Jim's Pages => Story Process => Story Estimates
Developers estimate the size of stories. Read that again out loud. Managers and customers cannot tell them they are wrong, cannot pressure them to compress estimates. The goal of estimating is to correctly predict work, not to make anybody happy with the prediction. See team RolesAndRights.
Developers estimate stories in story points. We encourage developers to use estimates of 1, 2, 4, and 8. The critical part of estimating a pile of stories is that a 4 story points is twice as much work as 2, and half as much as 8. If a story is bigger than 8, it should probably (but not necessarily) be split up. Other numbers are permitted after discussion with a manager or process coach.
Some agile authors suggest that developers estimate stories in "Ideal Engineering Days." In an Ideal Engineering Day you code for eight hours with no interruptions. We avoided this, because it is too tempting to see Ideal Engineering Days as calendar days. Then you hear one developer say "I could do that in three days." and another say "I've never done one of those, it might take me six." Which number do you use?
Our choice is neither. The two developers should be able to agree that one story is twice as big as another, regardless of who does it, and that's what we really want to know.
As the project delivers completed stories, we observe number of points completed per iteration. The ratio is known as velocity. It is a red flag when management tries to predict or establish velocity or mandate an improvement!
As each iteration passes under the bridge, we repeat the PlanningGame. With our ever-improving knowledge of velocity, we refine the overall project plan. Again, the goal of estimating is to accurately predict performance, not to make anybody happy.
Remember those two developers with different skills and different estimates? If we give every story to the best suited developer, velocity will be high. If not, velocity might be lower. On the whole, we expect stories to average out, so it's ok for story points to leave the skills aspect out out.
One time when you cannot observe velocity is at the start of the project. There are no iterations to measure. In the pre-sales phase we use other high-level estimating tools to build a ballpark estimate of time and resources for a project. Once we have the stories estimated, we can divide the total points by the ballpark timeline and get a predicted velocity. If we have appropriate prior experience we can see if this seems reasonable. Otherwise we have to wait for a few iterations to pass.
Because of confusion about Ideal Engineering Days vs. calendar days, some projects do their estimates in more abstract values, such as Gummy Bears. Velocity is then Gummy Bears per iteration. If you think there is no place for whimsy project planning. call them Story Points. But don't get too serious - some playfulness in the name helps remind you that this is not a life and death matter, and is not precise enough for rocket science.