Why estimate?

Much has been written on the subject of how to estimate the effort involved in developing software products. Some Agile teams use Story Points as their estimation units. Others estimate in Ideal Days. Still others use one of these plus Task Hours to help refine their estimates. Planning Poker is a popular method for quickly arriving at group consensus on estimates.

My own earliest attempts at estimating predate the Agile era by a couple of decades. In the beginning I used a technique that has probably been tried (with varying degrees of success) by many others:

  1. Break the development effort into as many small tasks as you can think of
  2. Estimate each of the tasks in hours
  3. Add all the estimates together
  4. Apply sufficient “padding” for comfort
  5. Hope the boss buys it

Estimation’s main purpose

There’s no doubt that the more recent Agile estimating techniques are much better than what I started out with, and I’m glad that so much effort has been put into developing these methods. Even so, I believe it’s easy to lose sight of the purpose behind estimating, which can be summarized as follows:

The purpose of estimating is to provide the customer with a predictable development schedule.

Predictable is the operative word here. With a truly predictable schedule, the customer can derive the information that is most important from his or her point of view. Given a predictable schedule, the customer can answer important questions, such as:

  • How much will this development cost?
  • Will we be able to hit the market window?

In other words, the customer is probably not interested in the accuracy or precision of your estimates in and of themselves. The customer is more likely interested in the predictive power of your estimates. Given that, you want to focus your estimating efforts on things that provide predictability.

Duration should be derived, not estimated

I like to encourage teams to focus on estimating User Stories in Story Points, and to discourage them from estimating tasks at all, largely because coming up with Task Hours doesn’t seem to contribute much to the goal of providing the customer with a predictable schedule. Admittedly, estimating Task Hours may help to inform the team about how good or bad it is at estimating duration, but that’s a metric that’s not directly useful to the customer.

What is directly useful is duration that is derived from a team’s demonstrated velocity. Given a velocity in units of Story Points per iteration, plus knowledge of how many Story Points remain in a development effort, the customer can quickly and easily predict the development schedule.

8 Comments

  1. Ted Young:

    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?

  2. Steve Bockman:

    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.

  3. Ted Young:

    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?”

  4. Steve Bockman:

    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.

  5. Ted Young:

    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’.

  6. Steve Bockman:

    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.

  7. Ted Young:

    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.

  8. Steve Bockman:

    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.

Clicky Web Analytics