Learn Agile Estimation : Story Points Estimation
Learn Agile Estimation : Story Points Estimation

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:

1. 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.
2. 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.
3. Once they have chosen their cards, all team members simultaneously flip their cards face up.
4. 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.
5. With the new evidence uncovered during the debate, the team returns to step 2.
6. Steps2 through 5 are repeated until a general consensus is reached for the PBI.
7. 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).

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!

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!