Don’t Average During Planning Poker

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."


A Free PDF to Help You Choose the Approach

A Free PDF to Help You Choose the Approach

I’ve created a PDF you can download that will help you decide which approach is best for any story you’re adding detail to. It also includes examples of the two approaches.

Download my PDF
29

Posted:

Mike Cohn

About the Author

Mike Cohn specializes in helping companies adopt and improve their use of agile processes and techniques to build extremely high-performance teams. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile as well as the Better User Stories video course. Mike is a founding member of the Agile Alliance and Scrum Alliance and can be reached at hello@mountaingoatsoftware.com. If you want to succeed with agile, you can also have Mike email you a short tip each week.

The discussion here is closed but join us in the Agile Mentors Community to further discuss this topic.

Go to AgileMentors.com