XPlorations

XP123XPlorations → Customer in XP (June 2000)

How to Be a Customer of XP Software June, 2000

Extreme Programming ("XP") is a fairly new software development methodology. We discuss these three aspects:
  • XP is a Different Approach
  • XP Practices
  • Customer Activities

XP is a Different Approach

Extreme Programming ("XP") is a fairly new software development method. It brings together a number of practices that help a team perform at maximum speed.

First, let's consider a traditional approach:

The user's group arranges with the development group to have an analyst assigned for a project. Over a series of weeks and months, the analyst meets with the users for several hours a week. The analysts produce a set of documents, perhaps including things like a Vision Statement or Use Cases. The users (and perhaps the programming team as well) review these documents and negotiate a release. The programmers take this information, and several months later produce a system that more or less does what it was intended to. It's often a close call at the end, as people find out what they missed, and realize what's changed since the documents were written. In the end, the customers come in to do a user acceptance test, and the system is released. Often the whole process took longer than anybody had expected, and the quality is not where the users want it.

By contrast, the XP approach emphasizes testing and customer involvement:

The Customer contacts an XP development group to start a project. An XP team insists that the Customer sit with their team the whole time they're developing. An XP project typically has three phases:
  • an exploration phase, where the Customer writes stories, the Programmers estimate them, and the Customer chooses which stories will be developed;
  • an iteration phase, where the Customer writes tests and answers questions, while the Programmers program; and
  • a release phase, where the Programmers install the software, and the Customer (hopefully) accepts the result.
The Customer in XP has frequent opportunities to change the team's direction if circumstances change. Because testing is so prominent, the Customer is aware of the project's true status much earlier in the cycle.


Extreme Programming believes that there is a fundamental split in the roles of Customer vs. Programmer. The Customer owns "what you get" while the Programmer owns "what it costs". This shows up in who gets to make which decisions. The Customer gets to decide: [summarized from Extreme Programming Explained, p. 55]
    Scope - what the system must do
    Priority - what's more important
    Composition of Releases - what must be in a release to be useful
    Dates of Releases - when is the release needed.

The Programmers get to decide: [ibid.]
    Estimated time to add a feature
    Technical consequences - Programmers explain the technical consequences of choices, but the Customer makes the decision
    Process - how the team will work
    Detailed Scheduled - within an iteration

The practices of XP help enforce this split. This division of responsibilities helps keep the whole team on track, by making the consequences of decisions be very visible. For example, if a Customer wants a report this week, the XP team is happy to provide it. They'll outline any technical risk, and estimate what it will cost. Then the Customer gets to pick what will be dropped to make time for the development.

What happens if there's a conflict? What if the Customer wants these features by this date, and the Programmers estimate that it will take longer than that? XP provides several options: the Customer can accept less scope, the Customer can accept a later date, the Customer may spend time or money exploring an alternative, or the Customer can find a different programming team. What XP doesn't let you do is say, "Let's try anyway - we'll catch up later."
 

XP Practices

Extreme Programming has a number of key practices. In Extreme Programming Explained, Kent Beck identifies these:
 
  • Planning game
  • Small releases
  • Metaphor
  • Simple design
  • Testing
  • Refactoring
  • Pair programming
  • Collective ownership
  • Continuous integration
  • 40-hour week
  • On-site customer
  • Coding standards

Roughly half of these involve the Customer's role. We'll look at these practices in particular:

On-Site Customer

In XP, the customer will sit with the team full-time. They'll write tests, answer questions, and set priorities. Having the customer with the team is crucial in helping the team go as fast as possible.

I once worked with a cross-functional team that had moved into one large room for a key project. In the "lessons learned" session, a manager of the marketing group said he thought the experience was great, that he was answering questions right when they came up and he could see the progress. He admitted that when he was back in his office, he'd get a voicemail, and he'd put off answering for a day or two. (Meanwhile, the developers either made a guess, or worked on something less important.)

