[AnimalMuppet]

You don't predict that. You measure it.

That is, we estimate a certain set of tasks. For this two-week sprint, we're going to try to do a subset, and that subset adds up to 20 story points. After two weeks, how much did we actually get done? 7 story points. Next sprint we did better, we got 11 done. After a few months, we settle down to an average of 10 story points per two week sprint. Now we know how many hours something is (estimated to be) based on the story points.

Note well: This velocity is a function of the team. If the team composition changes, previously measurements of velocities are no longer valid.

[cortesoft]

In all my years of software development, story points never became an accurate predictor of time, even with consistent teams and process. The types of tasks we would be working on varied too much and were too novel to become predictable.

If we were working on one app and just adding features and fixing bugs, maybe it would converge to a consistent average. However, I have always worked on teams that have myriad projects, moving in and out of development, with constant support and interrupt driven work taking up a huge variable amount of time.

[hinkley]

Management always gets frustrated when this doesn't materialize. If the instrument meant to keep management off your back doesn't do so, people will get frustrated with it.