One of the techniques that many Agilists have been embracing is using planning poker to help the team estimate and plan for an iteration. The focus of today’s blog is that one of the nice benefits of planning poker is helping ensure a common understanding of the work (story) at a team level.
Brief Introduction to Planning Poker
Planning poker is generally used during the team iteration planning meeting to help the team create estimates for stories (feature requests). Each team member has as set of cards that are numbered based on a modified Fibonacci sequence (?, 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, infinity).
After each story is presented to the team, there may be a few questions regarding the story. The time spent asking and addressing these questions should be kept as brief as possible. At this point, this is not a design discussion, the questions should only relate to helping the team member form a rough order of magnitude estimate.
After the story is presented, all team members display their cards simultaneously. Once all the estimates are shown, the team can determine if there is a general consensus or agreement to the estimate for the story.
If all of the estimates are roughly in the same neighborhood, then the team is ok. You can optionally ask the highest and lowest estimates on what their thoughts are, but if they are in the same ballpark as the rest of the team, it is usually relatively easy to come to an agreement.
Example, if the ranges are a 3, a couple of 5s and several 8s, not a big deal. Have the 3 explain their thought and you’ll find they’re probably willing to go up on their estimate.
Note when everyone in the same ballpark, do NOT spend a lot of time discussing the story, you’re done estimating the story, go on to estimating the next story (or tasking the story, if your team tasks after each story, which I would NOT recommend).
However, if there is a large gap in estimates, this is where you get the good stuff. Say most of the team is around a 5, but one person has a 20, then something’s going on. Either the 20 does not have a correct understanding of the story (or what it takes to implement the story), or the 20 knows something the others do not. Either way, this requires discussion.
Examples 1 – technical implementation:
The story is “implement role based security model”. Most of the team throws an 8, however one person throws a 40. Discussion is held and the people throwing the 8 believe they can leverage an existing security model the company has. However, the 40 knows that the legacy security model is outdated and does not come close to supporting the needs of this project. The ensuing discussion helps bring this to light and the team re-throws based on this new knowledge.
Example 2 – Story understanding:
The story is “Display Custom Images in System”. Several of the developers throw a 100 and the business analysts throw an 8. Each is surprised at the other’s estimates. During the discussion, turns out the developers thought that the system needed the ability to actually create and save images while the true requirement was that the system only needed to display an image from a specified location.
The key point of this blog is that using this technique should allow the team to quickly breeze through estimating stories where there is a general consensus on the size of the story and ensuring there is a common understanding in situations where there is a large gap in estimates.
(Note that the common understanding is just one of the benefits of planning poker. There are also major benefits in terms of velocity and using velocity to help plan team capacity, but more on that in a future blog.)