Agile user story's task estimation

Question

I have some confusion regarding the concept of a user story's task's estimation (effort estimate) using hours. What is the actual purpose of estimating effort in hours?

In addition to that, let's say my team's velocity is 50 story points and our Sprint duration is 2 weeks. In the Sprint Planning meeting, we have pulled 50 points' worth of user stories to the Sprint Backlog. Then we started to break user stories into tasks and estimate the effort using hours. Then we have noted that the total hours of all tasks (for all the user stories) is 2.5 weeks. In this situation, the task estimate (effort estimate) is conflicting with velocity. So how do we overcome this?

Answer 1

Estimating using story points at the story level and time at the task level isn't necessary, but it can be useful, particularly for teams that are new to Scrum.

Some reasons for using time-based task estimates include:

• The time-based estimates can act as a sanity check against your story point capacity
• If you have specialists in your team, you can check to make sure they aren't overloaded or under-loaded
• The act of doing the task level estimate can draw out some discovery conversation that might not otherwise take place
• You may have a team rule about a maximum duration for a task (e.g. no task takes longer than a day)

A lot of experienced Scrum teams find the overhead of doing the task level estimates is not worth the benefits. For newer teams though it can be a nice transition step away from a more traditional estimating approach.

Answer 2

To answer your first question re: the purpose of estimating effort in hours, it's really more complex than simply time/item. We're dealing with people here, and people have different skillsets, speeds, and knowledge. If you use hours, you obscure the main reason to use story points in the first place, which is to allow team members who perform at different speeds to communicate and estimate collaboratively.

Being practical, three developers can start by estimating a given user story as 5 points even if their individual estimates of the actual time on task differ. Starting with that estimate, they can then agree to estimate something as 3 points, relatively speaking to the criteria of work the entire team has already completed. When story points equated to hours, team members can no longer do this.

In this scenario, story points are still about effort, but the amount of time per point is not pegged to the same amount for all team members. Story points allow for collaborative, relative estimations without the need to take into account each individual developers time to complete the task.

To answer your second question, I recommend NOT planning out the entire sprint at Sprint Planning. I especially recommend not even paying attention to hours/item. Instead, focus on the highest-valued items first, and as requirements emerge, integrate them into the sprint if they help your team achieve their sprint goal. Use your metrics to help forecast your effort. Your entire sprint doesn't have to be planned at Sprint Planning, but you should have an understanding of how the work your team has pulled in will get them to their goal. Delivering value should always be more important than understanding how accurate your forecasts are sprint-to-sprint. That doesn't mean accurate estimations aren't important, but delivering value should be the primary focus.

Answer 3

Finally, I understood some benefit of estimation of tasks using hours and how to overcome my second question.

According to my understanding, breaking user stories into tasks is beneficial to understand “how much work the Team can commit to for a Sprint”, if we don’t know the team's velocity. However, before estimating tasks, the Scrum Master (SM) should prepare a team’s capacity planning to understand what is the maximum/total working hours the individual members will have in the Sprint.

After that, in Sprint Planning, the Team can break user stories into tasks and the SM can facilitate to monitor the individual task commitments against the total capacity of an individual person. If one member is exceeding the total capacity, the SM should inform the Team. In this way, we can avoid the overloading or underloading of a Team member within the Sprint.

Once all the Team members have committed to tasks with their full capacity, we can identify the velocity by calculating the committed user stories. However, if the Team is mature enough to estimate using user story points and we know the average velocity (after running 4+ sprints) then there is no need for breaking stories into tasks, unless the company uses individual commitments as their annual evaluation Key Performance Indicators.

To avoid exceeding the Sprint length, the SM should prepare a capacity planning before individual task commitment. The SM should monitoring the capacity of each individual Team member by examining to his/her total capacity so that the Team will not exceed the Sprint length with the estimation. However, in this method, we cannot pull user stories to Sprint Backlog by considering velocity, then break them into tasks and again estimate using hours. Either we have to pull stories by considering the velocity or we have to pull stories using the Team’s capacity.