Click here to view the complete list of archived articles

This article was originally published in the Winter 2002 issue of Methods & Tools

---

Extreme Programming as Nested Conversations - Page 2

William C. Wake, http://www.xp123.com

The Month-Scale Conversation

The whole project looks like this:

Release planning | Iteration | … | Iteration | Release

The conversation begins with an iteration or two of planning, and ends with a release to the end users.

To decide what will go into a release, the team will create a release plan. This plan shows, for each iteration, what features the system should have.

To create this plan, the customer will create stories—brief description of features, written on index cards. Here is a sample story card:

Create account

Enter desired username, password, & email address. Re-try if already in use.

The customer describes the story, but not every detail is necessary at this time. Rather, the conversation needs enough detail that the programmers are comfortable giving a ballpark estimate.

There will be a lot of conversation, but it won’t be all talk for the week or two. The programmers have several jobs during this exploratory time:

• estimate how long each story will take to implement
• make quick experiments, known as spikes, to better inform the estimates programmers will assign
• set up the development and test environment
• create a super-simple skeleton version of the application, to demonstrate the pieces working together. (For example, a web-based course registration system might have one web page with a simple form of one field, sent to a back end that looks up one thing in the database.)

Most XP teams use a simple relative scale for the stories: 1, 2, 3, or "too big." (These numbers are often called story points.) It’s helpful to have a rule of thumb as a starting point; you can use "one point = the team for a day" or "one point = a programmer for a week." But mostly, the stories will be compared against each other: "Is this one about as big as that one? Do we understand how to do it?" If a story is too big, the customer (not the programmers!) will divide it into two or more smaller stories until it can be estimated.

Using relative estimates is a little unusual, but it does have some benefits. It lets teams estimate stories by their "inherent" complexity, independently of the details of who will do exactly what part of the work. Furthermore, teams are often better able to start by saying, "these are about the same size" than to estimate a story’s absolute cost. The team’s ability to implement stories may change over time as a team learns and changes, but the relative costs of many stories will tend to stay the same.

The customer will write stories until they feel they’ve explored the possibilities enough to make a plan, and the programmers have estimated each story.

Given the estimated costs, the customer ranks the stories from most important to least. The programmers give an estimate of velocity: the number of story points they believe the team can implement per iteration.

The customer will arrange the stories into columns, with "velocity" points per column. The number of columns is determined by the number of weeks the customer (or management) wants to go until release. If all the stories don’t fit, the customer can either defer them to a new release, or adjust the planned release date. (For most customers, it’s better to drop features rather than slip a date.)

Here is a sample release plan, for a team with a velocity of four points/iteration:

Release Plan
Iteration 1 List courses (1) Enroll in course (2) Summary report (1)	Iteration 2 Create account (2) Login (1) Show schedule (1)	Iteration 3 Drop course (1) Manage courses (3)	Iteration 4 Fees (2) Logout (1) 1-sec. response (1)

This is a plan, not a commitment. It will change over time.

Until the release, the team engages in iterations. We’ll look at the iteration-level conversations next.

Key Points – Month-Scale Conversation The customer describes stories. The programmers estimate stories (1 to 3 story points). The customer sorts stories by priority. The programmers estimate velocity (points/iteration). The customer creates a release plan. The team performs iterations, then releases.

Week-Scale Conversations: Iterations

A release plan is a high-level plan; it’s not detailed enough for a team to work from directly. So, an iteration begins by creating an iteration plan. This is similar to a release plan, but at a finer level of detail.

The team first asks, "How many story points did we complete in the last iteration?" The team will plan for that many points for this iteration. This rule is known as Yesterday’s Weather, on the theory that yesterday’s weather is a pretty good predictor for today’s. (For the first iteration, the team can use the velocity estimate from the release plan.)

The customer selects the stories for the iteration. The customer needn’t select stories in the order used for the release plan; they can pick whichever stories have the most value given what they now know. They might even have new stories for the team to estimate.

The team then brainstorms tasks, to form an iteration plan. For each chosen story, the team lists the tasks that will implement it. One of the tasks should be "run customer test" (or the equivalent), as the customer’s criteria determine when the story is done.

Here is a sample iteration plan:

Iteration 2 Plan Create Account (2) Account table with user, password, email Web page Servlet – check dup acct, create it Run customer test Login (1) Lookup account, create cookie Web page Run customer test Show Schedule (1) Web page (result table) Servlet – lookup courses for logged-in user Run customer test

Individuals then sign up for tasks. Some teams assign all tasks at once, others sign up as the iteration progresses. In either case, you should be able to look at the chart and know who’s doing what.

Note that "Run customer test" is a task for each story. One of the jobs of the customer is to specify a test for each story. Ideally, the tests are ready even before iteration planning, but they need to be done before a "completed" story can be counted. Ron Jeffries describes requirements in XP as having three parts, "CCC" –Cards, Conversations, and Confirmation. Customer tests provide the confirmation. (Recall that "customer" may be a team including professional testers. The customer need not implement the test, but should specify and own it.)

Once we have a plan, the conversation shifts down to daily activities. At the end of the iteration, the team will deliver the application to the customer for final assessment of the iteration’s work.

Key Points – Week-Scale Conversation Use Yesterday’s Weather to determine the velocity to use. The customer selects stories adding up to "velocity" points. The team brainstorms tasks. The team signs up for tasks. The team does daily activities, and delivers the result of the iteration.

Page 1    Page 3   Back to the archive list