User Stories

User stories serve the same purpose as use cases but are not the same.
They are used to create time estimates for the release planning meeting.
They are also used instead of a large requirements document. User Stories
are written by the customers as things that the system needs to do for them.
They are similar to usage scenarios, except that they are not limited to
describing a user interface. They are in the format of about three sentences
of text written by the customer in the customers terminology without
techno-syntax.
User stories also drive the creation of the acceptance tests. One or
more automated acceptance tests must be created to verify the user story
has

been

correctly

implemented.

One of the biggest misunderstandings with user stories is how they

differ from traditional requirements specifications. The biggest difference is
in the level of detail. User stories should only provide enough detail to make
a reasonably low risk estimate of how long the story will take to implement.
When the time comes to implement the story developers will go to the
customer and receive a detailed description of the requirements face to face.

Developers estimate how long the stories might take to implement. Each
story will get a 1, 2 or 3 week estimate in "ideal development time". This
ideal development time is how long it would take to implement the story in
code if there were no distractions, no other assignments, and the researchers
knew exactly what to do. Longer than 3 weeks means the researchers need
to break the story down further. Less than 1 week and the researchers are at
too detailed a level, combine some stories. About 80 user stories plus or
minus 20 is a perfect number to create a release plan during release
planning.
Another difference between stories and a requirements document is a
focus on user needs. The researchers should try to avoid details of specific
technology, data base layout, and algorithms. The researchers should try to
keep stories focused on user needs and benefits as opposed to specifying
GUI layouts.
Architectural Spike
Create spike solutions to figure out answers to tough technical or design
problems. A spike solution is a very simple program to explore potential
solutions. Build the spike to only addresses the problem under examination
and ignore all other concerns. Most spikes are not good enough to keep, so
expect to throw it away. The goal is reducing the risk of a technical problem
or

increase

the

reliability

of

a user

story's

estimate.

When a technical difficulty threatens to hold up the system's

development put a pair of developers on the problem for a week or two and
reduce the potential risk.
Release Planning
A release planning meeting is used to create a release plan, which lays out
the overall project. The release plan is then used to create iteration plans for
each individual iteration.

It is important for technical people to make the technical decisions and

business people to make the business decisions. Release planning has a set
of rules that allows everyone involved with the project to make their own
decisions. The rules define a method to negotiate a schedule everyone can
commit to.
The essence of the release planning meeting is for the development team to
estimate each user story in terms of ideal programming weeks. An ideal
week is how long the researchers imagine it would take to implement that
story if the researchers had absolutely nothing else to do. No dependencies,
no extra work, but do include tests. The customer then decides what story is
the most important or has the highest priority to be completed.
User stories are printed or written on cards. Together developers and
customers move the cards around on a large table to create a set of stories
to be implemented as the first (or next) release. A useable, testable system
that makes good business sense delivered early is desired.
The researchers may plan by time or by scope. The project velocity is used to
determine either how many stories can be implemented before a given date
(time) or how long a set of stories will take to finish (scope). When planning
by time multiply the number of iterations by the project velocity to
determine how many user stories can be completed. When planning by
scope divide the total weeks of estimated user stories by the project velocity
to determine how many iterations till the release is ready.
Individual iterations are planned in detail just before each iteration begins
and not in advance. The release planning meeting was called the planning
game and the rules can be found at the Portland Pattern Repository.
When the final release plan is created and is displeasing to management it
is tempting to just change the estimates for the user stories. The researchers
must not do this. The estimates are valid and will be required as-is during the
iteration planning meetings. Underestimating now will cause problems later.

Instead negotiate an acceptable release plan. Negotiate until the developers,

customers, and managers can all agree to the release plan.
The base philosophy of release planning is that a project may be quantified
by four variables; scope, resources, time, and quality. Scope is how much is
to be done. Resources are how many people are available. Time is when the
project or release will be done. And quality is how good the software will be
and how well tested it will be.
No one can control all 4 variables. When the researchers change one the
researchers inadvertently cause another to change in response. Note that
lowering quality to any less than excellent has unforeseen impact on the
other 3 variables that may not become obvious until your project slows to a
crawl just before the deadline.
In essence there are only 3 variables that the researchers actually want to
change. Management can set 2 of those variables and the third will be set by
the development team.

