Comments on: Why estimate?

By: Steve Bockman

Steve Bockman — Mon, 16 Feb 2009 14:12:31 +0000

Actually, they’re all Story Points. It’s just that some stories can be much larger than others (and are therefore referred to as Epics). There’s no doubt that the estimates for Epics will be less exact than those for smaller stories. In fact, the larger gaps between the larger estimate numbers represent that uncertainty. But does this mean that we lose our predictability? Not really. It’s just less accurate with larger stories. Can we address this? Yes. At the appropriate time, divide larger stories into smaller ones.

By: Ted Young

Ted Young — Mon, 16 Feb 2009 04:56:20 +0000

Ahh, ok, I think the terminology of “Story” vs. “Feature” is where things can go awry. Let’s define “Story” as something that fits very comfortably in an iteration (ideally a bunch of them fit) and a “Feature” as something that may take months to be “done”. If the team can estimate all of the stories (1, 2, 4, 8 points), then we’re in great shape and can predict a completion date if the velocity is pretty stable. However, if is it reasonable to expect teams to do this? Or would they instead estimate the Features at a higher level (10, 20, 40, 100) and then have a total number of “Feature Points”? Alas, we have no way to convert Feature Points to Story Points and we’ve lost our predictability.

By: Steve Bockman

Steve Bockman — Wed, 11 Feb 2009 15:41:37 +0000

I believe that, in practice, story points are never “revealed” as you describe it. Stories have either been estimated, or they have not. If all of the stories in the backlog have been estimated, the total of story points will not increase. If some of the stories have not yet been estimated, it shouldn’t be a surprise to the product owner that any new estimates will cause the total to grow.

By: Ted Young

Ted Young — Wed, 11 Feb 2009 00:15:24 +0000

The product owner might argue that it is the same (”But _I_ didn’t add anything to the backlog!”). They might further argue that by saying that the 200 points that were “revealed” (and therefore were “there the whole time”) means that this method can _not_ ‘predict the development schedule’.

By: Steve Bockman

Steve Bockman — Sun, 08 Feb 2009 00:43:51 +0000

It isn’t the same set of features. The 200 extra points can only represent new features, over and above the ones represented by the original 500 points.

By: Ted Young

Ted Young — Sat, 07 Feb 2009 17:27:27 +0000

So then how to respond to the reaction of the product owner when they say “but you told us it’d be 500 points, and now it’s 700 for the same set of features?”

By: Steve Bockman

Steve Bockman — Sat, 07 Feb 2009 01:39:08 +0000

It’s pretty simple. The number of Story Points remaining in a release is just that. If new stories are added, that makes more Story Points, thus moving the release date.

By: Ted Young

Ted Young — Sat, 07 Feb 2009 01:02:58 +0000

How does one really know how many Story Points remain in a release? How do you account for the fact that new stories will be uncovered as development proceeds, thereby increasing the number of remaining Story Points? Doesn’t that uncertainty end up forcing you to pad and buffer so that when those “dark matter” stories are uncovered, you’ve already taken it into account?