A couple of weeks ago I received an e-mail from someone from attended my ‘Easy way to stop estimating’ speech at ALE2011 asking how to start building your histograms if, ironically, you are not supposed to do estimations (in which case, you don’t have estimations to build a histogram with 
).
Of course, the whole point of (nearly) dropping estimations is to rely on actual, real, measured data instead. On the following explanation, I’ll assume you are not ready to drop the whole thing and still need some minimal estimation (although I can’t imagine why 
).
There are several ways to do histograms depending on the nature of your work. If you are solving small ‘ticket-like’ issues you can trace how long they take to solve, maybe doing also a small pre-estimation of “small-medium-large” issue – then build the histogram with the actual data (and maybe dividing it in three histograms for each kind of estimation).
If you are more into user-story like product backlog then (if you wish) you can make a small pre-estimation of “small-medium-large” or directly use story points with a reduced set (“1-5-8-13″ for example). Then there are two ways you can go:
- You can stick to that number. If a “1″ end up being actually a 5, you still count it as a “1″. This way, you would be acknowledging that, in future sprints, other “1″ stories will probably become a 5. So for example, you start with “1, 1, 5, 5, 8″ for a total of 20 estimated points – then the first story takes way longer than you expected, and you end up with 15 delivered points – Great! next time you’ll commit to less capacity.
- You can re-estimate stories later on. Then you will acknowledge that the first “1″ was actually a “5″, and you’ll still go for 20 points of capacity. I DON’T LIKE THAT. It’s not that you are wrong, but it’s kind of a “vanity metric” that will make you think you actually delivered the 20 points you commited, when the truth is that you only delivered 4 out of 5 commited stories.
Of course, you can also do hourly tracing of user stories, meaning that you can tag them as “small-medium-large”, write down a beginning date when you start, an end date when you end and then assigning the difference for histogram building.
Example: User story 35, originally considered of “medium” size, started monday morning, endend wednesday afternoon – 3 DAYS.
You can make more complex calculations, for example including queuing time or focus factor, but my advice would be to keep it as simple as possible.
Once you have histograms, you can start playing with SLA’s and say things like “80% of our medium-rated stories are done in less than four days, and they NEVER take more than two weeks” – That’s a SLA
Please, everyone trying to reduce the estimation process, keep my informed of your progress!! )
Bonus: don’t miss Vasco Duarte’s brilliant post on the topic
)
