Planning Poker: Optimized

Posted on May 7, 2013 | 0 comments

Do you enjoy the benefits of fast, accurate estimation on your team by using “Planning Poker”?
Interested in squeezing a little bit more waste out of the process?  I have a relatively simple technique that I have applied successfully over the past several years to do just that. It may seem like planning poker is already a very highly optimized estimation technique, but just like anything else, there is always room for improvement.

Planning Poker Overview

First, for those who may be unfamiliar with the technique, let’s review the technique and some of the reasons why it works so well.  On most traditional software teams, estimating of work is done either by the developer who will do the work, or a technical lead of some type, or in some cases, a project manager.  Regardless of the individual that performs the estimation, it is typically performed by one or very few individuals with expertise in the field.  And in what unit do we typically estimate?  Hours, days, man-months, or some calendric equivalent is the canonical unit of measure for work effort for most traditional software teams.  So, how do we improve on this technique with planning poker?

Planning poker improves on the standard technique in three key areas: accuracy of estimates, effort required to estimate, and identification of risk.  To improve the accuracy of estimates, planning poker asks a team to estimate collaboratively as a team as well as hiding our “guesses” to avoid being influenced by others until we are ready to share as a group.  Next, the technique reduces the total effort required to estimate because instead of using a unit of time that is influenced by many environmental factors it uses a unit of relative effort by comparing one piece of work to another.  Lastly, teams identify risks and assumptions by discussing why their private “guesses” differed from each other.  For more detailed information, see Mike Cohn’s wonderful description of Planning Poker.

Here’s the basic technique:

  1. Product Owner/story author explains the user story to be estimated
  2. Team discusses the story and asks clarifying questions
  3. Individuals choose estimates from a deck of possible values (1, 2, 3, 5, 8, 13) and keep them private
  4. On a count of 3, the team shares their private estimates with each other
  5. Discuss differences and revote until we converge on one number

Planning Poker: Optimized

In order to further optimize this technique, we need to understand how mature teams using planning poker can exhibit waste in their process.  There are a few key areas where a good coach, ScrumMaster, or other facilitator will try to time-box the team to improve throughput: the user story overview, team discussions, and non-converging revoting.  These are the main areas that can exhibit waste (even on highly efficient Agile teams) because the criteria for when they are complete is not typically well understood.  Hopefully I can help change that!

Let’s optimize the user story overview first.  In order to test and validate the written communications of the team, ask that the story author read the story in full, which usually includes a narrative and perhaps some notes or preliminary acceptance criteria for completion.  For situations where a user story is little more than a title, offer the story author no more than one or two minutes (timed!) to explain the story, and then ask the team to hold all questions and comments.

In lieu of possibly wasteful discussions, require that the team produce a “rough draft” estimate based on the short overview they have already been presented.  This minor adjustment to the order of operations for planning poker eliminates limitless back and forth discussions that may or may not be adding value to the team’s ability to estimate the story.  Once the team has shared their “rough draft” estimates with one another, they may now openly justify their initial “rough draft” estimates, starting with the highest and lowest estimates.

All discussion at this point will be focused on answering the question “why was your number so high (or low)?”  As you might imagine, the team is now automatically guided toward the “right” discussion that is value added and will help the team to converge on the correct estimate in less time.  Arguments and debate about implementation strategy that does not change the effort estimate is eliminated.  In many cases, no discussion is necessary whatsoever!  A keen team leader will begin to take note of which stories required the most discussion and are therefore the most risky to develop.

Lastly, we introduce the rule that any team member, including those who are not voting, is allowed to call for a revote at any time.  This rule can be used when convergence is suspected, but the team continues to debate.  In the situation where the numbers are failing to converge, most practitioners will tell you to choose the larger number and move on, which is exactly what I recommend.

Here’s the optimized technique:

  1. Product Owner/story author reads the story aloud, or provides a timed 2 minute overview.
  2. Individuals choose estimates from a deck of possible values (1, 2, 3, 5, 8, 13) and keep them private
  3. On a count of 3, the team shares their private estimates with each other
  4. Discuss differences, ask clarifying questions, and revote until we converge on one number
  5. At any time, any individual may call for a “revote”

Tell me about the time you saved using this optimized technique in the comments!

Leave a Reply

Your email address will not be published. Required fields are marked *