My shopping cart
Your cart is currently empty.Continue Shopping
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.
A typical agile team will run a planning poker session with this sequence of steps:
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.
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.
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.
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.
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:
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.
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.