Accurate Project Estimation

The biggest challenge is whether team is able to divide the user story into small tasks. Another challenge is whether they have covered all sub tasks. I personally feel that team needs to spend sometime looking at the user stories to be discussed and estimated in sprint planning meeting else we can not reach to the stage of accurate estimates. Any thoughts / suggestions?

"Consistent velocity unlocks the power of estimating larger bodies of work." -- This is the key that has worked for us. For years in both government/military and the corporate world the mantra was break it into details and cost it out. This approach, for the vast majority, consistently resulted in late and buggy projects (yes, they did the "do it in half that time" routine regularly).

Instead, when we simply looked at our past history and saw things like averages of 18 months to launch a new product we knew we had a better idea. We just picked our historical average and said that is how long it would take. The initial reaction was "No way! Why so long?!" which is humorous because the typical "plan" was something like 12-15 months even though the average performance was 18 months (and *never* 15 or less).

I never saw much in Agile I cared for (hated the notion of pair programming) but when I saw Scrum and then saw it using the velocity concept (a historical average) I fell in love with it.

Bottom line, it isn't the analysis of the details that made the difference, it was knowing our actual historical past performance and using that recent past performance as our project estimate. We then never delivered a project more than two weeks late and have been up to a month early.

Ref 1: Its The Schedule: pmtoolsthatwork.com/its-the...
Ref 2: Its Not The Requirements: pmtoolsthatwork.com/is-your...

Why the anger? The author is describing what's worked for him and specifically recommends Scrum as a way of implementing getting good results with these techniques.

However, he is very definitely not describing Scrum, which is a much larger systemic approach to a different problem. Sites that don't use Scrum but need better estimation will surely find value in knowing these best practices.

Glad you mentioned McConnell's book (which actually came out in 2006), "Software Estimation:Demystifying the Black Art." Indeed, it covers some of the ground covered here and makes a good follow-on text for readers looking for more information.

This guy just described scrum. Steve McConnell's book on project estimation from 1999 or so discusses this stuff in detail. So a pretty sad article.

It is "easy" to estimate time for individual software modules. One hard problem, which always occurs, is estimating time for integration...

"By decomposing work
into small tasks, accurately assigning points to those tasks, ...."
Any advice on how to accurately estimate the time it will take to decompose work into small tasks?