Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Chapter 1 Extreme Programming . . . . . . . . . . . . . . . . 9
Extreme Programming is a discipline of software development with values of simplicity, communication, feedback
and courage. We focus on the roles of customer, manager,
and programer and accord key rights and responsibilities to
those in those roles.

Forward . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Chapter 2 Circle of Life . . . . . . . . . . . . . . . . . . . . . . 27
An XP project succeeds when the customers select business
value to be implemented, based on the team’s measured
ability to deliver functionality over time.

Chapter 3 On-site Customer . . . . . . . . . . . . . . . . . . . 31
An XP project needs a full-time customer to provide guidance. Here’s a summary of why ...

Chapter 4 User Stories . . . . . . . . . . . . . . . . . . . . . . . 37
Define requirements with stories, written on cards.

Chapter 5 Acceptance Tests . . . . . . . . . . . . . . . . . . . 45
Surely you aren’t going to assume you’re getting what you
need. Prove that it works! Acceptance tests allow the customer to know when the system works, and tell the programmers
what needs to be done.

Sidebar - Chapter 5 Acceptance Test Samples . . . . . . 49
At first it can be difficult figuring out how to do acceptance
tests. With a little practice it becomes easy.

Chapter 6 Story Estimation . . . . . . . . . . . . . . . . . . . . 51
Customers need to know how much stories will cost, in order
to choose which ones to do and which to defer. Programmers

It’s called Extreme Programming, after all. Here’s how we
do the programming part of things.
Integration is a bear. We can’t put it off forever. Let’s do it
all the time instead.

Sidebar - Chapter 11 Code Quality . . . . . . . . . . . . .103
A little more detail on something close to our hearts:
simplicity.

Chapter 12 Pair Programming . . . . . . . . . . . . . . . . .107
2


On an Extreme Programming team, two programmers sitting together at the same machine write all production
code.

Chapter 13 Unit Tests . . . . . . . . . . . . . . . . . . . . . . 113
Extreme Programmers test everything that could possibly
break, using automated tests that must run perfectly all the
time.

Sidebar - Chapter 13 xUnit . . . . . . . . . . . . . . . . . . . 127
Use the world’s lightest testing tool.

Chapter 14 Test-first, by Intention . . . . . . . . . . . . . 129
Code what you want, not how to do it. Chet and Ron do a
small task test first, trying always to express intention in the
code rather than algorithm.

Chapter 15 Releasing Changes . . . . . . . . . . . . . . . . 145

Chapter 22 Handling Defects . . . . . . . . . . . . . . . . . .183
Report ’em, schedule ’em, test and fix ’em, avoid ’em. Just
don’t call ’em bugs.

Sidebar - Chapter 22 Advanced Issue:
Bug Databases . . . . . . . . . . . . . . . . . . . .187
Sidebar - Chapter 22 Advanced Practice:
Tests as Database . . . . . . . . . . . . . . . . . .191
Sidebar - Chapter 22 Test to show a defect . . . . . . .193
When a defect is detected, begin with a test.

Chapter 23 Conclusion . . . . . . . . . . . . . . . . . . . . . .195

Section I Bonus Tracks . . . . . . . . . . . . . . . . . . . . . 205
Here are some things we’ve paid a lot to learn. Since you
bought the album, we wanted to give you a little something
extra. Thank you, and we hope we passed the audition.

Chapter 24 We’ll Try . . . . . . . . . . . . . . . . . . . . . . . .207
“We’ll try” can be the saddest words a programmer has ever
spoken, and most of us have spoken them more than once.
We’ve covered this material in other forms already, but it
bears repeating here.

Chapter 25 How to estimate anything . . . . . . . . . . .217
Sometimes estimating stories seems scary. Keep your heads,
4


stick together, and break the story down into small parts.

contains the entire series plus a whole lot more.

Chapter 32 A True Story . . . . . . . . . . . . . . . . . . . . 257
Ron Jeffries [re]learns something about simplicity.

5


Chapter 33 Estimates and Promises . . . . . . . . . . . . .261
We estimate how long the project will take. We promise to
tell the truth about how we’re doing.

Chapter 34 Everything that could possibly break . . .265
Test everything that could possibly break. What does this
mean? How is it possible?

6


Preface
How much would you pay for a software development team that would do
what you want? Wait, don’t answer yet — what if they could also tell you
how much it would cost, so that you could decide what to do and what to
defer, on your way to your deadline? You also get quality software, a
robust array of tests that support the project through its entire lifecycle,
and an up to date, clear view of project status. Best of all, you get the ability to change your mind about what you want, at any time.
There aren’t any silver bullets in software development, and there
probably never will be. However, Extreme Programming is a simple set
of common-sense practices that, when used together, really can give
you most of what you just read in the paragraph above. In this book,

