I favour dropping the estimation of Tasks in hours for a Sprint. It’s extra work and it doesn’t add anything to the process.
- It’s proven that relative estimation is more correct than absolute estimation. Since ideal man days is a time measure it’s all too easy to make absolute estimations.
- There is no linear correlation between a story point and the number of hours. People who ask how they can correlate story points with ideal time have not yet learned to separate the concepts properly.
- A story point is a universal measurement across the team. It is not biased by the experience or skills of any individual on the team.
- In the spirit of continuous improvement Agile practitioners ought to be alert to opportunities to reduce their process overhead (without losing effectiveness).
- If each story is small enough to be estimated and tested then there may be little benefit achieved through breaking it down into smaller tasks or re-estimating them in hours.
- The return on investment by estimating in hours is not high enough to make that a serious candidate. We want completed, working software, not very accurate estimates.
- A Product Owner wants to know how many features the team will deliver not how many hours each of them take. If the Product Owner gets an idea of the relative size he can prioritise and plan accordingly.
- After the 3rd or 4th sprint, the team reaches a steady state in story points and it becomes easier for the product owner to fill the backlog with story points.
- It’s difficult and time-consuming to to get developers to estimate time to completion. Developers are terrible at estimating because the work they do isn’t the same each time: either it’s a new business problem or they are dealing with a new technology. Developers also have a tendancy to “hoard” left-over time: if they think they have been allocated so many hours to do something then the work expands to fill the available time.
Dropping hours means that in VersionOne the Sprint Burndown Chart won’t show anything at all but we can refer to the Project Burndown Chart and the Cumulative Flow instead as that burns down Story Points.