To provide an estimate that is fairly accurate, the developers need to have a good grasp of the story. During release planning, the customer describes each user story and presents acceptance test criteria. The developers can ask questions until they are satisfied that they understand the most important aspects of what the customer is asking for. Avoid analysis paralysis; there are many stories.

Sometimes the team can just estimate the story from their gut. Other times the story may not quite fit prior experiences, and the team may have to explore potential design alternatives. Do not settle on a specific design. If competing ideas take about the same amount of time, pick an estimate and move on to the next story. Avoid analysis paralysis; there are many stories.

When there is deep uncertainty, the team can request the time to do some research (spike) in order to give a more realistic estimate.

If the team has done similar work before, they simply extrapolate from previous work. For work the team is unfamiliar with, a spike can provide just enough information to know what is possible and how long the effort is likely to last. An experienced XP team can estimate most stories in a few minutes or less. Avoid analysis paralysis; there are many stories.

Story estimates should not exceed the iteration duration for a pair of programmers. If the estimate is too big, have the customer split the story. People are better at estimating smaller pieces of work. Long estimates tend to go over budget. It would not be uncommon to take a four-week story and break it down only to discover it is four two-week stories.