Let's face it.... estimates are always going to be estimates! Not actuals.
No matter how much time we dedicate to getting the estimates "RIGHT", chances are they will still be wrong. They don't take into account the proverbial "unknown, unknowns" and in software development any item of work can contain unknowns or complexity that blow the estimates right out of the water!
In traditional project management the tendency is to chase reasons for "wrong" estimates and track actuals against estimates in some kind of attempt to get "better" at estimating. As a result, teams spend a lot of time putting hourly estimates on user stories, which still have a very high chance of being incorrect, so why bother? What a waste! Instead, spend a little bit of time estimating and be just as wrong/ right in the end!
I suggest a "mature" attitude to estimating.
- assume that the work will take as long as it takes
- assume that everyone will do the best job they can on a user story
- assume the team will not cut corners on quality
- assume no unnecessary over-engineering
- estimate "how big" user stories are using the fibonacci scale and comparatively estimate each story against other stories. (Is this bigger or smaller than the last one? How does it compare to our benchmark stories)
- use the fibonacci scale because the gap between numbers increases as we go higher. This mimics software development in a way because the bigger the story, the higher the risk of unknowns or complexity creeping in which will increase the amount of time it takes to develop.
- Based on the previous sprint's velocity, the current sprint's capacity and very importantly, gut feel. Project how much work the team can get done in the upcoming sprint
- Use this projection to manage expectations of when you can deliver your features/ software/ product
- If you "under-estimate", and have extra capacity left in a given sprint, then try to take extra stories into the sprint. (Pull system)
- only take in additional stories if you can finish them by the end of the sprint otherwise you will affect your ability to be "potentially deployable" at the end of that sprint
Really, what management and product owners want to know is when we can deliver our products and they want predictability. The above method still gives us these things, but without the pain of hour estimation and actuals tracking.