Each iteration is planned by breaking down the stories for that iteration into tasks. Tasks are scheduled by asking programmers to sign up for the tasks they want, then asking them to estimate their tasks, then rebalancing as necessary.
The release plan is synchronized to the rhythms of business. It gives the business people a way of thinking about sets of stories that together tell a good story to the market. The iteration plan is synchronized to the rhythms of programming. Two weeks is long enough to
Develop some new functionality
Do a substantial refactoring
Develop some infrastructure
Try some experiments
Recover from little disappointments
Unlike the release plan, the iteration plan is very much the developers'. They decide how to do things and in what order. The customer is still involved. It's important to report progress mid-iteration so that the customer can see what's happening and get a sense for what will actually happen. The customer will also get involved if the team finds there is too much to do and you need to cut scope.
The formal start of the iteration is the iteration planning meeting, where the programmers get together to break down the stories for that iteration into tasks. We do this because we need smaller units to track than the stories. Each task is about one to three ideal days long. While it's often worthwhile to have a programmer responsible for seeing a story through to completion, it is better for people to sign up for the smaller tasks to give them a chance to express their specializations. Stories can share work, and we can handle this better by having them share tasks. Finally, the kind of dependencies that drive most planners crazy must be dealt with inside of iterations.
After the iteration planning meeting someone takes on the responsibility of tracking the iteration (Chapter 19). This person, the tracker, keeps an eye on which tasks are done and how much is left on outstanding tasks. Her job is to alert the team to problems that might come up: having too much to do, too little to do, people overcommitted or undercommitted. Every day the team has a short stand-up meeting so everyone can see what everyone else is doing. This helps keep communication flowing across the whole team.
One of the most important principles in planning for Extreme Programming is that the dates are hard dates, but scope will vary. In every project you'll run into the situation where there is too much to do and you'll be tempted to slip the date of an iteration just a little bit to accommodate a little more functionality.
Don't do that.
Slipping dates is one of those bad habits that is both addictive and damaging. The damage really comes from the fact that it's so easy to do. At some point, however, you'll either slip so much that you'll lose all credibility (and the project, too), or you'll run into some date that's very painful to slip, like a release date. If slipping dates is the only thing people know how to do, then that's what will happen, and the pain is great.
The harder but surer way to cope with too much to do is to defer functionality. Because it's harder it's more important to practice doing it. Only if the team (and especially the customer) practices this for every iteration will everyone be ready to do this when the really important date comes along. The most important stories are the ones the customer decides he can live without for the moment. Those stories can save projects.
Sometimes it may be better to slip a release date. That's the customer's decision. It will involve many issues outside the scope of project planning. Only if everyone has practiced deferring function will the customer have a genuine choice between date and function. We are constantly surprised by how much "essential" functionality customers can do without when a big date looms.
Often you can make those hard choices only when the big dates appear, and without practice you can't do it under pressure. As Jim Highsmith says, "I used to think time-boxing was about time, but I've learned that instead it is about forcing hard tradeoff decisions throughout the project."
The other reason not to slip dates is that you lose control. There's always some uncertainty within the iteration. Only at the end of an iteration do you really know where you are. So you never want to put that time off.