It takes many decisions to develop software. If a team can get its answers or decisions in minutes instead of hours or days, its speed will be much higher.

XP is not the only approach that recognizes the value of an on-site customer. Tom Peters says: "Make clients an integral part of every project team." [The Professional Service Firm 50, p. 105] and "If the client won't give you full-time, top-flight members, beg off the project. The client isn't serious." [ibid., p. 106].
 

Planning Game

XP uses the notion of a planning game for planning the release (weeks to months) and for planning iterations (1 to 3 weeks). The planning game uses two players, and defines which type player can make which move. In this way, the process maintains a critical division of labor: Customer determines value, Programmer determines cost.

In the release planning game, the goal is to define the set of features required for the next release. It is centered around user stories. The Customer writes them, the Programmers estimate them, and the Customer plans the overall release. The iteration planning game is similar. The Customer chooses the stories for the iteration, and the Programmers estimate and accept the corresponding tasks.

Both games help make development tradeoffs explicit. If the Customer wants more stories, it takes more time. If they want the stories sooner, they have to give up scope. The games help clarify roles: Customers aren't permitted to make estimates, and Programmers aren't permitted to choose which features come first.
 

Testing

XP uses testing two ways: Customers develop acceptance tests that determine the overall behavior of the system, and Programmers create unit tests while programming.

As a Customer, you'll create tests for each story you request. You'll measure the progress in developing the system by running these tests. The Manager who is tracking development may maintain a graph showing how well the system is doing over time. For example:

Acceptance tests improving over time

Having to write your own tests is a challenging experience. An XP team might have a Tester or Programmer who will work with you (you specify - they implement), but you own the tests.

In many development approaches, the customer is expected to help specify the requirements, and one of the attributes of a good requirement is that it is testable. XP moves this testing toward the front of the development process. You may find that when you write a story, you're challenged to explain what the test will be like. This is healthy - it means the Programmers want to do what you want.

During development, Programmers will come to you with questions, which are either to get information they need, or to get you to make a decision. When you provide an answer, find a way to make a test that will tell you whether they've followed your answer.

Finally, you should strive to have your tests automated. This may mean spending some task development points, but you'll find it's worthwhile. You don't need a fancy screen - just a way to specify the inputs and the expected result. Some teams have been able to use spreadsheets for this: the user has a familiar interface, and the Programmers can read the spreadsheet with a small program to run the test.
 

Metaphor

The metaphor in XP is a conceptual framework for talking about your solution. You and the Programmers will seek a metaphor that will give you a shared vocabulary and a mental picture of the system. If you don't find one, you'll use the "naive metaphor", using the vocabulary of your problem domain.
 

Small Releases

XP specifies that releases should be as small as possible. An XP team is trying to learn, and the more feedback they get (especially from actual use), the better. Although the release should be small, it needs to make sense: only "whole" features should be included.

Projects that don't release for months and months, or even years, accumulate a lot of risk - technology will change, the business environment will change, the team will change. Targeting small releases reduces this risk.
 

40-Hour Week

Finally, XP teams maintain a 40-hour week. Too many teams have taken the short-term expedient of requiring lots of overtime, only to pay for it in increased bug rates, increased turnover, and increased overall cost. An XP version of the rule for 40-hour weeks is "Don't work two weeks of overtime in a row." Occasionally, a little extra time might be important. But if it's needed week after week, it indicates a systemic problem.

Be sensitive to this rule. Expect pushback when you want something "right now": expect the answer "what do you want to give up to get it?" Keeping your team well-rested will pay itself back many times over the project's life.
 

Customer Activities on an XP Team

We'll talk in more detail about the activities in the three phases:

Exploration:
    Release Planning Game
    Write a Story
    Split the Story

Iteration:
    Iteration Planning Game
    Answer Questions
    Write Acceptance Tests
    Run Acceptance Tests
    Steer the Iteration