Also let the developers moderate the customers

desire to have the project done immediately by hiring too many people at
one time.
Iteration
Iterative Development adds agility to the development process. Divide your
development schedule into about a dozen iterations of 1 to 3 weeks in
length. One week is the best choice even though it seems very short. Keep
the iteration length constant throughout the project. This is the heart beat of
your project. It is this constant that makes measuring progress and planning
simple

and

reliable

in

XP.

Don't schedule your programming tasks in advance. Instead have

an iteration planning meeting at the beginning of each iteration to plan out
what will be done. Just-in-time planning is an easy way to stay on top of
changing

user

requirements.

It is also against the rules to look ahead and try to implement anything

that it is not scheduled for this iteration. There will be plenty of time to
implement that functionality when it becomes the most important story in
the release

plan.

Take your iteration deadlines seriously! Track your progress during an

iteration. If it looks like the researchers will not finish all of your tasks then
call another iteration planning meeting, re-estimate, and remove some
the

of

tasks. Concentrate your effort on completing the most important tasks

as chosen by your customer, instead of having several unfinished tasks

chosen by the developers.
It may seem silly if your iterations are only one week long to make a new
plan, but it pays off in the end. By planning out each iteration as if it was
your last the researchers will be setting yourself up for an on-time delivery of
your product. Keep your projects heart beating loud and clear.
Acceptance Test
Acceptance tests are created from user stories. During an iteration the user
stories selected during the iteration planning meeting will be translated into
acceptance tests. The customer specifies scenarios to test when a user story
has been correctly implemented. A story can have one or many acceptance
tests,

whatever

it

takes

to

ensure

the

functionality

works.

Acceptance tests are black box system tests. Each acceptance test
represents

some

expected

result

from

the

system.

Customers

are

responsible for verifying the correctness of the acceptance tests and

reviewing test scores to decide which failed tests are of highest priority.
Acceptance tests are also used as regression tests prior to a production
release.
A user story is not considered complete until it has passed its
acceptance tests. This means that new acceptance tests must be created
each iteration or the development team will report zero progress.
Quality assurance (QA) is an essential part of the XP process. On some
projects QA is done by a separate group, while on others QA will be an

integrated into the development team itself. In either case XP requires

development to have much closer relationship with QA.
Acceptance tests should be automated so they can be run often. The
acceptance test score is published to the team. It is the team's responsibility
to schedule time each iteration to fix any failed tests.
The name acceptance tests was changed from functional tests. This better
reflects the intent, which is to guarantee that a customers requirements
have been met and the system is acceptable.
Small Releases
The development team needs to release iterative versions of the system to
the customers often. Some teams deploy new software into production every
day. At the very least the researchers will want to get new software into
production every week or two. At the end of every iteration the researchers
will have tested, working, production ready software to demonstrate to your
customers.

The

decision

to

put

it

into

production

is

theirs.

The release planning meeting is used to plan small units of functionality

that make good business sense and can be released into the customer's
environment early in the project. This is critical to getting valuable feedback
in time to have an impact on the system's development. The longer the
researchers wait to introduce an important feature to the system's users the
less time the researchers will have to fix it.

Iteration

Detail

An iteration planning meeting is called at the beginning of

each iteration to produce that iteration's plan of programming tasks.
Each iteration is 1 to 3 weeks long. User stories are chosen for this
iteration by the customer from the release plan in order of the most
valuable to the customer first. Failed acceptance tests to be fixed
are also selected. The customer selects user stories with estimates
that total up to the project velocity from the last iteration.
The user stories and failed tests are broken down into the
programming tasks that will support them. Tasks are written down
on index cards like user stories. While user stories are in the
customer's language, tasks are in the developer's language.

Duplicate tasks can be removed. These task cards will be the

detailed

plan

for

the

iteration.

Developers sign up to do the tasks and then estimate how long

