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."
Planning Poker
FeaturedPlanning Poker is a collaborative technique agile teams use to estimate product backlog items. It works because it combines independent thinking with team discussion.
Agile Estimating and Planning Chapters
FeaturedRead sample chapters from Mike Cohn's Agile Estimating and Planning and explore practical guidance for estimating, planning, and forecasting agile work. Please provide your name and email and we’ll send you the…
What Are Agile Story Points?
FeaturedUnderstand what story points measure and why they are often misunderstood.
When Should We Estimate the Product Backlog
Estimate backlog items at the right time and level of detail.
Don’t Equate Story Points to Hours
Story points are about time, specifically effort. But that does not mean you should say, “One story point = eight hours.
3 Roles That Need to be Involved in Agile Estimating with Planning Poker
Clarify who should be in Planning Poker so estimates include the right knowledge.
Four Reasons Agile Teams Estimate Product Backlog Items
Estimating product backlog items provides benefits beyond predicting when a project will be finished.
Estimates on Split Stories Do Not Need to Equal the Original
Understand why split story estimates do not need to add up to the original.
Automatically Triangulating Estimates in Planning Poker
Compare new estimates with known stories to keep Planning Poker results consistent.
Why I Don't Use Story Points for Sprint Planning
I don't use story points for sprint planning because story points are a useful long-term measure. They are not useful in the short-term.
Should You Re-Estimate Unfinished Stories?
We avoid having unfinished work at the end of a sprint, but it sometimes happens. Here’s what to do.
The Best Way to Establish a Baseline When Playing Planning Poker
Establish useful baselines so Planning Poker estimates stay relative.
2 Times to Play Planning Poker and 1 Time Not To
I recommend using Planning Poker on product backlog items rather than on the tasks that make up a sprint backlog.
7 Ways to Get the Best Estimates of Story Size
Agile teams often struggle to estimate product backlog items. Here are 7 ways to make solid improvements.
Estimating
Build practical agile estimating skills with story points, planning poker, triangulation, velocity, and techniques for making useful forecasts without chasing false precision.
Estimating & Planning
Improve estimates, forecasts, release planning, and conversations about scope, timing, and risk.
Plan Visualizer
The Plan Visualizer is a free agile forecasting tool for testing whether a target scope can be completed by a target deadline. It plots the plan against a low and high velocity estimate so teams and stakeholders can…
Accurate Agile Planning
Help teams create credible forecasts, plan under uncertainty, and make better decisions about scope, timing, risk, and tradeoffs.
Velocity Range Calculator
Use this to calculate a velocity range from historical sprint data and support milestone forecasting.