Release:
    Accept the Release
    Celebrate the Release
 
 

Exploration

Release Planning Game
During the exploration phase (typically 1 to 4 weeks), the team works together to play the release planning game. This game embeds the rights of Customers and Programmers into the rules. You can think of the game as looking like this:

Release planning game

Customers Write a Story. The Programmers try to estimate it. If it's too big, they pass it back to the Customer to Split the Story. If the Programmers don't know how to implement it, they do an investigation called a spike. If the Programmers think the story will take 1 to 3 story points ("weeks") of work, they pass it to the customer to sort. (Story points don't correspond exactly to real weeks: the Manager will let you know how many story points to expect the team to accomplish per iteration.)

To sort the stories, the Customer arranges them in order of importance (most important first). To indicate what will be in the release, the Customer will clip the back cards together: everything before the clip is planned to be in the release. For best results, make the release as soon as possible.

The unclipped stories tell you the due date as well: knowing the total story points and the number of story points per iteration will tell you how many iterations. If you're trying to hit a particular date, you may need to include fewer stories; if you're trying for a particular set of stories, you'll have to be flexible on the date.

If you don't like what you're getting, you have a few options: change the stories, accept a new date, change the team, or work with a different team entirely.
 

Write a Story
To write a story, take a blank file card and write "Story: story title" on the top. Add a short paragraph describing some feature of the system. (Try to keep it small enough that the Programmers will estimate 1 to 3 story points.) Give the card to the Programmers to estimate.

If you need to, cite or attach supporting materials. A story card doesn't need all the details though - it's as much a promise to discuss a feature as a description of it.

Remember that the story must be testable. And since you're the one specifying the tests (later on), this means you have to know how to test it.
 

Split the Story
You may want to split a story for more flexibility, or because the Programmers say it is too big for them to estimate. (If the Programmers want it split, you have to split it, even if it doesn't sound that bad to you. Smaller stories tend to be less risky, so it's worth the trouble.)

Take the original story card. Write two or more new story cards, each simpler than the original, that when taken together cover the original story. Rip up and throw away the original card. Give the new stories to the Programmers to estimate.
 
 

Iteration Phase

Iteration Planning Game
On the first day of each iteration, the team will decide which stories to focus on.

The team accomplished some number of story points in the previous iteration. (For the first iteration, assume 1/3 story point per programmer per week.) Select as many story cards as you'd like, provided they add up to that many story points or fewer. The stories don't have to be in the order they were in the release plan; you can request them in whatever order you like. In fact, you can introduce new stories if you're willing to give the team time to estimate them.

Iteration planning game

In the first phase of the game, read each story card, and work with the team to brainstorm the tasks it might involve. At the end of this phase, the Programmers will have a pile of task cards, corresponding to the story cards you selected. (A given task may support many stories.)

The second phase is mostly the Programmers' job. They will select the tasks, estimate them, and accept the ones they will perform. In addition to conversations to clarify what you need, you may be involved in this phase for two reasons:

  1. If they can't fit in all the tasks, they'll ask you to defer or split a story.
  2. If they have more time than tasks, they may ask you add in another story.
Finally, the team has developed an iteration plan, that will complete your set of stories. You have four jobs during the rest of the iteration:


Answer Questions
One of the main reasons you're an on-site customer is so you can answer questions for the Programmers while they're implementing tasks.

When they ask, either answer or promise to find out (and do so quickly). This feedback cycle of minutes instead of hours or days is one of the key things that lets an XP team move quickly.

Many questions are not questions of fact: they require you to make a decision. Your decisions are important: they're how you get what you need.

Once you've answered a question, you'll want to keep track of your answer. The best way to do this is to Write Acceptance Tests or (more rarely) Write a Story.
 

Write Acceptance Tests
For each story in the iteration, determine what you would need to know to be confident that the story was properly implemented, and write a test to verify it. Progress in the iteration will be measured against the tests, so the sooner they're available, the better.

In the simplest form, a test will be a card with the title: "Test: test-title FOR story-title", containing information about the test. In a better case, you may be able to specify the test in a spreadsheet; you may want to spend some story or task points to get a tool to run these tests automatically. Alternatively, you may have a Programmer or Tester who will help - you specify the test, and they'll implement it.

When you're designing tests, think about the input and the expected result. (You need to capture both.) Test both what should happen when things are right, and what should happen when they go wrong. For example, a word processor test might specify what happens when the disk is full. It can also be revealing to have tests that are at a boundary condition and on either side of it. For example, if you're allowing numbers 1-99999, try 0, 1, 2, 9998, 9999, and 10000 as test values. (There's certainly a lot more to testing than this brief introduction.)

Try to keep your tests fairly independent of each other: when one test breaks, you don't want too many problems to look at. If they're independent, you can run them in any order, without a lot of setup.

Acceptance tests are crucial: they're your "gauge" so you can measure how good the program is.
 

Run Acceptance Tests
Every day, run the acceptance tests for all stories to be completed by the end of this iteration. Let the team know which tests pass and which fail. The Manager will keep a Big Visible Chart (described earlier). After you run these tests by hand a few days, you'll see why you might prefer automated tests.

By the end of the iteration, you'd like all tests to pass, although it won't necessarily be so.
 

Steer the Iteration
You have three key opportunities to guide the team:

  1. Release planning: you choose what's in, what's out, and the date.
  2. Iteration planning: you choose what stories are in this iteration.
  3. On the fly (within the release): you choose what the team does right now.
There will be times when you need to adjust the plan. Perhaps the development team is not progressing as quickly as planned, and they need to drop some features for the iteration. Given the team's progress, the Customer decides which story is more crucial, or whether a story can be meaningfully split.

Or, there may be a change in business conditions. Perhaps marketing has identified a killer feature that would enable sales to book many orders if only it were available by the show date. In this case, you can introduce the new story, get it estimated, and re-prioritize the team's activities. You prefer not to interrupt an iteration in progress if you can avoid it, but if you ask, the team will set aside - or throw away - what they've done, and devote themselves to the new features.
 

Release Phase

Accept the Release
As you get closer to the end of the release, the Programmers will be handling the final tasks of installing the software. Once they're ready, you'll want to run the acceptance tests one last time, along with whatever else you need to be sure the software is ready to go live.

When the software is in, and you're satisfied, take a deep breath and declare, "We accept the release." Notify anybody who needs to know.

Celebrate the Release
You've hit a major milestone: releasing the software. The Manager will arrange an appropriate celebration, inviting all who helped create this success.

Relax and explore a little before jumping in to the next release.
 

Conclusion

We've explored several aspects of the role of the Customer in Extreme Programming.

First, we considered the things that make XP a different approach, including the presence of an on-site customer, and the way Customers define value while Programmers define cost.

Next, we looked at several of XP's practices, and how the Customer is involved in them: On-Site Customer, Planning Game, Testing, Metaphor, Small Releases, and 40-Hour Week.

Finally, we considered the phases of an XP project, and the activities of the Customer in those phases.
    Exploration: Release Planning Game, Write a Story, Split the Story.
    Iteration: Iteration Planning Game, Answer Questions, Write Acceptance Tests, Run Acceptance Tests, Steer the Iteration.
    Release: Accept the Release, Celebrate the Release.

I hope this introduction has encouraged you to explore Extreme Programming more deeply. The key starting point would be Kent Beck's Extreme Programming Explained. Another book out now is Extreme Programming Installed by Jeffries et al. Finally, there are two online places to get information (although they tend to be populated more by Programmers than Customers): http://c2.com/wiki?ExtremeProgrammingRoadmap and http://www.egroups.com/group/extremeprogramming.

Resources and Related Articles

[Written 6-10-2000.]

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