How To Plan

You're always wrong about the future, even if you get the major events right.
Unfortunately, you're measured on how close to right about the future you were.
The further off you are, the more trouble you're in with those who are doing the
measuring. There is no way to fix this situation.
The only thing you can do is go with what you know for sure:

 Time keeps moving, so you can predict that a particular date will arrive in a
certain number of calendar days.

 Before that date arrives, if everyone involved agrees to dedicate a certain
number of days to a particular set of tasks designed to solve a problem, you
can make progress toward the goal.

 If you don't apply effort toward achieving the goal, we guarantee you won't
be any closer to it by the time the date arrives.
So plan. Reality won't ever match your plan, so don't spend too much time on it
(a day or two per iteration feels about right). Specify the target, estimate the effort in
"ideal days", then execute the effort. When you're done, take stock to see how far
off you were when you estimated. The next time around, you'll have more
experience to guide you. This is common sense, but we've noticed it isn't that
common. "Fire! Ready! Aim!" isn't as backwards as it sounds.
The Release Planning Game
One of the refreshing things about XP is that it isn't unnecessarily formal.
Planning is a "back to basics" affair. The customer and the developers sit a in a room
with whiteboards and note cards. The customer starts talking about what the system
needs to do. The customer writes each requirement (yes, these are requirements) on
a card. Try to keep the stories small enough so that one developer (with a pair of
course) can accomplish them within one of your iterations. Developers ask
clarifying questions. The customer answers them. If a developer thinks there is a
story missing, he can suggest it, but only customers write (or at least validate) stories
(and they can reject suggested stories entirely if they want to). That's step one.
Once the cards are done, the grand sorting begins. The customer sorts them into
three piles based on business value:

 Necessary for the system to be viable.

 Not absolutely necessary, but valuable

 Nice to have

Then the developers make their estimates. NOTE: it doesn't need to happen in
this order, but people usually care more about the estimates for the first and second
priorities. Identify how sure you are of the estimate. If you need some time to do
some research, identify how much time you need to give them an estimate you can
have any confidence in. Don't do this for every story or ask for an inordinate amount
of time. Half a day is usually more than enough… a full day is usually more than
sufficient. Remember, you are not looking for a guarantee, just an estimate. If they
won't give you the time, either refuse to give them an estimate or make it big. Don't
give them anything else.
At this point, and again in iteration planning at a much smaller scale, the
development team will explore the stories they have no clue how to estimate. This is
called…drum roll, please…Exploration. And there was much rejoicing. We use
Exploration to accomplish a few critical things:

 To lower the risk of making a bum estimate

 To experiment with various implementation options to increase and
demonstrate our understanding of the problem

 To determine our velocity for implementing stories
Exploration can last anywhere from one day to two months, depending on the
size of the project, how well-defined the stories are, and the issues surrounding the
technology choices. If we are just starting a brand new project that is not extremely
similar to one we've done with the same team members before, the typical length is
about a month if all the necessary resources (human and otherwise) are readily
available.
When Exploration is done, and it shouldn't last very long, the developers move
on to estimating the stories. Developers estimate coding time for each story in what
we call craft units. Each one corresponds roughly to a half-week's work for a single
developer or an "ideal day" (days where all the developer has to do is work on the
task, without distraction). A story that will take a week gets two units, and so on.
(Your mileage may vary). If a story needs less than one craft unit, it gets combined
with another story for estimation purposes. If a story spans more than N deliverable
units (where N is the number of units one developer can do in an iteration), the
customer split into smaller craft units. No story may span more than one iteration
worth of deliverable units (eight for us on a four week iteration. We prefer smaller
iterations… see next chapter). If it does, the customer splits it into smaller stories.
Given the estimates from the developers and the velocity they settled on during
initial planning, the customer has a choice. He/she can either

 choose a set of cards, and base the completion date on the estimates on
the cards, or

 set a completion date, and include the highest priority cards which fit
based on the estimates
The stack of cards you've got is your next Release. Congratulations.
This process is done at the beginning of each release. It should take no more
than a few days, excluding time for necessary spikes, and usually takes less. When
it's done, the customer has a set of cards for the next release, a price tag for each one
(the estimate), and an idea of what will come in future releases.
The Iteration Planning Game
We left off with a stack of cards that need to be done for a release. This is too
much to concentrate on all at once, so the customer sorts that bigish stack of cards
into iteration-sized piles, based on two things:

 business value and anything else that determines priority for the
customer

 the velocity of the development team
