Why is Planning Poker a popular estimation technique in agile and scrum teams?
Planning Poker, also known as Estimation Poker, is an effective tool for relative estimation of complex empirical work, such as engineering or software development.
It is a quick and efficient way to get the data you need to produce a plan. Also known as Scrum Poker or Pointing Poker the game results in a numerical score being assigned to a product feature or deliverable, such as that described by a "user story".
This score is the number of "story points" - a relative measure of complexity or risk - which can be fed into planning and forecasting processes.
How to play?
A typical agile team will run a planning poker session with this sequence of steps:
- Developers are each dealt an identical hand of Estimation Poker Cards. Each card has a number from the Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21 plus coffee and question mark symbols.
- In this context a developer is anyone who contributes to the implementation, and can include quality assurance, cyber security, user experience and operations professionals.
- Someone with an understanding of the feature, usually the product owner, presents the feature.
- The development team then discuss the feature as much as they feel necessary. Optionally, they produce and agree a task-break down but tasks won't be estimated individually.
- At an agreed time, developers secretly select a card reflecting their individual assessment of the feature, how complex it is to engineer, test and deliver. If the developer does not have an estimate, or needs a break, play the appropriate card.
- Altogether, on count of three, the developers share their card.
- Unless there is already consensus, conversation should now focus on why the story is seen differently by the developers who played the highest and lowest cards.
- Steps 5 to 7 are repeated until there is consensus, or the team agree to invoke one of a number of strategies to resolve differences of opinion.
- Once there is a consensus estimate, record the number of story points or T-Shirt Size against the user story. Writing it on a user story card with a pen is a great start, as that record is immutable.
Our Planning Poker Range
How long does it take?
Estimation poker is often time-boxed to keep it as short as possible, but there is also value in allowing the technical solution to be discussed thoroughly. The level of depth to go into is a trade-off decided by the teams.
Estimates are not directly valuable to a business in the way that features are. Teams should be estimating for a clear purpose, to help make a decision or verify a plan.
Once your team have discussed a feature and exchanged perspectives there is little else for them to gain. So the game should last long enough to meet the purposes of estimating but no longer than that.
Why does Planning Poker work so well?
Using a card game like poker for planning a software project might seem odd. This gamification encourages team members to think independently by asking them to reveal their score simultaneously with their peers. This avoids the cognitive bias known as anchoring and exposes situations where team members hold different information or perspectives on the work.
Influential Lean Management theory categorises estimation as waste because it does not directly deliver value. Agile practitioners therefore try to reduce the time spent producing estimates, which have a poor history of inaccuracy anyway.
Typically, conversations during the game will be focused on the perspectives that differ the most. This means that details that will not effect the estimate are less likely to be discussed and the conversation is much more efficient.
Another reason this poker game process makes planning cheaper is that it takes relative complexity as the input, rather than a complex design document that may not be accurate. There is simply too much detail to be discovered down the road, and without an implementation in-progress much of that detail is not discoverable.
Relative complexity however, is a tractable question. Only a broad outline of the solution is needed to determine this, and that outline can be produced in a fraction of the time, dramatically reducing the effort needed to produce an estimate.
What is a story point?
A story point is an abstract unit. It is not convertible to time or cost in the way that you can convert inches to centimetres. You can, however, use it as a leading indicator of the cost or time you are likely to need to achieve a goal.
If you are keeping good records of the work your teams have done, and the initial estimates for each item, then you can make statistical claims. Useful claims might include:
95% of 5 point stories were completed within 4 weeks.
99% of medium stories took less than a week.
Several 1 point stories were all delivered in less than a week.
You can then extrapolate a typical velocity in terms of story points per man day, with a known degree of confidence.
Velocity is the term used to describe this ratio of story points to time. It is sometimes said that a team which does not know it's velocity is not doing agile.
How do story points help me forecast a release?
Once a team knows it's velocity, and has estimates for a body of work then you can make a prediction about when that work will be completed.
Let's say you need 4 features before you can launch a new advertising campaign. Your marketing team need to decide whether to tie the campaign into a sporting event in the Spring, or a music festival in the Summer.
Let us suppose:
Estimates are 5 + 13 + 3 + 8 = 29 story points
They will probably split the 13 point story to an 8 and a 5 point story, with the same total.
The team's historic velocity is at least 10 points per week.
Their record is such that 95% of the time they manged to deliver features with 10 points of complexity each week. 5% of the time they hit obstacles and performed more slowly.
The sporting event takes place in the first week of June. To meet that deadline confidently the team must be ready to start by the 1st of May.
If they are not ready to start by that date then the Marketing team may decide to tie in with the Summer music festival. Alternatively, faced with a 3 month delay they may decide to drop one of the features and accept a smaller uplift more quickly.
For example, they may determine that the cost of running the team for more than a week does is not justified for that 13 point user story, but the team split it to a 5 and an 8 and marketing can accept just one part, or none.
Such decisions are quite easy to make with the help of spreadsheets given this level of detail. Asking the team to estimate every task and sub-task to the hour would simply delay the start date and may not result in a more accurate prediction.
Why use the Fibonacci Sequence?
The Fibonacci sequence is a series of numbers derived by adding the two prior numbers. It frequently turns up in nature, such as in the spiral form of flowers. It is named for the Italian mathematician Leonardo Bonacci, known as Fibonacci, but was first identified in India. It's use in estimation is almost arbitrary, but it's popularity has some important causes:
- The difference between numbers increases over time. This matches the experience of developers and project leaders who know that features that are only slightly more complicated are much more likely to take longer to deliver.
- The relationship between adjacent numbers is consistent. Developers have plenty of details to consider while estimating. If the relationship between adjacent numbers seems to change then this is confusing and burdensome. Using consistent numbers makes this simpler, not harder even if they happen to look strange.
- It is clearly unrelated to time. We have a feel for which numbers are related to time. 5 days, 52 weeks, 12 hours, 15 minutes. The Fibonacci sequence is distinct from those numbers. This makes it easier to have conversations about what story points are.
We prefer the raw Fibonacci sequence over variations as it is optimal for the process of estimating. Variations that use rounded numbers are motivated by a need for round numbers in reports, however, we favour reporting only the forecast delivery dates and doing so in units of time. We expect this to prevent comparisons of teams based on velocity, which are rarely meaningful.
Who invented planning poker and why so many names?
Planning Poker was invented by James Grenning after a particularly slow meeting. The team was bored and had nothing to engage with, while just two team members discussed an estimate. They finally kept the same estimate they had before heading down this rabbit-role 20 minutes earlier.
The game was popularised by Mountain Goat Software's Mike Cohn in his book Agile Estimating and Planning. He also trademarked the name "Planning Poker" and requires teams to use his modified sequence of numbers which is optimised for reporting. Many other names are used, for example, pointing poker is at least as popular in the United States. Scrum teams often call it Scrum Poker, because they are producing Sprint forecasts.
We use the name "Estimation Poker" because we do not sell decks with the whole of the Planning Poker sequence, offering more player-sets per deck instead. We have optimized our decks for fast estimation during the planning session, rather than reporting afterwards. Using the raw Fibonacci series ensures each card has a consistent relationship to the cards that come before it in the sequence. We believe this makes life easier for estimators.
This level of non-conformity is a sign of large and diverse communities taking an interest in the game and bringing with them their own perspectives. This is a sign of the game's popularity and increasing importance in project delivery best-practices.
What is Scrum Poker and how is this played?
Scrum Poker was always just another name for Planning Poker or Estimation Poker until Agile Stationery's Simon Gibbs created the first version optimised for Scrum teams.
Simon was approached by an agile coach at a well known ecommerce retailer whose team was not delivering on a predictable timetable. The team was actually practicing kanban, but rather than producing stories all the same size, they often accepted stories that blew up unexpectedly into huge epics or just took longer than usual. The problem was that the team were just too nice and too keen to get started as soon as possible. Enforcing standards, even to make life simpler for themselves, was unappealing for them. Little did they realise how disruptive it was for stakeholders when bad stories caused a problem.
The game was invented to normalise the exceptional case that stories will be rejected and work will not start, either because they are too big, or too poorly defined and likely to "blow up". The very simple act of printing these two rejection reasons on cards is a kind of social proof that a rejected story is a normal outcome for a planning meeting.
Scrum Poker replaces the "?" and "21" cards with "Not ready" and "Split", if consensus is achieved for either outcome then the story moved backwards through the process and more work is done to improve the story.
The 2020 COVID pandemic stopped that team using the cards, but the game deck was put into production during lockdown and proved consistently popular ever since.
Resources
- "Planning Poker or How to avoid analysis paralysis while release planning" by James Grenning - the original paper proposing Planning Poker.
- "Relative Estimation Communication" by Ilan Goldstein, Axis Agile - a simple explanation of relative estimation based on a fitness analogy.
- "Stop wasting time trying to get estimates right! – and what to do instead" by Jesper Boeg, Agile Upgrade - a thorough guide to making cost based decisions without wasting money on the estimates themselves.
