Man has an intense desire for assured knowledge.
We plan to communicate our intentions and to prepare for the
unplanned. In XP, the plan evolves with feedback from building and
using the system. We adjust our intentions as we see our ideas being
realized. Sometimes reality matches what we want. Other times we
gain new insight and change our plans accordingly. XP ensures we get
our recommended daily allowance of reality checks.
Planning is a three part process in XP:
- Release Planning
We decide on the course of action based on customer desires and team
capacity in the planning game. The result is the release plan: a list
of stories (requirements) prioritized by business value. A release
encompasses the next one to two months of work.
- Iteration Planning
We divvy up the stories based on individual programmer desires and
capacity in an iteration planning meeting. An iteration plan is a
prioritized list of development tasks estimated by the people who will
be implementing them. Iterations are delivered every one to three weeks.
- Pair Programming
We continuously balance between improving internal quality and adding
business function based on peer-to-peer discussions and individual
task commitments. A pair programming session lasts a few hours. The
output is one or more unit tests and the software that passes those
This chapter covers release planning. The subsequent chapters discuss
the other two activities.
To start the ball rolling, the customer and programmers sit in a room
together to define the requirements, priorities, and deadlines for the
release. We call this the planning game.
Planning is an interpersonal process, a game, if you will. The
customer wants a long list of features, and the team wants to implement
them all. Unfortunately, the team is limited in what it can
accomplish in one release. In XP, the planning game defines the
rules, pieces, and roles. The objective is clear communication of
business objectives and technical constraints.
In XP, we speak about the customer as a single
person, although several people may fill this role simultaneously.
It's important that the people acting as the customer speak in one
voice. This ensures that the project adds business value
optimally--to the the best of the customer's knowledge. Obviously, no
one knows the optimal path, that's why XP encourages tight feedback
loops. However, the team cannot be divided in its goals, or the
project will fail. XP has no mechanisms to resolve disputes between
the people acting as the customer.
The role of the customer is played by people who represent the
collective business interests of the project. For example, product
managers, users, and clients act as the customer. The business
requirements, priorities, and deadlines are defined by the
XP defines the roles of customer and programmer unambiguously. The
customer's job is to identify what needs to get
done, and the programmers' job is to explain how
it will get done. The customer is not allowed to say an estimate is
wrong or to contradict a technical statement made by the programmers.
And, conversely, programmers cannot say a feature is unnecessary or
the customer has her priorities wrong. The planning game is based on
mutual respect for these equal and distinct responsibilities.
If you are new to XP, you may want to have an impartial coach
participate in your first few planning games. The planning game is
non-adversarial, and a coach may help to remind people that planning
is about getting as accurate a picture as possible given limited data.
A story is how the customer communicates a
requirement in XP. The content of a story is simple, usually one or
two sentences. Here are some actual stories:
The questions and answers will be customized with the name of the
bride and groom where applicable.
Figure out which computer to use, and install disks. Make available
via Samba and NFS.
Subscription start/end dates should not overlap.
Update data in demo club.
Include AccountSync entries.
file_t is too large for a single export file.
Need to figure out how to split.
Convert EC payments to QuickBooks IIF format.
Group checks into deposits.
Move account to Wells Fargo.
For the most part, the customer writes the stories.
Note the incompleteness of the
stories in some cases. For example, DemoClubUpdate doesn't specify
what data is required. If the programmer needs more info, he will ask
the customer when he starts implementing the story.
Some of these example stories were not written by the customer, for
example, DBExportSplit and InstallDisks. Technical stories come up
during implementation, but it is the customer who decides how
important they are. The programmers' job is to note the technical
need on a story card, and to present the business case to the customer
during the planning game.
The customer does not write the stories and say, "get to
There is an explicit trade-off with simple requirements; the customer
must stick around for the implementation. She must be available to
the programmers to fill in the details during execution of the plan.
A story is not sufficient criteria for acceptance. Part of the
customer's job is to write the acceptance tests with the help of the
programmers. Perl makes
this easy. Acceptance Testing explains how
The stories are written on story cards. Here's the CloseChase story
Close Chase Story Card
I use story cards for almost everything. In this case, it's an
administration problem. The
mechanism is always the same: when there is a problem to solve, write
it on a story card. It represents a work item, and all work items
need to be put in the queue.
It often is a good idea to prepare story cards before the planning
game. Everybody should keep a stack on their desks. The customer may
think of new stories while using the system. The programmers may
encounter internal quality problems while coding.
There is no officially-sanctioned XP story card. Each project may
need special customizations. This story card is one we have developed
for our company's needs.
Here's the way we interpret the fields:
This is a mixed-case identifier for the story. Giving a handle to the
story simplifies communication about it. In my experience, customers
tend to have trouble filling in this field in the beginning.
Programmers are used to naming things (subroutines, modules, etc.),
and they may be able to help the customer choose appropriate story
The date or name of the release. We use this field loosely to
categorize stories by release or project. We couldn't predict when
CloseChase would be done, so we just put it in the Misc category.
Some teams work on several projects simultaneously, and this field
helps keep the story cards organized.
After the customer physically orders the story cards, she writes their
numeric priority in this field. The numbering scheme is arbitrary.
Sometimes you need to insert a story card in the middle of a
sequence. We add a letter, for example, 5a, or use a dotted
decimal notation, 5.1. If you drop the story cards, it's important to
be able to get them back in priority order.
The person who wrote the story.
You then know whom to ask for the details.
The date the story was written.
The date the story's implementation is accepted by the customer. We
do this at the start of every planning game before we get into the new
stories. This helps remind the customer what has just been
accomplished, and, sometimes, lets the customer catch incomplete
A few sentences and/or pictures explaining the requirement. Be
brief. If the description isn't clear, rip up the card and
start over. This is the most important field, so you may want to fill
it in first.
See examples in Stories.
The programmers write their best guess for the implementation time.
See discussion about the time scale in
The programmers list the implementation risks and prerequisites in
this section. This gives the customer more information about the
confidence of the estimate and helps her order dependent stories.
Don't implement the story here. It's tempting to write pseudocode or
to outline the design. Save the design for when you are in front of a
computer with your programming partner.
The list of activities required to implement the story. If the list
of tasks grows to more than fits in a few lines, you probably need to
split the story. The original story estimate is probably wrong, too.
We try to avoid large, complex stories to ensure the software pipeline
stays full, and XP's many feedback loops remain active.
This field is filled in during iteration planning, which
is covered in Iteration Planning.
The person who is responsible for this task. Sometimes we add the
partner who helped implement the task. It can be useful when trying
to remember why the code was written in a particular way.
The estimate for this task.
The date the task is finished. This field can also be used to record the
actual time to implement the task. We use it to help audit our
- Acceptance Test
This field reminds everybody that stories should have acceptance
tests. Ideally, the customer should be responsible for this task, but
a programmer probably ends up doing most of the work.
See Acceptance Testing for more detail.
One important characteristic of story cards is their physical
implementation. They are real dead plant matter. You write on them
with ink, not electrons. PDAs and laptops are not recommended for
The planning game is an interpersonal communication process. Story
cards are a simple communication medium, which enables people to have
as much face time as possible. You can read the cards from any angle, in
almost any lighting condition.
The stories listed so far have been text. Sometimes text won't
do. Paper is also an excellent medium for creating pictures
on-the-fly. Here's another example that demonstrates the
versatility of story cards to capture the story:
PaymentsInFiscalYear Story Card
And, here's the final user interface:
PaymentsInFiscalYear User Interface
The simple picture was enough to get the point across.
After a customer completes her portion of the story card, the
programmers can estimate its implementation, and note any special
considerations, such as, new hardware requirements or prerequisite
stories. Estimation is an art, where consistency is much more
important than precision or accuracy. The customer uses
them to assess the relative cost of stories to aid prioritization.
Programmers use estimates to compute and compare velocities (velocity
is the sum of estimates for an iteration--see
Velocity for details).
Stories are estimated in ideal programming days, not real-time.
It's hard enough to forecast a story's implementation
without considering other factors such as, hardware failures, sick
time, or activation of military reservists. Not to mention
unforeseeable refactorings required to accommodate the implementation
or changes requested by the customer as the implementation evolves.
Ideal day are the way we avoid thinking about such factors that
we can neither influence nor estimate.
Don't be afraid of making incorrect estimates. By definition,
estimates are forecasts made with incomplete information. You should
be concerned when estimates end up matching reality exactly, because
it's likely due to the effects of Parkinson's Law: work expands so as
to fill the time available for its completion.
Plan-driven methodologies often succumb to Parkinson's Law.
Programmers are rewarded for making or beating their estimates.
Over-estimation is a great way to make sure this happens. In XP, if
you over-esimate, you simply get more work to do. You don't get to go
home early, because the length of an iteration is measured in
real-time, not ideal time. There is always more business value to
add, and the code can always be improved through refactoring. Other
XP feedback mechanisms, such as, small releases, pair programming, and
continuous integration, also help to combat Parkinson's Law.
So don't worry about Parkinson, the weather, or politics. Just write
your best guess as to how many ideal days the story will take to
implement, and move on to the next card.
Sometimes you can't come up with a number that you have any confidence
in. The typical problem is that the story is too large, and it needs
to be split up. As a rule of thumb if the story comprises more than
one week's worth of work, decompose it into smaller stories.
For example, this is a story that was too large for me to estimate:
Create a web site with the ability to upload Microsoft Word documents
by me and viewed by anybody. The documents are categorized by visitor
(consumer, broker, etc.).
With the help of a customer, we split the story into four smaller,
more easily estimable stories:
Create the web site home page and navigation scheme.
Implement pages with Word document links and hand-installed documents.
Allow site administrators to login.
Implement upload page for Word documents accessible only by administrators.
We were able to deliver business value on the first story. After the
second story, the customer had a functional site from the end-user
perspective. We were able to populate the site using non-web-based
file transfer tools.
The last two stories gave the customer full administrative control of
the site, which is business value, but not as important
as having a site at all.
Most stories can be broken down this way. It's
quite similar to decomposing a story into tasks (see Iteration Planning).
Some stories defy estimation or decomposition. The programmers knows
so little about the problem domain that they may not even know if it is
feasible to implement the story. Some fundamental research is
required. In XP, we call this a spike solution. Two
programmers prototype, mockup, or just explore the problem space in
detail for a short time.
System integration is often important to spike. There are usually so
many variables that are out of the programmers' control. For example,
one project we were involved in required us to download transactions from
financial websites. Our first attempt was to use the Open Financial
Exchange (OFX) protocol. It turned out that OFX is not very open, and
we hit a non-technical roadblock. In parallel with talking to the OFX
consortium, we also spiked a web crawling solution for downloading
transactions from financial websites. We quickly learned that the
algorithmic complexity was not in the transaction download component
but in the backend--integrating the transactions into an existing
accounting database. This was an unexpected and important discovery.
The spike solution gave us the information we needed to estimate our
The spike solution should be estimated, too. This caps the time the
customer must pay for experimentation. The goal is to determine
feasibility and cost, not to implement a fully working solution.
Spike solutions are thrown away. The result of a spike solution is a
new story or stories, which can be estimated with confidence.
Once the stories that can be estimated have been estimated, the
customer groups and prioritizes them. The physical ordering process
requires a large table so the customer can see as many of the cards as
possible. The customer groups the stories in two piles: this release and
The size of the release depends on the customer, although you should
avoid releases exceeding a few months.
The team will divide this release into iterations that last a few
weeks at most (see Iteration Planning).
From the customer's perspective each iteration is a partial but
usable software distribution.
The size of a release is therefore a bit of a fuzzy concept. The
customer may choose to stop work on a release before all the stories
are implemented, and shall still have a working system albeit with
fewer features than planned.
This is why prioritization is so important and can't be left to the
programmers. The customer should see a continuous flow of software
distributions in order of decreasing business value. XP eschews big
bang releases. A working end-to-end system is available very early
on in the implementation of a release plan.
For this reason, programmers should avoid creating too many
dependencies between stories. It's all too easy to control the
prioritization through unnecessary linking. If you find yourself
saying, "We need to build the infrastructure for this
story." Remember XP's guideline: you aren't going to need it
(YAGNI). Infrastructure evolves from refactoring as you discover what
parts of the system need it.
When the planning game is over put the subsequent releases pile into
storage until the next planning game. The team may get done early in
which case pull them out mid-release and add enough stories to meet
the deadline for the current release. The nice thing with XP is that
you can add or rearrange stories at any time. The stories that are
already implemented have already been tested within the context of a
working system. There's no end-of-release panic to integrate the
parts into the whole. Indeed, the system probably is already in use
well before the end of the release.
All the Facts
The customer's job is hard. She is managing other factors besides
implemention complexity, such as, time to market and resource
acquisition. To simplify the planning process, she has to have all
the data from the programmers. Any work which consumes time and
resources needs to be on the planning game table.
The considerations of stories may be significant. If the story
requires a relational database to be implemented, you need to make
this clear. Or, it may be obvious that a story requires major code
restructuring. If so, get it on a card.
While you're coding, you'll notice problems. You may have to
copy-and-paste, because the refactoring required to make the pasted
code reusable may be lengthy.
Write down the problem on a story card and
bring it to the next planning game or iteration planning meeting.
The customer and management are made aware of internal quality
issues before they get out of control.
Release planning is the way we communicate business objectives to the
programmers and enable programmers to communicate technical
constraints. The planning game is a simple forum for effective
communication that relies on interactive feedback.
By limiting the length of releases to one or two months, we limit the
length of planning meetings. This means we have fewer objectives to
discuss. It is easy to maintain the cohesion of small releases and to
identify dependencies and other potential problems. XP simplifies
plan digestion by encouraging us to take a small bite and chew it
thoroughly before taking the next bite.
Ideas and Opinions, Albert Einstein,
Crown Publishers Inc., 1985, p. 22.
The source can be found at
XP assumes the entire team,
including the customer, share the same office. If the customer or
part of the team are not colocated, you may want to scan your story
cards after the planning game and store them in the collective
repository. I'm not a fan of purely electronic story cards, but some
people like them. As with all things XP, try it by the book and then
season to your taste.
Cards are context sensitive, so you may not understand the details of
the PaymentsInFiscalYear story or implementation. The point is to
demonstrate how little information you need on a story card, and how
closely a quick sketch matches the final implementation.
Lengthy to me means anything that takes an hour or more. You may have
completed several refactorings already, and any more will blow your
For a complete discussion on refactoring, see