Thursday, August 02, 2007

Planning Poker

I wanted to share with you an idea that has been extremely successful for us at GenoLogics over the past couple months. A few months ago I finished reading Mike Cohn's Agile Estimating and PlanningIn this terrific book Cohn describes an estimating technique named "Planning Poker". Either this idea is older than I know, or it has really started catching on quickly, because I've begun seeing it in many other places. There's even an online tool to support its use with distributed teams.

So what is Planning Poker? Basically, it's a light-weight, loosely structured technique for group estimating. It draws on historical experience, group knowledge, and some very low-tech tools to keep the process moving.

In Cohn's book he introduces the concept as a tool to help estimate user stories. We have used it for that at GLS. However, we have taken the process a step beyond that and have begun using it to estimate all manner of issues, many larger than user stories.

In a nutshell, here's how it works at GLS.

A moderator (usually from Project Management) creates a list of items to be estimated. The more detail this person has ahead of time, the better.

The estimators (usually a group of five to seven people) sit down in a board room with their planning poker cards in hand (more on that in a minute).

An important note about the composition of these groups: it's best to have a broad representation of interests. We always have one or two people from QA, at least one of our Tech Leads, a couple developers who are familiar with the area being estimated, a member from Product Management (often the person who owns these requirements), and often someone from our Customer Service team. This is critical to make sure the estimates don't leave anything out.

The moderator reads out the description of the item being estimated. "The user should be able to search all experimental data using regular expressions" (or something like that).

A conversation ensues in which everyone asks for clarification, extra details where required, potential impacts to other features, documentation needs, testing implications, etc. For most things, this usually takes only a couple minutes. For extremely complex issues, this has taken us as long as twenty minutes.

The moderator then asks everyone to select their estimate using their cards. These cards contains the numbers 1,2,3,5,8,13 (a Fibonacci sequence). On the count of three, everyone shows their cards at the same time.

When estimating user-stories, these numbers represent "story points" and are relative sizes compared to other user stories completed in the past. When we use this technique to estimate larger items (when we're doing roadmap planning), we use these numbers to represent man-weeks of effort. When doing man-week estimates, the team is required to factor in design, coding, testing, regression and documentation into their totals.

The moderator then asks the estimators who held up the lowest number and the highest number (if necessary) to explain to the rest of the group the reasons for their choice. This step is critical to the whole process. It provides a way for those with divergent opinions to express what they are thinking and triggers additional questions among the group.

After a couple minutes of additional discussion, the moderator asks everyone to select their estimates again. On the count of three all cards are shown. If there is still significant disagreement at this point, the process returns to step 8. Often however, the estimates have nearly converged by the second round, and those that disagree will usually express that the majority view is acceptable to them.

Write the estimate down and go on to the next item.

Following this process we have estimated 25+ complex and significant items in under four hours. Previously those estimates would have been done by a small group of 1 or 2 developers, probably would have taken longer, and certainly would have glossed over or completely forgotten important aspects of each issue.

If you find yourself or your group struggling with estimating I strong suggest giving this method a try. It has worked wonderfully for us and I regularly hear our developers and Product Management people speaking in glowing terms about it. Perhaps the best part is that developers no longer dread estimating meetings because they moving quickly, they provide clear value, and to a degree they are even fun.