Posts made in May, 2013

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: Product Owner/story author explains the user story to be estimated Team discusses the story and asks clarifying questions Individuals choose estimates from a deck of possible values (1, 2, 3, 5, 8, 13) and keep them private On a count of 3, the team shares their private estimates with each other 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...

Read More