Plans are useless, but planning is indispensable.
-- Dwight D. Eisenhower
An iteration adds function to a system without breaking it. The new
features are delivered to the customer in a complete software
distribution. This way the customer can try out the story
implementations, and the programmers can get feedback on the
system every few weeks, before the entire release is implemented.
While release planning sets the pace for the customer, iterations are
the heartbeat of the system's implementation.
By distributing the software on a fixed schedule, typically from one
to three weeks, the programmers stay focused on delivering complete
stories. This avoids the situation where the system remains
"95% done" until the entire release has been
implemented. XP programmers complete the most important story first
before moving on to the next one.
This chapter covers dividing stories into tasks during the iteration
planning meeting, estimating tasks, grouping tasks into iterations,
and tracking team and individual velocity to schedule the next
A task is the basic unit of work of an
The stories are broken down into a list of tasks during the iteration
planning meeting. For example, here are the tasks for two of the
stories from Release Planning:
Implement year at a glance widget.
Implement data model and report.
Acceptance test: validate payments in months for members.
Compare rates and services at local banks.
Open new account.
Move automatic payments (FedEx, EarthLink)
After last check clears, transfer remaining funds.
Acceptance test: verify account is closed and automatic payments working.
For reasons of simplicity, I write the tasks directly on the bottom of
the story cards. This keeps the motivation for the work (the
story) and the list of work items on one piece of paper. This helps
me stay focused on the trees without getting lost in the forest.
Alternatively, you might create separate task cards, one for each work
item. This allows you to divide up the work for an individual story
among several programmers. If you tend towards larger, multi-week
stories, task cards are probably the way to go.
Iteration planning involves the entire team. Somebody reads the
stories aloud, and everybody contributes to identifying the tasks,
which are written on whiteboards or flip charts for all to see.
Another person writes the tasks down on the cards once everyone agrees
they are correct.
The meeting is a time for group design discussions. It isn't always
obvious what tasks are required to implement a story. While ad hoc
design discussions pop up during programming, iteration planning is a
time for the whole team to discuss the system's implementation. You
might realize that a global refactorings need scheduling. This may
add dependencies and possibly a new story for the customer to prioritize.
After all the tasks are listed on the board, people commit to
implementing them. Individuals take the cards and estimate the tasks
they are planning to implement. As with stories, estimate in
ideal programming days. Everybody's ideal timescale is different,
don't expect the task and story estimates to add up.
If a task is difficult to estimate, ask for help. Others may have a
better feeling for the problem and/or implementation. Sometimes a
task is too complex, and you'll realize as a group that the risk
factors were underestimated. Restructure the task list for this
story. If you think this story's estimate is way off, discuss it with
the person responsible for the story estimate. It may need to be
changed, and the customer should be informed of the unforeseen
considerations and the new estimate.
Get Me a Bucket
In plan-driven methodologies, the amount of work that goes into
software distribution is dictated by the plan. The schedule is
extended as you experience the actual implementation time for the work
items. A software distribution only comes out when the entire release
is complete. XP takes another view. Software distributions flow out
from the team in fixed time iterations, much like water flowing
through a water wheel.
The buckets on a water wheel
are a fixed size, too, and only one bucket is necessary to get the
water wheel turning. If the bucket is too large, the wheel won't turn
for awhile, and the water will flow in fits and starts. Tiny
buckets don't supply enough energy to move the wheel at all. There's a
reasonable range of sizes for efficient transfer of potential to
kinetic energy. Experience suggests that the most efficient range for
XP iterations is one to three weeks. Each team must decide, however,
what works best.
The rate at which the water flows through a water wheel is measured in
cubic feet or meters per second. The implementation flow rate
in XP is called velocity, and is the ratio of estimated ideal days to
real implementation days. Since the number of real days is fixed per
iteration, we simply keep track of the sum of the estimated ideal days
for each iteration. The ideal time budget for the next iteration is
the velocity of the iteration just completed.
Our goal in XP iteration planning is to predictably fill an iteration
with exactly the right number of stories. This reduces planning time
to a minimum, and keeps the software process flowing smoothly and
reliably, just like an efficiently designed water wheel.
Velocity is a relative measure, however. You can only compare like
estimates. The team's velocity is the sum of estimates for completed
stories per iteration. Likewise, your individual velocity is measured
in your own estimation timescale, the sum of your task estimates
completed per iteration. You can't compare the velocities of
different individuals, and it doesn't matter if the sum of task
estimates doesn't add up to their story estimate.
It's like comparing water wheel flow rates with the rate at which
people flow on an escalator. The denominators are the same, but the
numerators are different.
Your velocity should converge after the first few iterations. If it
doesn't, something's wrong, and in Tracking, I
discuss what to do about it. The starting budget for the first
iteration is a guess. It's likely to be way off. At first, it's
reasonable to assume the ratio of ideal days to real days is 1:1.
Scheduling the first iteration is just the beginning. You'll find
you and your team's natural velocity converges rapidly no matter what
the starting point is.
Watch Your Speed
Velocity is a self-governing speed limit. The team limits the sum of
its story estimates to the velocity of the prior iteration. The sum
of your task estimates should not exceed your individual velocity.
That is, you should sign up for the same amount of estimated work that
you completed last iteration.
If you signed up for too many tasks, look for somebody with excess
capacity. Pick a simpler story if no one volunteers. We avoid
splitting stories across iterations, because it complicates tracking.
All stories will be implemented
by release end, so you'll be able to pick the story you dropped next
iteration, if it still interests you.
The priority on the story card expresses the customer's expectation
of business value. Programmers work on the highest priority
stories in each iteration. In XP, we deliver as much business value
as early as possible in the release.
There's no guarantee all stories can be implemented. The best way for
the customer to ensure a particular feature is added is to limit the
scope of the release. If the programmers get done early, you can add
stories in a mid-release planning game followed by an iteration
planning meeting. And, if you run out of work before the end of the
iteration, grab the highest priority story card, estimate the tasks,
and implement them. This is how you increase your individual
Taking Care of Business
XP was originally invented to solve an internal software development
problem. The idea of light requirements is more easily accepted in
internal projects than it is for consulting projects.
You can still use XP if your relationship with the customer is
contractual. My consulting company takes three approaches:
We write small, fixed-price contracts after the planning game.
We scan the story cards and include them in the contract.
We write a general contract which promises fixed length iterations
for a fixed price. The planning game happens before every iteration.
We write a time and materials contract, and the customer provides
stories on an as needed basis.
The three cases are listed in order of increasing trust. We use the
first option with customers who are skeptical about our development
process. To help with this, we absorb the risk with a fixed price
iteration with a satisfaction guarantee. We know that the sooner we
get coding, the lower the risk of dissatisfaction. And, we bypass many
hours of unpaid work by circumventing protracted negotiations on a
detailed, legalistic specification.
After the first iteration, we usually slip into the second option. The
customer has seen a working end-to-end system, and she has experienced
our process. Functioning software has a way of convincing even the
most skeptical customers about XP.
Finally, we move into time and materials mode. By the second or third
iteration, XP has established a strong trust relationship due to its
intense focus on the customer and her priorities.
The Beat Goes on
From the first iteration to the
last, an XP team cranks out a steady stream of software
distributions. Programming, like many other creative professions,
needs a regular beat.
It's all too easy to get distracted by an interesting problem.
Regular, high frequency deadlines help people to stay on track.
Every team has to find its own rhythm.
Weekly iterations work well in my experience, and they dovetail nicely with
the 40-hour week practice of XP. At the end of the week, we go home
with a clean plate, and come back with a fresh mind for the next
Whether you deliver every week or every few weeks, the goal is to keep
the software water wheel flowing to the customer. She sees steady
progress, and programmers get high frequency feedback about the
quality of the system.
Overshot water wheels with horizontal axles are the subject of this
I had a music teacher who
believed this, too. He used to thwack my leg with his baton to make
sure I didn't forget the beat. I recommend a kinder, gentler approach
for your team. Although some in XP advocate a RolledUpNewspaper,
visit the XP Wiki at
to learn more.