Extreme Programming uses both stories and tasks in release and iteration planning. I generally recommend only estimating stories. In answering a recent XP mailing list question on the topic, I explained why I feel that way. Here it is:

I feel task estimates are extraneous. I stopped recommending/doing task estimates when I realized that that they provide no additional benefit to release planning -- but do increase the complexity of iteration planning.

To explain "no additional benefit" I need to explain why I think we do estimates and tracking in the first place -- ie. what is the benefit?

-- Premise One --

The Reason we estimate and track is so that we can predict the future -- specifically about our releases.

We either want to predict "when will we be done with this given block of functionality" or "how much of this block of functionality will be done by a given date." There are as many reasons why as there are stakeholders (everything from busines strategy to vacation planning).

-- Premise Two --

Anything that helps me better predict the future is useful -- anything else is extraneous.

(This is the simplicity argument again)

-- Assertion --

Given those two premises, we can effectively predict our release future using just two items: Story estimates, and Fixed-length Iterations. Here's how:

-- Estimate the Stories in relative points --

Stories should be estimated by comparing them to each other in terms of how much effort they are.

(e.g. Story A is arbitrarily picked as a 1 point story, Story B is estimated to be twice as big so its a 2)

Once we have estimated them all, we can add up our estimates to calculate our total estimated effort. (e.g. 500 points worth of stories). Thus we are not estimating "How long" but "how big" the effort is without relating it to the calendar in any way (i.e. its an abstract measurement).

-- Pick an initial velocity --

Velocity is always measured using a ratio. In XP it is points per iteration (ppi). What to pick for the initial value seems largely irrelevant* (e.g. 10ppi).

-- Fix the iteration length --

This is a biggie, because this is our link to the future. (I like 1 week iterations others prefer 2 or more. For planning purposes, the shorter the better, because we get more measurements).

So if our example project contains 500 points of stories. Given our initial velocity of 10ppi we estimate that the project will take 50 iterations, and thus 50 weeks.

-- Recalculate every iteration --

Specifically Re-estimate whenever you know something. And use yesterday's weather* (points completed last iteration becomes the velocity for next iteration) for your velocity calculation.

==========

Therefore...

Since we didn't use task estimates at all -- and we are predicting the future -- task estimates are extraneous.

-- Summary -- Tasks still have an important role to play in iteration planning -- but their value is in defining who will will work on what -- not how long it will take.

One final thing to note, all of the above are just numbers. Just as in driving, high or low velocity may or may not be a sign of trouble. The XP planning system still depends on interpretation and an understanding of the risks that can confront a project team -- but its simplicty and effectivness can greatly assist us in gaining visibility into our projects -- and communicate what find out to others.

Notes:

• Whether our intial velocity is: random, always 5, or calculated by doing some big analysis, the initial number's overall impact is minimal -- much like the speed at which you back out of your driveway has a very small impact on how long it takes you to get to work.

** Re-estimating. for the above system to work we don't need to know actual/versus expected. All we need is to improve the relative consistency of the estimates for similar stories. e.g. if Story ZZ is of similar effort to Story AF as long as they have the same estimate our formula will work. Thus, re-estimating is about aligning relative-effort consistency -- not (directly) about re-predicting how long things will take.

* Velocity is the number of points completed last iteration -- not the average of overall-total divided by the number of iterations. Howver, this average can be useful for planning:

Suppose after iteration 5, we have completed 50 stories and our current velocity is 20. We can use that average to show that our initial estimate is still holding (we have gone 5, and have 45 iterations to go). We can also use our current velocity to estimate remaining time to be 22.5 iterations. (if for example we are approaching our actual cruising speed). Which you pick will be largely determined by whether you feel your last iteration was typical or unusual.

The point is, velocity is the measure of how fast we are going right now -- not an attempt to predict how fast we will go (just as your car's speedometer doesn't know whether you are going to be on the interstate for ten minutes, or ten hours -- and just tells you what your speed is right now).

And just as in driving, the more periods you go, the more the "total completed divided by period" average project will zero in on our actual ship date. But since in practice velocity tends to stabilize, both calculations tend to converge -- just as they would if you 9.5 of your 10 hour drive was spent on an interstate going 65mph. Which you choose is partly a matter of taste, and more importantly local circumstances.