First, let's consider a traditional approach:
By contrast, the XP approach emphasizes testing and customer involvement:
The Programmers get to decide: [ibid.]
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
Roughly half of these involve the Customer's role. We'll look at these practices in particular:
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.
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
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:
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.
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.
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.
ExplorationRelease 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:
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
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
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 PhaseIteration 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.
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:
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.
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
By the end of the iteration, you'd like all tests to pass,
although it won't necessarily be so.
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 PhaseAccept 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.
Relax and explore a little before jumping in to the next
ConclusionWe'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.
Finally, we considered the phases of an XP project, and the
activities of the Customer in
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
Copyright 1994-2010, William C. Wake - William.Wake@acm.org