With relative story point estimation now in your arsenal, you finally have a weapon to wield in the battle against the forces that make software estimation so painful. Relative estimation is simple, makes sense, and is way more fun than other long-winded and misleading estimation techniques!
The technique we use to conduct relative estimation is a game invented by James Grenning and popularized by Mike Cohn called Planning Poker. It is based on a method developed in the 1970s called Wideband Delphi that evolved from an earlier version (Delphi) invented in the 1950s by the RAND Corporation. This approach utilizes broad insight from a group of cross-functional experts to arrive at an estimate that is typically more accurate than one derived from a single person.
Setting Up the Game
The technique is called Planning Poker because teams literally play with cards. But, instead of spades, hearts, clubs, and diamonds, they use cards representing story point values. A common point system that is utilized for these values is Mike Cohn’s modified Fibonacci sequence:
1⁄2, 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞ (infinity)
In case you were wondering, I believe a fair translation for the infinity card would be something along the lines of, “Whoa! That is way too big to estimate—it definitely needs splitting before any meaningful estimation can occur.”
I’m a fan of using the modified Fibonacci sequence because it helps to reflect the greater amount of uncertainty that exists as requirements get larger (see Figure 1) while also avoiding the perception of precision (hence the change from 21 to 20, 42 to 40 and so on). That being said, it does come with a potential problem especially with new teams. If you recall from Relative Estimation Comunication, the point values should not correlate to a specific time or distance unit. The issue when using Fibonacci numbers is that people can get into the bad habit of equating 13 points to 13 hours, for example.
Figure 1 – The modified Fibonacci sequence is an approximation of the logarithmic “golden spiral” where greater uncertainty exists as requirements get larger.
To combat this situation, some teams adopt more abstract classifiers, such as T-shirt sizes:
XS, S, M, L, XL, XXL
I personally don’t use this extra layer of abstraction because it requires the extra step of mapping to a numeric value to enable forecasting during release planning — remember how in Relative Estimation Communication we calculated the time it would take to climb the buildings by dividing by the numeric velocity value?
Planning Poker Mechanics
Before we proceed with some Planning Poker hints and tips to ensure that your sessions don’t become late-night marathons, let’s run through a brief overview of the mechanics of the game.
The session proceeds as follows:
- The product owner describes the top PBI before the team is invited to ask questions to clarify the scope and desired benefits. Any changes to the PBI description or acceptance criteria are captured progressively.
- Once ready to estimate, each team member places, face down on the table, the card he or she feels best represents the effort required to complete the PBI.
- Once they have chosen their cards, all team members simultaneously flip their cards face up.
- When there is a lack of agreement, the holder of the high card has a short debate (a few minutes at most) with the low-card representative under close observation from the rest of the team.
- With the new evidence uncovered during the debate, the team returns to step 2.
- Steps2 through 5 are repeated until a general consensus is reached for the PBI.
- Once the PBI has been assigned a value, the process starts again from step 1 for the next PBI in the product backlog (see Figure 2).
Figure 2 – The flow of a typical Planning Poker cycle.
Note that the ScrumMaster acts as the facilitator throughout and is not involved in the actual estimation.
A key requirement is that everyone must estimate the effort for the entire PBI as opposed to just estimating the bit that pertains to his or her specialty. For example, a programmer needs to estimate the effort of not just the coding work but also the testing and deployment work—an interesting concept, right?
So, how does everyone participate in estimates of work that is not in their primary area of expertise? Well, they need to base the combined estimate on experience. Even though they might not have done much of the testing, they will remember what was involved when a similar PBI was implemented in the past. They will recall, for example, that even though the programming wasn’t too tricky, the testing was a nightmare because of the various integration points with the third-party payment system they were using. It is common for individuals to assume that they are estimating only for their specific function, and it is a common reason that new teams typically start with very disparate estimates (so beware of this pitfall).
When to Play Planning Poker
The first Planning Poker session should take place after the initial product backlog is compiled, and subsequent games can be played whenever a new PBI is added to the backlog or in the rare situation that reestimation is called for. Reestimation should be required only when a whole class of PBIs suddenly becomes smaller or larger (relatively speaking). When does this situation occur? Let’s say that a set of your PBIs rely on integration with a third party. Their API has been flimsy, at best, and you know that workarounds, not to mention a whole heap of extra testing, will need to be applied. Let’s say they finally release a brand-new, super-improved interface that removes the need for workarounds and additional testing—all of a sudden, any PBIs reliant on it become relatively smaller.
Get the Team Warmed Up
To get the entire team ready for a Planning Poker session, it’s important to circulate a small number of reference PBIs that correspond to the point levels in the card deck. Refer to my article about Transitioning from Time Estimation to Relative Estimation for more details.
This process calibrates everybody’s yardsticks nice and early so that the team will be able to immediately recall what a 13-point PBI is and what a 1-point PBI is (as well as everything in between). Send these references out a few days before the session, followed by a quick reminder on the morning of the session.
Big Cards for Big Occasions
I typically advocate removing the big cards (20, 40, 100, infinity) as well as the 1⁄2 card from the Planning Poker deck. The rationale behind this decision is that you effectively cut the total choice of cards down to six, and fewer options equals less analysis paralysis. Further, it discourages product owners from bringing to the table any stories that are too large and nebulous.
That being said, Mike Cohn raises a valid scenario in which the big cards will come in handy:
[jbox color=”gray”]
“Suppose your boss wants to know the general size of a new project being considered. The boss doesn’t need a perfect, very precise estimate. Something like “around a year” or “three to six months” is enough in this case. To answer this question you’ll want to write a product backlog. You want to put no more effort into this than you need to. Since the boss wants a high-level estimate, you can write a high-level product backlog. Big user story “epics” that describe large swaths of functionality will suffice…. And these epic user stories can be estimated with the large story point values.”
Mike Cohn – In Defense of Large Numbers
[/jbox]
If nothing else, using these big numbers will indicate to all involved that there is a high level of uncertainty and that the best estimate that can be offered at this early stage is one of general magnitude rather than specific duration.
Don’t Double Up
As often happens, a group of PBIs will inevitably rely on some of the same important research or technical plumbing. If this is the case, ensure that the same work is not estimated multiple times. This underlying work should be incorporated into the estimation of only one of the PBIs, not into all of them. Which PBI you decide to incorporate these extra tasks into is up to you, but try to select the one you anticipate will be implemented first. Although this advice might sound obvious, you may find that your team assumes they are estimating PBIs in isolation unless you make this point explicitly clear.
Reaching a Consensus
After some discussion, the team will play its first round of Planning Poker. If it doesn’t result in consensus, I recommend asking the following questions:
- Have you considered all the necessary functions and not just individual specializations?
- Do you have a hard or soft opinion about that score?If it is soft, are you comfortable switching your value?
- Is anyone on the borderline between two values?If so, are you comfortable moving to the more popular adjacent score?
If there is no consensus after asking these questions, it is time to facilitate a quick debate between a representative of the high card and a representative of the low card. The trick here is to make sure the debate doesn’t become a drawn-out, granular technical discussion. The simple message to the debaters is to base their arguments on the relative comparison of the PBI being estimated to the reference PBIs (rather than on the complexities of the potential technical implementation). Remember from Relative Estimation Communication that relative estimation focuses on comparing rather than deconstructing.
Finally, if the team simply cannot reach an agreement between two adjacent values, you should err on the side of caution and use the higher value.
Phones Can Help
Unless you’re a hard-core disciplinarian, you will find people occasionally checking their phones for messages. If they’re playing Angry Birds, then you’ve got bigger problems! Instead of being the scolding teacher, make their devices part of the session. Get the team to download one of the legitimate, licensed Planning Poker apps and use their devices instead of the traditional cards. Not only does playing Planning Poker on a phone make it more difficult to play around with Angry Birds, it also saves you from that laborious task of sorting through the cards at the end of the session!
It’s All about Benefits
After you’ve played some Planning Poker and used the advice from this article, the estimation benefits should be obvious. But what happens when your boss calls you into his office to discuss concerns about the team playing card games on the company’s dollar? Well, here are some extra benefits you can explain to transform him into a Planning Poker advocate:
- The ability to rapidly estimate long-term product backlogs without requiring detailed specifications and complicated dependency mapping.
- The ability to provide broader insight from a diverse set of functional experts to ensure that estimates aren’t being padded or underbaked.
- The ability to leverage the knowledge obtained from completing legacy work.
- The ability for the team to actually have some fun while conducting a traditionally mundane and frustrating task. Planning Poker sessions are interactive, lively, and much faster than traditional estimation marathons!
Remember Parkinson’s Law
Speaking from experience, if the ScrumMaster doesn’t control the pace and focus of Planning Poker sessions, they will become endless talkfests or could even turn into pitched battle (personally, I don’t know which one is worse!).
Time-box your discussions and always remember Parkinson’s law: “Work expands so as to fill the time available for its completion” (Parkinson 1993).
I assure you that if you apply the suggestions given in this article, your Planning Poker sessions will not only become punchier (as in faster, not more violent) but everyone will enjoy them a great deal more!
If you liked this article, you can:
Find out more about Planning Poker by taking one of our CSM training courses.
This is great advice, thankyou! We no longer use 20, 40, and 100, which has forced us to break items into smaller stories resulting in more accurate estimations, and more successful sprints!
I would differentiate between 1) removing the 0, 20, 40, 100 and infinity cards from the deck and 2) not accepting such values as the estimations.
We have a good experience with sticking to the latter (option 2) – we use cards 0, 1, 2, 3, 5, 8, 13, 20, 40 and ?. 1-20 are valid estimates for us, but anybody can use even 0, 40 and ? anytime during the game.
It says:
0 – I do not actually see any work here,
40 – too big, needs splitting (we could also use infinity instead of this one),
? – I do not have a clue, I can’t estimate.
These cards then serve as a correction mechanism to return some stories to “pre-estimation phase”, or to trigger a further discussion directly on the estimation meeting.
In my opinion it is much better to allow team members to use these cards – and therefore express their real opinion – than force them to silently adjust to the set of “allowed” cards. Yes, experienced team members will say their opinion aloud anyway, but there are also those who welcome having the cards as a “tool” to do so.
If you really find in practice that nobody is using concrete cards (though they know their meaning and purpose) only then you can remove them from the deck.
Thanks for your thoughts Ondrej. It appears that we are certainly on the same page when it comes to the underlying message i.e. keep your stories small and break them down if they appear too large – the fact that you use a card as a prompt is all good; I just get concerned when the 40 card is used as an actual estimate. Regarding your comment about forcing the team to silently adjust to the allowed cards, if you check out this entry you will see that this situation shouldn’t arise due to the earlier calibration.
[…] http://www.scrumshortcuts.com/blog/estimation/planning-poker-at-pace/ Share this:TwitterFacebookVind ik leuk:LikeWees de eerste om post te waarderen. […]
I came across this blog from the Scrum Alliance website…really good stuff 🙂 Is the “high card-low card” debate and revote mandatory when estimates differ, or is it ok to just pick the average points value of all the estimates assuming nobody objects? I’ve found that most of the time people are happy to go with whatever the average is and this allows our planning sessions to progress more quickly.
Also – thanks for the tip about the planning poker apps. I’d never considered that before, and I’ve noticed there are heaps of free options. Only a couple of them actually leave the card face down at first, so that narrows it down for me 🙂
Hi Brandon – thank you for your kind words.
I find averages quite dangerous and deceptive. What happens if some developers choose 13 and others a 3 due to misinterpretation? Simply taking the average will negate any debate that would lead to the more accurate result.
Very valid and practical suggestions.
Many a times the poker sessions get dragged for hours. Any ideas to keep it short – say within an hour for about 20 items?
@Rathina – glad you found the suggestions helpful. Apart from the tips that will hopefully really speed things up, be very disciplined with time-boxes so that debate is kept short, sharp and to the point. I like to use a funny alarm on my phone to help enforce this 🙂
[…] https://www.axisagile.com.au/blog/estimation/planning-poker-at-pace/ […]