The Planning Game

Plans are useless. Planning is priceless

Release Planning

The above poster shows a real-world Release Plan. The team has provided estimates for all 11 stories on the poster. Each story is estimated in team weeks . A team week is the amount of time it will take for the whole team to complete each story. If only 2 people on a 10-person team are capable of completing a given story (i.e. the other 8 don't have the knowledge to work on the story), then those 2 people represent the whole team when they estimate the story. In other words, the whole team is whoever on the team can help complete a story.

The estimates for the above poster add up to 6 months of work. It is also customary to create 3-month-long Release Plans. During the Planning Game, the team decides how long they would like a release to be. It is common to plan for multiple interim releases before getting to a production release . This requires that Customers produce enough stories for numerous release plans.

To estimate a story, a team discusses the story with Customers. This often leads to breaking the story into smaller pieces to understand what is involved in implementing the story. When the team feels confident, they estimate the story in terms of team weeks and repeat the process for all remaining stories.

Customers must select which stories to include on their Release Plan. This typically involves a good deal of prioritization. If the Customers have chosen to do a 12-week-long interim release, they can only choose 12 weeks worth of stories for the Release Plan. If they don't like the estimate on a story, they may question and debate the estimate, yet it is ultimately up to those who will be implementing the story to provide the final estimate for the story.

The “game” part of the Planning Game occurs when the Customer, who is given a certain budget, like 12 weeks, must choose which stories to pick from a pile of stories that may add up to something like 31 weeks worth of team work. Getting from 31 down to 12 involves discussion, reducing scope on stories, splitting stories, and deferring stories to a later release.

Once a Release Plan has been created, it is ready to be updated! This follows the philosophy that plans are useless, while planning is priceless.

So a Release Plan is not something set in stone. It will change during the release. Either more important stories will be added to the plan and less-important stories will be dropped from the plan, or, based on calculating how much work has been completed mid-way through the release, the team will realize that it can accomplish more or fewer stories than already appear on the plan. It is the job of Customers to see that the Release Plan provides the most accurate picture of what the team can accomplish.

Iteration Planning

Iteration Planning is similar to Release Planning. A typical iteration is either 1- or 2-weeks long. Instead of using team weeks to estimate stories on an Iteration Plan, the team uses NUTs. What's a NUT? A NUT is a Nebulous Unit of Time. How big is that? It's between the size of a pistachio nut and a coconut:

We estimate Iteration stories in NUTs because we don't know how much work can get done during our initial iterations. We begin with an estimate – we can do 20 NUTs per iteration. Huh? What's a NUT? Don't worry, we don't know yet. We'll know as soon as we begin measuring how many NUTs we do per iteration.

During Iteration Planning, Customers, who have already prioritized their needs on the Release Plan, choose which stories they'd like to have implemented during the 1- or 2-week iteration. These stories tend to be smaller versions of the stories on the Release Plan. The team estimates these stories in terms of NUTs. This story will take 1 NUT (which means it seems easy), while that one will take 3 NUTs and that one, which is really complex, will take 5 NUTS.

If the team's initial velocity is 20 NUTs, Customers can only choose stories that add up to 20 NUTs. They can question estimates, split stories and defer stories to a later iteration.

If little discussion occurs, and Customers simply pick stories that add up to 20 NUTs, it's likely that Iteration Planning isn't going well. Customers want as much functionality programmed as possible per iteration. If they simply accept every estimate, without any questions, it's likely they'll get less functionality than they could get, for estimates are often wrong or off due to misunderstandings about what is required. In other words, discussion and negotiation are essential to good planning.

After an iteration, we measure how many NUTs we accomplished. There are two ways of doing this: the black and white way or the gray way. The black and white way says that if a story was not completed (which means it was not accepted as complete by the Customers) no NUTs are counted for it. The gray way looks at what percentage of a story was completed – if one half of a 2-NUT story was completed, we count 1 NUT as having been accomplished. Using either the black and white or gray way of accounting for our work, we total the NUTs completed during the iteration. Say it is 14 NUTs. We then use 14 NUTs as our budget for the next iteration. This means that Customers get to choose stories that add up to 14 NUTs on the Iteration Plan.

How do NUTs correlate with the Release Plan? They don't. If you want to know how accurate your Release Plan is, have the team re-estimate the stories in team weeks. If they've already accomplished a lot of work in several iterations, the Release Plan will no longer contain 12 weeks worth of work.

Further Reading