Dragons in the Algorithm
Adventures in Programming
by Michael Chermside

Story Points

If you have complete and accurate requirements for your project which won't change, and your development team is spot-on in estimating and highly consistent in their development pace. and there are no surprises, then you can produce highly accurate project timeline estimates up front. Such accurate estimates are (or, more accurately, would be) quite useful and well worth the effort it takes to produce them because of how nicely you can schedule everything. But how about the rest of us, for which none of this is true?

There really isn't much benefit to putting in lots of hours developing a detailed estimate if the project isn't going to proceed according to plan anyway (and it rarely does). This is why most agile development approaches -- including Scrum -- use a less-precise but also less time-consuming approach. By going with rough requirements, and a simple imprecise estimation process a team can produce rough estimates in a surprisingly short amount of time. The time saved writing requirement documents and producing estimates can be used to build something useful instead.

The process that I have found to be most useful starts out with requirements that are simple: just a paragraph or two written down for a feature and a few minutes discussion to make sure everyone understands it. The team meets, making sure to include someone from the "business side" who can answer questions about what is needed, the developers, QA, DBAs, and whatever other specialists are needed. The business person explains what is needed; the team talks through how they will code and how it will be tested. Then we're ready to estimate.

Everyone just says how long they think it will take. To avoid "groupthink" where everyone just agrees with the first person to speak, it's good to have each person come up with their idea independently before comparing: selecting cards and all revealing at the same time is one way to do this. Everyone estimates: yes, that means the DBA may estimate a Java coding task, but that's OK. To avoid long useless debates over whether it's 23.2 or 23.4 we usually limit the estimated sizes to some discrete values: 1, 2, 3, 5, 8, 13, 20, and "more" are a widely used set of values (the values chosen to make it easy to split a task). If, after hearing what was said we all agree on the size then we're done (this is where we all discount the DBA's estimate of the Java task); if not then we discuss for a few more minutes: maybe someone realized an extra step the others missed or knows where to find test data without having to enter it. If we still disagree after that, just take the larger estimate.

That's it! It takes only a few minutes to produce estimates this way. Of course, the estimates are worth what you put into them: the business MUST realize that these are only rough numbers. A common way to do that is to estimate in "Story Points" instead of "hours" or "days". Speaking in terms of a unit that is less concrete seems to help remind everyone that this is only a rough value. But it is a rough value that did NOT take weeks of preparation, and thus well worth it.

Posted Wed 28 September 2011 by mcherm in Programming