Now you have to plan the next iteration. Don't worry. Iteration planning is just
release planning in miniature.
Reserve some time at the beginning of each iteration (say, one or two days) to
review the last iteration's work. Be critical. Take steps to reduce business and
technical risk based on what you learn and changes in the customer's needs. Then
use a downsized version of the Planning Game to break the stories down.
This time, however, the development team breaks the stories down into "tasks".
The act of breaking them down into tasks is actually a design exercise. You are
figuring out the design approach you are going to take to implement the stories, and
each step is a task. How small should you break up the tasks? Two days is the
maximum we feel comfortable with. I've heard others say one day or one-half day.
Go smaller until you are better at estimating large chunks. Add up the chunks and
revise the story estimates for the customer.
It usually takes us a day or two to nail this down. So iteration planning usually
goes something like this:
< 1 hour - Demonstration and discussion of what we got accomplished. There
should be no real surprises here if your customer has been active in the iteration, it is
just a syncing up of what we did and did not do. If they haven't been active, you
might need more time for this.

1-2 hours - Discussion of what the next iteration should contain based on what
he had thought we'd tackle next and what we should tackle next based on what we
know now… this results in a candidates list which is prioritized by the customer.
4-6 hours - People volunteer to lead the breaking down of each of the candidates
into tasks. This can take lots of forms, but basically we break into small groups and
do it, sometime with the customer and sometimes without. Sometimes, an
individual does some quick exploration, and then calls someone over to work
through it. Sometimes the customer is grabbed.
Next day - we have a list of tasks and possibly a list of issues that need to be
resolved. People sign up for the highest priority tasks and start them. We review
what we think we can get done with the customer and sometime during the day we're
done iteration planning (or at least 90% of it). It's kind of fluid as to when the
planning ends and the doing begins.
If, after breaking down the stories into tasks, you find that your estimate for the
iteration is bigger than you had originally estimated, share it with the customer. Tell
them how many days of tasks you are over. They might pull out a story that is that
many tasks (after they are done being disappointed). On the other hand, they may
want to re-split a story. Now that they are broken down into tasks, there might be
natural, obvious breaks in the story that weren't obvious before. The remaining tasks
can go into a future story… probably next iteration, but that's up to the customer
when we start the next iteration.
In "Planning", Kent & Martin suggests only committing to the number of stories
you delivered last iteration. That's not a bad rule. We certainly take last iteration
into consideration when we plan the next iteration. However, we also adjust per
developer. A new developer may actually be able to contribute based on their skill
level, their familiarity with the domain, and how much they've worked with other
members of the team before. We also adjust for whatever else is going on
(vacations, other known assignments, whatever) that we are confident will have an
impact. We tell the developer how many units we think we'll be able to deliver based
on all this.
We weren't very good early on. Sometimes we were off by 35%. However,
we've gotten pretty good lately, and we seem to be within 5-10% of actual units
delivered. This should not be confused with accuracy of estimates on individual
tasks. We're getting better at that, too. See the Tracking section for more on this.
When Exploration is finished, get everybody together in a room again and take
to the whiteboard. The development team brainstorms the tasks for each iteration.
Our rule of thumb is that any story worth two or more deliverable units should be
broken down into smaller tasks. The customer sits in to answer questions to listen to
make sure the developers understand the stories. If the customer hears somebody say
something that indicates the team missed the point, he/she pipes up and steers a
little. Once the tasks are on the board, the developers hold a kind of auction (it can
get a little funny). Somebody chimes in to take ownership of the task and estimate it.
Other developers (not customers) can take pot shots at the estimate to refine it.
When the ownership/estimation auction is done, the developers review the
estimates for each story and revise as necessary. If something needs to fall off the
plate for the current iteration, the customer picks what falls off. If there's more room
than there used to be, the customer picks what gets added. Update the plan if the
changes warrant it.
At the end of each iteration, the development team commits to the system being
able to run with the functionality described in the stories for that iteration. The initial
iterations probably won't produce a system that does much of anything useful
(although sometimes this isn't true). They are still important as a gauge for
customers to be sure they are getting what they expect out of the development
process.
This iteration planning happens at the beginning of each iteration. It usually
takes anywhere from a half-day to two days, excluding time for necessary spikes. It
shouldn't take more than two days. When it's done, developers know what they'll be
working on next and how long it should take. They have their marching orders.
What if you don't have a single customer? Travis Griggs speaks of unique
approach they've come up with called "The Senate Game" [need to insert Travis
description here]