How To Start Planning

You'll never know all there is to know about planning and estimating, but you
won't know anything if you don't get out there and do it. Remember that XP is
about learning and doing it better next time. The more you plan, the better you'll get
at it.
When you're just getting started, it's more important to get used to that rhythm
than it is to be right. At the beginning, you won't have a clue what your team's
velocity will be. Guess and refine it later. You'll do this frequently when you start.
Get used to it. Don't be lazy, but don't be too tough on yourself either.
One of the people in Ken's 1999 OOPSLA Workshop "Refining the Practices of
Extreme Programming" put it this way:
Starting with nothing more than a very high level statement of
functionality to be implemented that month, the first task was for the
team to break this down into more manageable pieces. Our intention
was to write on a whiteboard a list of sub-requirements, each of which
could be implemented by a team in on half-day. This effort was largely
a failure. We did identify functional pieces that could be doled out to
the pair teams, but our accuracy in identifying half-day tasks was way
off….We never did get to the goal of actually identifying half-day tasks
reliably, but soon they were being completed in a whole day with very
good consistency. [Rob Billington, submission to "Refining the
Practices of Extreme Programming", OOPSLA 1999]
That's the spirit. When you were learning to drive a car, steering was a tough
skill to pick up. You probably swerved a lot. After a while, you didn't have to think
about it as much – it started to become second nature. Planning is the same way.
Start by having your customer write cards. Have them put each feature of the
proposed system on a card. This might be uncomfortable for them at first, but it's the
same exercise they would be doing to help you create a requirements spec. You're
just giving them the power to write it down, and you're making each feature of the
system a discrete card.
When it's time for story estimation, use a few rules of thumb until you have
enough empirical evidence to refine the numbers for your team:

 Each story should require no fewer than one half-week for a single
developer. If it does, combine it with another.
 Have the customer split any story worth more than a week for a single
developer.

 Start with two-week iterations to increase the amount of feedback you
get early in the process. You can lengthen this later, if it makes sense.

 Guess at a velocity of four days per iteration to start. Adjust upward in
the next iteration if you end up getting more work done than that.
Once the customer has specified what is to be included in the release, based on
the team's velocity, have him sort the cards into iteration-sized piles. Then have
developers brainstorm tasks for each story, estimate them, and accept responsibility
for them. Some additional rules of thumb here:

 Estimate tasks at 0.25 to two days in the beginning.

 Never fight a ground war in Russia in the wintertime.

 Never match wits with a Sicilian when death is on the line.
Remember, the goal with planning is to keep it simple. The best way to do this is
keep it ridiculously short in the beginning. Give yourself lots of feedback, and lots
of opportunities to steer. As your skills improve, you can begin looking a little
farther down the road as you drive (but never too far).