financial websites. We quickly learned that the algorithmic complexity was not in the transaction download component but in the backend-integrating the transactions into an existing accounting database. This was an unexpected and important discovery. The spike solution gave us the information we needed to estimate our stories.

The spike solution should be estimated, too. This caps the time the customer must pay for experimentation. The goal is to determine feasibility and cost, not to implement a fully working solution. Spike solutions are thrown away. The result of a spike solution is a new story or stories, which can be estimated with confidence.

4.10 Prioritization

Once the stories that can be estimated have been estimated, the customer groups and prioritizes them. The physical ordering process requires a large table so the customer can see as many of the cards as possible. The customer groups the stories in two piles: this release and subsequent releases.

The size of the release depends on the customer, although you should avoid releases exceeding a few months. The team will divide this release into iterations that last a few weeks at most (see Iteration Planning). From the customer’s perspective each iteration is a partial but usable software distribution. The size of a release is therefore a bit of a fuzzy concept. The customer may choose to stop work on a release before all the stories are implemented, and shall still have a working system albeit with fewer features than planned.

This is why prioritization is so important, and can’t be left to the programmers. The customer should see a continuous flow of software distributions in order of decreasing business value. XP eschews big bang releases. A working end-to-end system is available very early on in the implementation of a release plan.

For this reason, programmers should avoid creating too many dependencies between stories. It’s all too easy to control the prioritization through unnecessary linking. If you find yourself saying, “We need to build the infrastructure for this story.” Remember XP’s guideline: you aren’t going to need it (YAGNI). Infrastructure evolves from refactoring as you discover what parts of the system need it.

When the planning game is over put the subsequent releases pile into storage until the next planning game. The team may get done early in which case pull them out mid-release and add enough stories to meet the