Why Estimate Twice In Scrum?

Why Estimate Twice In Scrum?

I use this question in interviews. Most candidates struggle to come up with an answer.

Many Scrum teams estimate both in Story Points and in hours. Why not just estimate in hours and save yourself the hassle of estimating twice?

Quick And High-Level Estimation Using Story Points

Story Points allow a team to quickly estimate how much work a PBI (Product Backlog Item) represents. It is accurate enough to plan ahead without being time-consuming. We want to be able to provide a rough forecast to our stakeholders.

The idea behind Story Points that instead of estimating in hours, you use previously completed work as reference to estimate new work. People are better at estimating relatively. So instead of starting from scratch with each estimate, you compare it to something that the team has already completed.

The team agrees calibrates some past work items and agrees they represent a certain amount of work, for example 3 and 8 Story Points. During a planning poker session, future work is estimated relative to these reference work items. Is the new item we want to pick up similar in size to the 3 Story Point item or the 8 Story Point item?

The team can only pick from specific numbers from a fibonacci-like sequence: 1, 2, 3, 5, 8, 13, 20, 40, 100. Once the team reaches agreement, you have a rough indication how much effort the work item represents. See my previous article if you want to know in detail what Story Points and how they should be used.

Breaking Down In Small Tasks And Fine-Grained Estimation In Hours

In Sprint Planning, the team breaks down PBI’s in small tasks team members can pick-up. The team estimates these tasks in hours. The total work is the sum of all tasks in hours. This can then compared to the actual capacity of the team to deliver work.

---

Benefits Of Estimating Twice

1. More Control Over Your Sprint.
   By estimating all tasks in hours it is possible to create a sprint burn-down chart in hours. Every day you can check if the sprint is on track. It provides more information on the current situation of the sprint.

2. More Accurate Estimates.
   By breaking down the work in small tasks the estimates become more accurate. The work needs to be clear to be able to break it down in small tasks.

3. Preventing Over- And Under Committing
   Imagine your team has a capacity of 400 hours to perform work. By estimating in hours you can determine if the capacity is enough to deliver the sprint. It is also easy to take into account holidays of team members and unexpected situations. It could also be that somebody in the team has the capacity to do more work, so you are able to take this into account during Sprint Planning.

4. Clear How Much Work Is Left For Unfinished Issues.
   When a PBI of 13 Story Points is not finished during the sprint it is unclear how much work is necessary to complete it. If all sub-tasks belonging to a PBI have an estimation in hours it is transparent how much work is left.

5. Valuable Input For Retrospective.
   When all work is estimated in hours, it is more easy to determine which issues the team spent more time working on than expected. This is useful input to improve the estimation of future issues. The team could also conclude that they should make their issues smaller. When using only Story Points it is harder to notice what issues the team spent working on more than expected. As we do not know how many hours an issue of 8 Story Points should take exactly.

---

Disadvantages Of Estimating Twice

1. Overhead Which Does Not Necessarily Improve Accuracy Of Estimates.
   When your team has a stable velocity in Story Points, then estimation in hours may not be necessary. It may just be an extra step that introduces overhead. If you can plan accurately using Story Points, then why waste time estimating in hours?

2. Working In Hours In Combination With Logging Hours.
   People generally do not like logging their hours, as it is an administrative hassle and annoying to do. It also immediately becomes clear when you are spending more time than expected. This may lead to guilt and lower productivity. It is really important that the whole team understands why you work in hours. You do it to plan better and learn from your estimations.

3. Working In Hours May Lead To Micro-Managing Or Punishing Team Members.
   When working in hours it becomes easy to micromanage and confront developers. It is tempting to interrupt them when they are spending more time on something than expected. It is also easy to become angry at a team member because they are not delivering on time. This is counter-productive. Do not punish people when their estimations are off. It should be an opportunity for learning to try do it better the next time.

Conclusion

There are clear benefits and disadvantages to estimating in hours after you already estimated in Story Points. When the velocity of your team is stable, then it may not be necessary to estimate in hours. Some people see estimation as a non-value adding activity you should do try to do as little as possible.

Estimating in hours fits well with the empirical approach of Scrum. It provides an opportunity for learning and gives more fine-grained control over the sprint. It is important that all team members understand why you are using hours. Otherwise it may prove to be very counter-productive and not worth the effort.