Extreme Programming: How to plan for iteration

In my previous article, I outlined the planning stages that are performed during an XP project, with a particular emphasis on the upfront planning that is ignored in many “XP” projects. This month I want to talk about planning at the other end of the spectrum – how we decide the content of a particular iteration, using the Planning Game.

Fundamentally, the Planning Game is about creating an environment where two things happen:

• Business people make business decisions
• Technical people make technical decisions

You might feel that we don't need to do anything special to ensure this happens, but situations where exactly the reverse occurs are actually common. Consider this conversation between Sales and Development:

Sales : “I need you to implement the ten features on this list. How long will it take?”
Development : “It looks like about ten weeks work”
Sales : “I've promised the customer it will be done in five weeks, so you'll have to do it in five”
Development : “Ok, I'll see what I can do”

This conversation is dysfunctional at a number of levels, but two things have gone wrong. First, Sales decided how long something would take to develop, which should be a technical decision. Secondly, in all likelihood Development won't get everything done in five weeks, so they'll need to decide what to do first.When development does this, they are prioritising features, which should be a business decision. You can decide how often conversations like this one occur in your workplace.

In an XP project, prioritisation and commitment levels are determined during the Planning Game, which occurs at the end of each iteration. The steps in the planning game are:

1. Note the number of story points completed in the previous iteration
This will be the commitment level, or velocity, for the next iteration. Assuming that the next iteration will be like the previous iteration is called using “yesterday's weather”, because on average the weather today is 76% likely to be the same as the weather yesterday (thanks to my friends at the New Zealand Met Service for this statistic). The experience of XP teams is that the inherent uncertainty in each iteration swamps any theoretical improvement you might get from more sophisticated (and more time consuming) approaches. If there are macro changes between iterations (e.g. half the team is on vacation next iteration), then certainly take this into account, but don't sweat the small stuff. In particular, if you add people to the development team, don't assume in advance that there will be an improvement in velocity. Instead, wait to see what happens and then increase the velocity to match the observed change – there may be a slight lag, but that's one of the reasons we keep iterations short.

2. Customers choose stories for the next iteration
Once the velocity is determined, the customer chooses the stories for the next iteration. They should do this based primarily on business value, but risk management is a factor as well. Each story already has a cost in story points, and the customers are free to choose any stories, whose estimates sum to the iteration velocity. If there are dependencies between stories, these are noted and need to be taken into account, but having story dependencies should be the exception rather than the rule.

3. If there are too many points, the developers ask a customer to split a story
Sometimes it's impossible to make the existing stories sum to the iteration velocity (e.g. all the remaining stories are 3 points, and the iteration velocity is 10 points). In this case, the customer needs to split a story into smaller parts, each of which still has some business meaning. For example, if our original story is “Enter customer details”, we might split it into “Enter corporate customer details” and “Enter personal customer details”.

4. Estimate any new stories
After the story is split, the developers estimate the new stories. Splitting the story may reveal new requirements, or show that some aspects of the story aren't required at all, so there's no compulsion for the new estimates to add up to the previous estimate.

5. Stories are split into technical tasks
Since stories are described in business terms, someone needs to break them down into corresponding technical tasks. In an XP project this is done by the development team as a whole, during the planning game. There are multiple ways that a story could be broken into technical tasks, and choosing between them is a design activity. Often this step reveals some uncertainty that needs be resolved in cooperation with the customer.

6. Developers take responsibility for technical tasks and stories
Once all the stories have been split up, each developer chooses which tasks they will be responsible for. The simple rule for my team is that we don't leave the room until everything is covered, though there are certainly some subtleties to how this occurs. Tasks have points associated with them as well, but they are determined by the individual who takes responsibility for the task, and are only used by the developers to balance their personal load – to make sure they aren't signed up for too much or too little.

Now we're ready to start the iteration.

This describes the simplest form of the planning game. Real projects certainly encounter issues that I simply don't have space to cover here. Rest assured that XP projects have mechanisms for dealing with both under and overcommitment, at both the team and individual levels, and for tracking progress within an iteration. As I hope I conveyed in my last column, planning is a integral part of every XP project.

Steve Hayes is the Software Development Manager at Internet Business Systems (IBS). IBS provides agile methods consulting and development services, and browser hosted solutions to the financial services industry.