We are software developers. We have been involved in many successful
projects, and even in some that “weren’t so successful”. The successful
ones were a lot more fun, for us, and for our customers. The unsuccessful ones have taught us a great deal about software development.
We have had the privilege of working on a great project, with a great
teacher, Kent Beck. We were part of the shaping of the software process named Extreme Programming, XP for short. Since then, we have
been helping everyone who will listen to learn from our experience.
The first book in the Extreme Programming series, Extreme Programming Explained, covers the reasoning behind the XP process. Based on
our experience on the original XP project and the others we have
helped with, this book describes what makes XP work, day to day and
month to month.
Successful software development is a team effort — not just the development team, but the larger team consisting of customer, management
and developers. Extreme Programming is a simple process that brings
these people together and helps them to succeed together. XP is aimed
primarily at object-oriented projects using teams of a dozen or fewer
9


Extreme Programming

programmers in one location. We would use XP for both in-house
development and development of shrink-wrapped software. The principles of XP apply to any moderately-sized project that needs to deliver
quality software rapidly and flexibly.
Customers — those who have software that needs to be developed —
will learn simple, effective ways to communicate what they need, to be
sure that they are getting what they need, and to steer the project to
success. You will learn that you can change your mind, and still get
what you need, on time.
Programmers — those who, on an XP project, define the architecture,
design the system, write the tests and the code that supports them —
will learn how to deliver business value quickly, how to deal with

the customer does. If you’re the XP customer, we’re talking to you.
Note that we say “the customer”, not “the customers”. Whether they
are one or many people, the XP customer always speaks with one voice.
The determination of what will have business value, and the order of
building that value, rests solely with the customer. (Don’t worry, you
get lots of help and advice. But ultimately, you get to make the call.)
An XP team plans and builds software in terms of “stories”. Stories are
just that — individual stories about how the system needs to work.
Each story describes one thing that the system needs to do. Each story
must be understood well enough that the programmers can estimate
its difficulty. And each story must be testable.
As the customer, you express what must be done in terms of stories.
For a project spanning a few months, there may be 50 or 100 stories.
Larger projects of course have more stories. We’ll talk more about the
details in User Stories (page 37).
You probably have a delivery date in mind, though some projects have
a fixed feature list rather than a fixed date. We are not content to imagine that everything that you can think of will be done by a given date
Neither should you be. Instead, the XP process lets the team predict,
more and more accurately, how much work can be done in any given
time period. Using this information, you manage project scope —
choosing what to do now and what to defer until later — to ensure
successful delivery.
You, the customer, have the critical responsibility to choose the stories
that will provide the most valuable features, the highest business value,
by the desired delivery date. The XP development process lets you
11


Extreme Programming


Base the program on simple, clear design. This lets you produce quality software quickly. There’s more discussion of this in Code Quality
(page 103), and A True Story (page 257). As you learn more about
what the design wants to be, improve the design using Refactoring
(page 95).
XP isn’t slash and burn programming, not code and fix, not at all.
Extreme Programming is about careful and continuous design, rapid
feedback from extensive testing, and the maintenance of relentlessly
clear and high-quality code.
Keep the system integrated at all times, so there’s always a good version to look at. Keeping integrated lets you go rapidly without
stepping on each others’ toes. See Continuous Integration (page 96).
Share the ownership of all the code, so no one has to wait and everyone feels able to make everything better. See Collective Code Ownership
(page 93), andReleasing Changes (page 145). Share a single Coding
Standard (page 97) as well, whether you evolve your own or adopt
one from elsewhere. Make everyone’s code look alike—it helps with
communication and team focus. Express your individuality in the way
you wear your XP ball cap.
Make sure that the system always works, using comprehensive unit
tests of your own making, as well as the customer’s acceptance tests.
These tests allow rapid change, and support collective code ownership
by keeping change from introducing mistakes. See Unit Tests
(page 113), Acceptance Tests (page 45), Everything that could possibly
break (page 265), and Test-first, by Intention (page 129).
Write all production code in pairs, for maximum speed and cross-training, in support of shared code ownership and rapid progress, as
described in Pair Programming (page 107).
Extreme Programming is an approach to software development that
lets programmers do what they do best — program — while giving the
customers what they need most — business value. It’s a win-win
approach and fun too.
13



14


Extreme Programming

When the date is chosen, prepare the ground. Arrange a room, send
out the invitations, order the refreshments — or cause these things to
be done if you have administrative help.
Before any planning meeting, check with the customers, reminding
them to be ready and to bring any new stories, and so on. If they need
help, provide it.
During each meeting, you may wish to coordinate or facilitate — or
designate someone to do so. Help to keep the team on process, make
notes on the proceedings, offer to get special resource people if they’re
needed, and so on.
After each meeting, if reporting needs to be done, you should do it or
cause it to be done. (Internal reporting generally is not needed. The
plan is on the white board and in the minds of the team. But some
stakeholders outside the room may need to be kept up to date.)
During the iteration, it’s the same: cause the right things to happen,
coordinate the activities, report results — and always remove obstacles.
The project manager usually has the personnel responsibility, and this
is a very important one. Even on the best teams, there are differences
between individuals, and sometimes there can be temporary or permanent people problems.
When people get in conflict, you need to fix it. If someone’s behavior
is harming the team, you have to address the problem. If the individual
cannot or will not correct the behavior, you must remove them from
the team. This should not be done lightly or precipitously, but sometimes it must be done, and it is the project manager’s responsibility.
There can sometimes be political problems that impact the team.

