XPlorations

XP123XPlorations → Release Planning (Feb. 2000)

Story Time: Release Planning February, 2000

This is a fictional episode showing release planning for a search system.

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.

Planning Game: Exploration Phase
Approach User Programmer
Goal: Understand what the system is to do, well enough that it can be estimated.

Method: User writes and manages stories. Programmer estimates stories (spiking when necessary). Continue until all stories wanted for the planning phase are estimated.

Result: Working set of estimated stories.

Write a Story
Usually on their own, but perhaps because the Programmer suggested one.

Split a Story
If the programmers don't understand it or can't estimate it.

Toss a Story
Because it's no longer wanted or because a split story covers it.

Estimate a Story
In ideal programmer weeks. If >3, User should split story.

Spike
Quick programming exploration of an issue, to enable an estimate.

 

Planning Game: Planning Phase
Approach Actions
Goal: Next release planned so it gives most bang for the buck.

Method: Do Actions 1 to 4.

Result: List of stories to be included in the next release (and some tentative understanding by User of future releases).

  1. User: Sort Stories by Value
    From high to low, or least labeled high, medium, and low.
  2. Programmer: Sort Stories by Risk
    From high to low, or least labeled high, medium, and low.
  3. Programmer: Set Velocity
    Declare how many story points (as estimated earlier) the user will get per "3"-week iteration. Velocity is empirically determined. If this is the first time, a reasonable guess is 1 story point per programmer per 3-week iteration.
  4. User: Choose Scope
    Choose stories for the next release. The total story estimates, divide by the velocity, tell how long it will take. (For the first release, the stories must exercise the whole system end-to-end, even if at a minimal level.)

 

Planning Game: Steering Phase
Approach Move, Trigger, Reaction
Goal: Manage ongoing development.

Method: When one of the triggers occurs, react to it as shown.

Result: Development managed over time, so User can continue to maximize value given what's learned during development.

Move: Iteration
Trigger: Start of iteration
Reaction:
  1. User picks one iteration worth of stories from release plan.
  2. Programmer implements them.

Move: Reset Velocity ("Recovery")
Trigger: Programmer realizes velocity is wrong.
Reaction:
  1. Programmer re-estimates velocity.
  2. User can defer (or split) stories to maintain release date.

Move: New Story
Trigger: User identifies new, more valuable story.
Reaction:
  1. Programmer estimates story.
  2. User can remove estimated points from incomplete part of existing plan, and insert the new story.

Move: Re-Estimate
Trigger: Programmer feels the plan is out of whack
Reaction:
  1. Programmer re-estimates velocity and all stories.
  2. User can set new scope plan.

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:

Given a query, return a list of all matching items. Look at the details of any items.

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:"

Query by author, title, or keyword.
Use Z39.50 [ANSI standard for searching library catalogs].
Support Z39.2 MARC document format [ANSI standard].
Support simple text document format (SUTRS) [From Z39.50].

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:

Use a graphical user interface.
Allow sorting of results (e.g., by author or title).

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."

Z39.50 systems can either let you look at quick information (e.g., title, author, year), or you can see the whole thing. Instead of always showing the full item, allow drill-down from results to individual items.

Programmer: "2 weeks".

Don't make me drill down if the result has only one item.

Programmer: "1 week".

Allow for saving of results to a file.

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".

Print whole list of results or individual items.

Programmer: "2 weeks".

Allow saving of queries.

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".

Support boolean queries ("and", "or", and "not").

Programmer: "3 weeks".

Configure what library we're working with.

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:"

System can run on a PC. Nice if it could run on Unix and Mac too.

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".

Typical query is answered in 15 seconds or less.

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:

  High Value Medium Value Low Value
High Risk Z39.50 (3) Boolean (3)
Sorting (2)
 
Medium Risk Query (2)
MARC (2)
GUI (2)
Drill-down (2) Print (2)
Low Risk Performance (1) SUTRS (1)
Config (2)
Portable (1)
No-drill (1)
Save Result (1)
Save Query (1)

[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

[Written 2-18-2000.]

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