I like to use Planning Poker to estimate the user stories on an agile team’s product backlog. In this approach individual estimators hold up cards showing their estimates. If estimators disagree they discuss why, ask questions of their product owner (who should be present), and repeat until they come to consensus. Team members often ask me whether they really need to come to consensus or whether they can just take the mean of the individual estimates.
The problem with averaging is that it is too easy–rather than have the fierce discussion that is one of the huge benefits of playing Planning Poker teams fall into a trap of playing one or two rounds and then just averaging. An obvious dysfunction is that one estimator may play the 100 card not because he thinks it will take that long but because he thinks 20 is the right number and other estimators are thinking 8 and 13. For this reason and others, if a team truly feels compelled to average, they should take the median (middle value) rather than the mean (sum of estimates divided by number of estimates).
A lot of dark corners are enlightened through the discussion; teams lose out on that when they average. So while I want teams to come to agreement, I don’t care how heartfelt the agreement is. If we agree on 13 some of us may really believe that’s the right number. Others may think 8 is right but that 13 is “close enough.” Still others may think we’ve discussed the item too long and even though it should be a 20 will give in and call it a 13 just to be done with it.
So, rather than average if the team is an impasse I suggest going another round. If still stuck, someone should suggest a reasonable number and see if everyone can “support it” rather than “think it’s the absolutely perfect number.”
Tags: agile estimation, planning poker
Now the question is..where can i buy some of the nice looking cards..
Hi Evan–We do sell the cards at our cost, which is $2.50 per deck, plus shipping. Each deck has enough for four estimators. We cannot yet accept orders online. To order cards contact Laura Cohn at (720) 890-6110 or at laura@mountaingoatsoftware.com. She will need to know:
* the number of decks you want
* your credit card number
* credit card expiration date
* the name on the credit card
* the billing address of the credit
* the address to ship the cards to
* any special shipping instructions (such as “to arrive on Friday if possibleâ€)
Also, check out http://www.planningpoker.com if you have a distributed team. That free site let’s team play planning poker online.
I’m a proud owner of 3 decks. They rock!
so frustrated with my team right now. I joined last week and we basically have 3 months left to finish a project that is HUGE in scope and no one wants to do estimating because it’s going to tell us the obvious… “we can’t finish all of this functionality by then”. Sad really. So our estimating is like this: “You need to finish this by friday, can you?”. I hate waterfalls.
My experience lies more with XP than Scrum. If my understanding is correct you would use Planning Poker when estimating the product backlog (release planning) and you wouldn’t use it for the sprint backlog (iteration planning)? I am not sure if Scrum has the same principle as XP, where developers sign up for tasks and they estimate how long it will take them to do the task. I also want to digress slightly and get your opinion on defects. I have seen reference to a defect backlog in Scrum but I am not sure if this is a consistent approach? My question though is do you estimate defects? For example, what happens if the defects is determined to be a fact-of-life?
Many thanks.
Hi Peter–
Yes, I personally advocate Planning Poker for estimating the product backlog (which we use for release planning). I’m indifferent to using Planning Poker for sprint planning but others have reported very good success using it then as well.
I can’t recall hearing a team call their bug list a “defect backlog”. The normal mode is that bugs go into a defect tracking system (because this system has become a workflow tool between the development group and other groups such as support). One common approach is to grab anywhere from say 2-12 bugs that the product owner wants fixed, estimate them in story points (or ideal days if the product backlog is estimated in those instead) and then include them as normal in sprint planning. So, yes it’s common to estimate defects but usually in clumps rather than individually. The other approach if you have a lot of them is just to make an average fix-time estimate per defect.
Regarding planning for defect work in the the interation, I have had success using a exponential algorithm to estimate the number of defects to be fixed for a certein number of points. Line up 2 number lines like this, one Fibernacci and one ^2.
1 2 3 5 8 13
1 2 4 8 16 32
The top number is how many points estimated for a package of bugs on line 2. In other words, on avareage, 8 defects is worth 5 points. 16 defects is estimated as 8 points, and so on.
Is this real? Well, I noticed the pattern, I didn’t impose it. Cool, eh?
Hi Kris–
We anticipated that the site might be blocked by some IT groups. The http://www.planningpoker.com site is mirrored at http://www.agilereckoning. com so you can access it via that name. (I hope–it depends if your IT group filters out poker in the site’s body or in the URL.)
I don’t know how the space got it the URL above. It should be http://www.agilereckoning.com
We love the poker cards – I’m giving them to our East Coast teams for Christmas
I was excited to see the online Poker – however our IT department blocked the site because of the word “Poker”!
Hi Mike,
Glad to have stumbled across your blog. I’ve attended a couple of your tutorials over the past 18 months and become a big fan as a result.
On the topic of Planning Poker, I’ve noticed a few patterns in the time that we’ve been using it, and thought I’d pass them along for discussion or consideration.
In your example where you say that one person believes an item to be 8 but goes along with 13 because it’s “close enough”, I’ve found that I have to be sure to explain what that means to avoid a particularly nefarious result. What can happen is that the person who thinks it’s an 8 but “goes along” with the 13 is still regarding that item as a 13 in their head. So when another item is being discussed, he or she is now sizing it as an 8 (say) because it seems about half the size of the previous item (which was a 13 as far as they’re concerned), whereas everyone else is considering it a 3 or a 5, for exactly the same reason (half of an 8)! In other words, that person said “close enough” but didn’t really give up on their own answer… they just “went along to get along!” Because of this, I’ve had to say things like, “OK gang, so we all agree that that last item was an 8. That means that no one should still be thinking of it as a 5, or as a 13, or as anything other than an 8. Agreed?”
Another pattern seems to manifest itself when teams size things in bunches but never take the time to compare those Story Points to anything outside of that new group of items. Sure, they’ll have a fairly consistent notion of what a 1 is, perhaps, but won’t actually look at each new item, after sizing it, and ask, “Is this really about the same size as _____ from the backlog?” where that other item was sized at some earlier date. They end up with little pockets of backlog items that are sized reasonably well compared to each other but which actually represent slightly different units. You can imagine what a release plan built on those non-aligned backlog item sizes looks like, where the velocity never achieves anything resembling consistency.
Not sure if these are common patterns or not, but thought I’d share them regardless. Always happy to find people willing to “talk Agile!”
Hi Matt-
I’ve definitely noticed this same situation, in which one estimator agrees to change his 13 to an 8 but then does subsequent comparisons to the invalid 13. The best I’ve found to do in this situation is to constantly compare items being estimated to ones previously estimated. I might say, “So if you call this is 13 it’s about three times the size of this five [and then I read the 5] and it’s about the same size as this other 13….” It’s amazing how often someone will respond with, “Oh, no, it’s not at all. It’s much bigger than that one…” This is part of what I call triangulating–finding the right estimate for this item by comparing it to at least a couple of previously estimated items.
I get around the problem of the meaning of the units shifting from session to session the same way. Start an estimating session with, “OK, here are some examples from past sessions…” and then read a few random items being sure to cover a variety of sizes.
[...] Save Time… Avoid Agile Planning Poker The agile project management technique of planning poker is a popular estimation process for software development. My favorite Agile author Mike Cohn presents a good description of the practice on his blog here: http://blog.mountaingoatsoftware.com/?p=14. [...]
We average where the risk is low, we do that on a 5er or a 8er, maybe a 13er is averaged to an 8er.
But we never do a 20 out of a 40.
But i will bring up the comparing to prevuious items, which should solve that.
After all i don’t see that as a problem, since we just do that with the small numbers.
The Team works with the PO already before the weekly estimates, so stories come in handy chunks anyway.
I guess the average rating is a little bit like the commit to a sprint before having stuff planned in PII. I drag you theough the stuff, you drag me through the stuff. So everyone is obliged to help each other.
This makes people sure that there is no problem is saying “ok i go along with a 8 but i was playing the 13, because …..”. All in all they wont be working alone on the task in the end.
Stuff to think about. …..