If they aren’t, it’s because I didn’t figure out how to do it yet. Please
help.

Manager and Customer Rights
1. You have the right to an overall plan, to know what can be accomplished, when, and at what cost.
2. You have the right to get the most possible value out of every programming week.
3. You have the right to see progress in a running system, proven to

16


Extreme Programming

work by passing repeatable tests that you specify.
4. You have the right to change your mind, to substitute functionality,
and to change priorities without paying exorbitant costs.
5. You have the right to be informed of schedule changes, in time to
choose how to reduce scope to restore the original date. You can
cancel at any time and be left with a useful working system reflecting investment to date.

Programmer Rights
1. You have the right to know what is needed, with clear declarations
of priority.
2. You have the right to produce quality work at all times.
3. You have the right to ask for and receive help from peers, superiors,
and customers.
4. You have the right to make and update your own estimates.
5. You have the right to accept your responsibilities instead of having
them assigned to you.
This book is about helping your project deliver these rights. Here’s a

You have the right to change your mind, to substitute
functionality, and to change priorities without paying
exorbitant costs.
Things change. Market requirements change, business requirements
change. An XP project thrives on change, through simple design, kept
simple through Refactoring (page 95). By allowing for change, we give
the customer the best chance to guide the project to success.

You have the right to be informed of schedule changes,
in time to choose how to reduce scope to restore the
original date. You can cancel at any time and be left with
a useful working system reflecting investment to date.
Too often, projects get to “ninety percent done” and stay there with
no real information coming out. Then there’s a sudden huge slip near
the end. XP works to be sure that everyone knows just what is really
happening, with clear and honest reporting (Resources, Scope, Quality,
18


Extreme Programming

Time, page 157), as well as the public Acceptance Tests. Because an XP
project implements business value first, and because of Small Releases
(page 65) and Continuous Integration (page 96), the product can be
kept always ready for release.

You have the right to know what is needed, with clear
declarations of priority.
Programmers want to implement what is really needed, but things get
in the way. Sometimes they don’t understand what is needed — user

not just how long you hope it will take — you can guide the project to
success by managing what is worked on. XP’s Customer Defines Release
and Iteration Planning allow you to do that management. Having the
programmers do Story Estimation (page 51) gives you the information
you need to steer the planning.

You have the right to accept your responsibilities instead
of having them assigned to you.
We all work most effectively when we have accepted our responsibilities instead of having them thrust upon us. Part of the ritual of the XP
Iteration Planning is that the programmers sign up for what they will
work on. At that time they choose to do the work, and put their name
down for what they will accomplish. This small act of commitment
engages the individual’s own honor as a necessary part of the team.

Project flow
The rest of the book follows the chronological flow of an XP project.
We’ve pointed to many of the chapters earlier in this introduction. An
XP project begins with an on-site customer, who provides the stories
that define the system and the acceptance tests that prove the system
works. We focus on small releases, each one defined by the customer.
We work in short iterations, again working on the customer’s stories of
highest business value.
Programmers follow a number of important practices, including Simple
Design (page 93), Refactoring (page 95), Collective Code Ownership
(page 93), and Pair Programming (page 107). They write their code
including extensive Unit Tests (page 113), ensuring consistent progress
and high quality.

20


do.
Typically, Validation means that somebody other than the producer
analyzes the Product and assures that it satisfies its purpose. Now, on
with the discussion.
When developing any software system there are two questions to
answer:
• Are we developing the right software?
• Are we developing the software right?
Essentially, the first question is about Analysis (what is it supposed to
do?) and Validation (does it actually do it?) and the second question is
about Design and Construction (is this the right architecture? does it
satisfy the "ilities"?). Can you say Inception/Transition versus Elaboration/Construction - I knew you could...
We also know that the first question is much more important than the
second, as developing the wrong software right is useless. So, because
XP does everything to extremes, we would expect it to focus on the
first question to the exclusion of the second. Almost, but not quite...

23


Forward

So, what does XP do to address the first question? IMHO, everything
except Refactoring (and only half of that...). This is because the
essence of Validation is communication, and almost everything about
XP is to facilitate communication: between the Customer and Developer and between Developers.
And because XP is extreme, the only kind of communication it wants is
face-to-face: PairProgramming, PlanningGame, and so on. And it
insists on a second pair of eyes on everything - it's all about Validating
everything that is done, all the time...