their own tasks will take to complete. It is important for the
developer who accepts a task to also be the one who estimates how
long it will take to finish. People are not interchangeable and the
person who is going to do the task must estimate how long it will
take.
Each task should be estimated as 1, 2, 3 (add 1/2 if the
researchers need to) ideal programming days in duration. Ideal
programming days are how long it would take the researchers to
complete the task if there were no distractions. Tasks which are
shorter than 1 day can be grouped together. Tasks which are longer
than 3 days should be broken down farther.
Now the project velocity is used again to determine if the iteration
is over booked or not. Total up the time estimates in ideal
programming days of the tasks, this must not exceed the project
velocity from the previous iteration. If the iteration has too much
then the customer must choose user stories to be put off until a
later iteration (snow plowing).
If the iteration has too little then another story can be accepted.
The velocity in task days (iteration planning) overrides the velocity
in story weeks (release planning) as it is more accurate.
It is often alarming to see user stories being snow plowed. Don't
panic. Remember the importance of unit testing and refactoring. A
debt in either of these areas will slow the researchers down. Avoid

adding any functionality before it is scheduled. Just add what the

researchers need for today. Adding anything extra will slow the
researchers down. Don't be tempted into changing your task and
story estimates. The planning process relies on the cold reality of
consistent estimates, fudging them to be a little lower creates more
problems.
Keep an eye on your project velocity and snow plowing. The
researchers may need to re-estimate all the stories and re-negotiate
the release plan every three to five iterations, this is normal. So long
as the researchers always implement the most valuable stories first
the researchers will always be doing as much as possible for your
customers

and

management.

An iterative development style can add agility to your

development process. Try just in time planning by not planning
specific programming tasks farther ahead than the current iteration.
Bugs
When a bug is found tests are created to guard against it
coming back. A bug in production requires an acceptance test
be written to guard against it. Creating an acceptance test first
before

debugging

helps

customers

concisely

define

the

problem and communicate that problem to the programmers.

Programmers have a failed test to focus their efforts and know
when
Given

the
a

failed

problem
acceptance

is
test,

developers

fixed.
then

create unit tests to show the defect from a more source code
specific point of view. Failing unit tests give immediate
feedback to the development effort when the bug has been

repaired. When the unit tests run at 100% then the failing
acceptance test can be run again to validate the bug is fixed.

Project Velocity
The project velocity (or just velocity) is a measure of how much work
is getting done on your project. To measure the project velocity the
researchers simply add up the estimates of the user stories that
were finished during the iteration. It's just that simple. The
researchers also total up the estimates for the tasks finished during
the iteration. Both of these measurements are used for iteration
planning.
During the meeting customers are allowed to choose the same
number of user stories equal to the project velocity measured in the
previous iteration. Those stories are broken down into technical
tasks and the team is allowed to sign up for the same number of
tasks

equal

to

the

previous

iteration's

project

velocity.

This simple mechanism allows developers to recover and clean

up after a difficult iteration and averages out estimates. Your project
velocity goes up by allowing developers to ask the customers for
another story when their work is completed early and no clean up
tasks

remain.

A few ups and downs in project velocity are expected. The

researchers should use a release planning meeting to re-estimate
and re-negotiate the release plan if your project velocity changes
dramatically for more than one iteration. Expect the project velocity
to change again when the system is put into production due to

maintenance tasks. Don't bother dividing the project velocity by the

length of the iteration or the number of people. This number isn't
any good to compare two project's productivity. Each project team
will have a different bias to estimating stories and tasks, some
estimate high, some estimate low. It doesn't matter in the long run.
Tracking the total amount of work done during each iteration is the
key to keeping the project moving at a steady predictable pace.
The problem with any project is the initial estimate. Collecting
lots of details does not make your initial estimate anything other
than a guess. Worry about estimating the overall scope of the
project and get that right instead of creating large documents.
Consider spending the time the researchers would have invested
into creating a detailed specification on actually doing a couple
iterations of development. Measure the project velocity during these
initial explorations and make a much better guess at the project's
total size.