Poker game concludes: Guess who won?

This sprint, our team experimented with a concept called Planning Poker.

Planning Poker is designed to assist the pigs (programmers and testers committed to the project) with schedule forecasting—Most scrum shops prefer the word forecast over estimates because it more-accurately describes the uncertainty in predicting software feature deliveries.

Following yesterday's Iteration Planning—once we knew exactly what features would be implemented in this sprint—we sat around a table following specific rules and using playing cards to forecast the results of this sprint.

Before I describe how the Planning Poker went, let me say to Scrum purist out there:

The team at Decade Software does not schedule one extremely long planning meeting. Ours is divided into four smaller meetings. The first is a requirements hand-off and clarification session hosted by the Product Owner. The second is an iteration planning meeting, where the team reviews what constitutes as a first iteration of the top items in the Product Backlog. The third session is referred to as our Sprint Planning Meeting. As with traditional scrum shops, this is where we decide what will and will not be committed to by the team. The fourth session this sprint was Planning Poker. We decided to experiment with this technique to establish the initial estimates that plug into Scrum for Team System, which produces our Sprint Burn-down Chart. Next sprint, the order of our third and fourth sessions will likely be reversed. Like any agile team, we are learning and refining our processes as we go.

Now, this is how our card game went...

I—as Scrum Master—selected a forecast-able use case (requested software feature previously provided by the Project Owner during the sprint hand-off session earlier that day), and the team reviewed what had been discussed regarding the selected use case during iteration planning—essentially reviewing what would and would not be done during the July sprint.

After that discussion, each forecaster (5 pigs selected as experts in the domain covered by the use case) turned a card face down. When everyone turned their cards face up, the typical range of forecasted points (each card has a point value) was discussed and defended until everyone agreed on a single forecast. This process repeated until all committed use cases had been forecasted.

As the session continued, participants collaborated by comparing previous forecasts use cases with new forecasts as a method of validation. All pigs participated in the discussion—not just the designated forecasters.

Even with one session of Planning Poker, this method has proven to be an efficient and fun way to forecast preliminary schedules without spending thousands of dollars creating Microsoft Project plans that usually do little more than support someone's guess.

So—to answer the question of "who won?"—the team did, of course.

I highly recommend that you give Planning Poker a try.