XPlorations

Release Planning

The goal of release planning is to identify a version of the system suitable for the next release, and to get some idea of future releases. This planning has a horizon of typically 1-3 months.

Release planning in XP is done through the "Planning Game". The idea is that there are two players, User and Programmer. The tokens are the user stories, written on file cards. The game has three phases: exploration, planning, and steering. There are various moves the players can make, depending on the phase.

For the following example, we'll go through the exploratory and planning phases.

Vision

First, we need some sort of overall vision for the system.

Vision: Produce a system able to search an electronic library card catalog.

We might hope for a little more on why we want to do this, and how we think our system will be better than others, but it's a reasonable starting point for now.

Exploratory Phase: Writing and Estimating

We'll begin the planning game by asking the user to start writing stories. They write a card:

The Programmer look at this story and try to estimate it, but they come back and say "it's too big". The User says, "Let me split it into a few cards:"

The user says, "There might be other formats later, but those two are only ones I know we need."

The Programmer will estimate the stories. We'll assume the team has some familiarity with Z39.50 and the ASN.1 standard it uses. But they may decide to do a quick spike: they already have a tool to handle the protocol encoding, so one pair might attempt to do a simple "login" connection to a Z39.50 system. Another programmer might research the MARC format, and code up a quick tool to parse a record. Someone else might look at SUTRS. Another pair might try to encode a simple query. (With luck, the programmers might have been able to do some of this investigation before the planning game, or part of the team may have been hired for expertise that can take most of the problems into account.)

After the investigations, the Programmer says: "Queries: 2 weeks; Z39.50: 3 weeks; MARC: 2 weeks; SUTRS: 1 week."

Meanwhile, the user has been coming up with a couple more stories:

User: "We'd like a graphical user interface so it's easy to use." Programmer: "For what you've described so far, 2 weeks."

User: "Not all libraries can sort, but we'd like to take advantage of those that can." Programmer (after some quick investigation): "2 weeks."

Programmer: "2 weeks".

Programmer: "1 week".

Programmer: "What's this for?"
User: "It lets other programs see the results; the user can share the file with friends, use it in a document, etc."
Programmer: "1 week".

Programmer: "2 weeks".

Programmer: "How is this different from saving the results?"
User: "You won't get the same result every time you search with the same query."
Programmer: "What?!?!"
User: "Libraries buy new books every day. Some people like a standing query that they can run just to see 'what's new?'.
Programmer: "Oh - OK. 1 week".

Programmer: "3 weeks".

Programmer: "What kind of configuration information do we need?"
User: "It's similar to a URL on the web: host, port, and datababse name. Some users use the same library every time, but others use a variety. We'd like the users to be able to have a list of libraries."
Programmer: "2 weeks".

Programmer: "How about a few more stories - one about what types of systems we should run on, and one about performance?"
Customer: "Good idea. Here you go:"

Programmer: "Our programmers are familiar with C++ and Java, and both those could be used. Here are some tradeoffs... [Mercifully omitted] If you want to go with C++, we'll need to split the story because the system-specific parts will make it take longer than 3 weeks to accommodate it. If you're willing to go with Java, we estimate 1 week." (To arrange for multiple machines, and development and testing environments.)
User: "We'll take Java then."
Programmer: "Could you put that on the card?"
User: "OK".

The programmers go do a quick spike, using a "quick" GUI and a simplified system. It appears that the bulk of time is spent waiting on the network. They tell the users "1 week". (This allows for some time to establish a performance monitor tool, and for performance tuning.)

Planning Phase: Sorting and Selecting

The User sorts by value, the Programmer by risk:

[When I look at this table, one thing I notice is that all the high-risk stories seem to be the ones with the 3-week estimates. That's probably natural, but if I noticed this in reality, I'd probably encourage the team to think about it a little, to see what they could do to reduce the risk, maybe encouraging the users to split the risky stories.]

Development says, "The velocity is 6, meaning you get 6 estimated points per 3-week iteration with our team."

The User says, "I know we need a minimally functioning system as soon as possible. These are the stories I choose for the first release:"

• Z39.50
• Query
• MARC
• GUI
• Performance
• SUTRS
• Config
• Portable

(Notice that this is all the high-value items, and some select medium-value items.)

At this point, development could proceed (beginning with iteration planning).

Steering Phase

We'll talk about Iteration Planning another day. The other parts of the Steering Phase are activities we've already discussed.

Conclusion

We have:

• Described the Release Planning process, as embodied in the planning game, and organized into exploratory, planning, and steering phases.
• Developed and estimated a number of stories, demonstrating the exploratory phase.
• Sorted stories, and selected stories for the release plan, demonstrating the planning phase.
• Deferred a discussion of iteration planning.

References

• Extreme Programming Explored, by Bill Wake. This article is the basis for chapter 7.
• Extreme Programming Explained: Embrace Change, Kent Beck, 1999.
• Wiki PlanningGame
• Agile Project Management, XP Style
• Distortions in Velocity

[Written 2-18-2000.]

Copyright 1994-2010, William C. Wake - William.Wake@acm.org