Tool for recording Planning Poker games

When we play Planning Poker I wanted a way of recording the results of each story in a simple way. I also wanted to be able to accept the fact that we won't always reach consensus. So if we have three people playing a 3, person playing a 2 and one person playing a 5, and all of them refuse to change their minds, what do you do? Do you count it as 3? Or 5? Or 2? After you've tried letting the extremes argue (defend) their choices and then had a couple of replays, it starts to feel silly. So being a fan of mathematics and formulas I wanted to be able to live with that difference in opinion and still have a clear way of counting the result. The obvious approach would be to count the average; (2+3+3+3+5)/5 = 3,2 (or rounded to nearest half; 3.0). It works. Do it if you want. I on the other hand wanted the formula to tilt towards "worst case" rather than letting the lower estimates affect it equally. So I used a formula I picked up in (I think) "Agile Estmiating and Planning" by Mike Cohn; Estimate = (1*Min + 2*Avg + 3*Max)/6. The result in the example above would be: (1*2+2*3.2+3*5)/6=3.9. Or rounded to nearest half (which we always do); 4.0.


So for every play we do we record the final estimates from each player. We enter them in the formula above and that is what we the put as the estimate or story point value.


I have a tool I made in Excel, which we now use. Feel free to download and use if you like:
EstimationSheetTemplate-v4.xls

Planning Poker and tasks vs stories

We've used Planning Poker for over a year now. Our experience is that it is a great and easy way of coming up with estimates. If you don't know what it is, you can read more about it here.

When we started it seemed natural to us then that the values of the Planning Poker deck represented hours; 1,2,3,5,8 hours and so on. We had a rule of thumb that said that no task/requirement/story should be larger than e.g. 18-24 hours. If estimators felt like playing a higher card than that then it indicated that the story needed to be split up into smaller bits.

So, this seemed fine, especially on paper. The problem was that many sessions became extremely lengthy and we often got stuck in discussions about details and solutions. I know this is to be avoided in Planning Poker, but that's what I wanted to point out here: we made that mistake. It wasn't as easy as just saying "No let's not talk about design details now"... We said that. Over and over :-). People felt they needed to discuss the details, in order to decide between e.g. a 5 or an 8, or between 8 and 13... It was often possible to force a play and ask people to follow gut-feeling and intuition first, but the discussions kept popping up over and over again.

Our approach on avoiding this and speeding up the sessions was to simplify: forget hours. We estimate days instead. Our smallest estimate now is 0.5 (days) and then we follow the typical Planning Poker deck series; 1,2,3,5,8 and so on. A typical task/story takes between 0.5 and 5 days, I would say.

In my experience estimating in hours causes a false sense of security and leads to over-confidence in the plans. One of the arguments against using days as the estimation unit may be that we then miss the opportunity of really thinking through what parts/activities/tasks a certain story/task consists of and thereby miss possibly important aspects in the estimate... Maybe it is so. I dont know yet... So far I think it's a good tradeoff; I trade waste of time and false sense of security for a possible decreased accuracy... Well, I've already accepted to sacrifice accuracy given the 2-3 minutes per story and the whole idea behind Poker Planning to begin with: a fast and simlpe way of estimating.

My understanding of the common practice in Scrum is that you estimate two sorts of things;
1. Estimate stories in Story Points, which is a relative estimate of complexity (regardless of time)
2. Break stories down into tasks and estimate tasks in hours.

Our implementation (so far :-)) is to simply estimate stories using Gnome Days. Sometimes we have to break stories down into tasks during a sprint planning session, but certainly not always. If we do, we obviously estimate the tasks individually, but we still use days as the unit, not hours.

I'm curious to hear about other people's experience in estimating days vs hours in Scrum.