What About These Estimates?

Extreme Programming teams estimate stories in a few different ways:

• Arbitrary Units. Some teams estimate stories in arbitrary units, sometimes called Gummi Bears. Take a small story, call it a 1. Estimate others proportionally to that small story.

• Ideal Time. Some teams use ideal time, or bar time. Bar time is the amount of time you would estimate after a few beers, when a programming buddy told you about some hard job he had to do. You might say, If theyd leave me alone, I could do that in two days. Your ideal time estimate for that story is two days.

• Elapsed Time. Some teams estimate in elapsed time, the expected time actually required to do the job. Note that the previous two estimates are not in elapsed time.

In the previous section, I estimated in days and I was thinking in terms of elapsed time. I was assuming that I would not be pairing. If I am able to pair, Ill go much faster. The usual experience is that two people pairing get more effective work done than if they worked alone. Since Chet and Paul are only on the project when they work with me, the effect of pairing with them is to make me go faster. They dont get paid any more for that; its a good deal for me. Anyway, my figures above are elapsed days, without a pair. Thats a conservative number, I hope, and just what I needed at this point.

Teams that use arbitrary or ideal units measure their velocity, the rate at which they produce units. If the team completes stories adding up to 15 Gummi Bears in a week, their velocity is 15 GB per week, or 15. If the team completes stories adding up to 20 ideal days, their velocity is 20.

Velocity is used to predict how long it will really take to get things done. Its all very well for the team, or its management, to say that everything will be done by January 15th, but its not likely to come true all by itself. The wise team measures how rapidly progress is really being made, and it reports that information to customers and management on a regular basis. Customers and management adjust what they ask for to get the best possible combination of features by the delivery date they have in mind. The XP Iteration Planning practicesee the Extreme Programming preliminary chapter at the front of this booksuggests that the team should schedule, in each development iteration, just as much work as they got done in the previous iteration.

Thus, whats important about story estimates is that they should be approximately proportional: a two should take twice as long as a one. If thats the case, we can use velocity to predict how long it will take to get any combination of stories finished. If theres a deadline ahead, some important date, the way to get the best product by that date is to have estimates for all the stories, to know velocity, and to pick the most important stories that the story estimates and the teams velocity indicate you are likely to get done.

Its all very well to rail and fuss over the need to get more done. The wise management move, however, is to manage: based on what the team is able to accomplish, choose the most important work to be done. Measure progress often, and update estimates often. This is how XP customers and managers steer their projects to success.