Subtasks of User Stories: how and why we estimate them
As employees and customers alike continue to work from home in view of the COVID-19 pandemic, we believe it is getting even more important than ever to continue sharing our experience with regards to remote work and efficient collaboration across distributed teams. While there are various infrastructure solutions (Microsoft Teams, Slack, WebEx, Google Meet etc) suitable for distributed workflows, it is of at least equal importance to have well established processes in place. In this article we would like to explain how we work on estimations to make every Sprint Planning accurate.
We start planning a new Sprint. The Developers add several User Stories to the Sprint Backlog. Each User Story has its estimated handling time. The pooled estimate does not exceed the Capacity, that is the total workload feasible to be completed during the Sprint. The Developers confirm that they are able to implement all the functionality and achieve the Sprint Goal by the end of the Sprint.
How can we make sure that the functionality will really be ready on time? And how can we identify possible deviations in advance?
When planning a Sprint, we split each User Story in the Sprint Backlog into subtasks. Subtasks not only help us decompose big User Stories into smaller elements, but they help us distribute the corresponding work to team members. Subtasks can also be subjects of estimation. Then the estimation can be used for constructing so-called information radiators, e.g. a Sprint Burndown Chart. By analyzing the Sprint Burndown Chart, the team can conduct an inspection in relation to the achievement of the Sprint Goal. Let’s take a look at several examples of how subtasks can be estimated.
Calculating the time required for subtasks and using a Burndown Chart
At the planning meeting, the team decomposes User Stories into subtasks and makes time estimates for each of the subtasks. For example, the task list for each User Story may be as follows:
- Refactoring (6 hours).
- Implementation of the core module (4 hours).
- Finding a method for interaction with the database (7 hours).
- Applying UI fixes (2 hours).
- Creating an autotest (3 hours).
The total of the time estimates is shown in the Burndown Chart. As the subtasks become completed, the time value in the Burndown Chart will converge to zero.
Advantages of this approach
- It is possible to see the difference between the initial estimate and the actual value not only for User Stories, but for subtasks as well.
- Smaller components are easier to estimate with greater precision than anything large and generalized.
- Decomposing your User Stories, you can once again verify their initial time estimates.
- When estimating User Stories, you can use both time units and Story Points.
Disadvantages
- All the constituent subtasks are to be estimated in addition to the User Story itself, which entails more discussions during the planning and takes more time.
- Incomplete subtasks should be re-estimated at the Daily Scrum meetings. It takes time too.
- Customers are not interested in estimates for subtasks. They want to know the original estimates for User Stories, or time that has already been spent on the implementation of subtasks.
- People seldom make precise estimates in absolute units.
Making quantitative estimation of subtasks and using a Burndown Chart
In one of our projects we used the following approach: we only estimated User Stories in Story Points or in units of time, while drawing a Burndown Chart based on the number of currently open subtasks.
Example:
When decomposing our User Stories at the planning meeting, we agreed that subtasks should meet following criteria:
- They are approximately the same in size.
- The implementation of a subtask shouldn’t take more than one day.
As soon as subtasks become closed, the Burndown Chart converges to zero.
Advantages of this approach
- Time saving. The Developers do not estimate each subtask during the planning. There is no need to re-estimate subtasks at the Daily Scrum meetings.
- User Stories can be estimated in Story Points or units of time.
- The time spent on the implementation of subtasks can be logged as before.
Disadvantages
- Team’s subtasks will not immediately meet the initial criteria. For the first two or three planning meetings, the Developers will be learning how to create subtasks with approximately the same size.
- Customers are not interested in estimates for subtasks. They want to know the original estimates for User Stories, or time that has already been spent on the implementation of subtasks.
Subtasks do not count, Burndown Chart is in Story Points
Imagine there is a User Story estimated as much as 40 Story Points in the Sprint backlog. During the planning, the team also creates subtasks. Subtasks are not estimated. Later on, at the Daily Scrum meetings, the Developers will check which subtasks have already been closed, and then the team will re-estimate the User Story in Story Points.
The Burndown Chart is in Story Points based on the status of the User Story.
Conclusion
Whatever approach you choose, please keep it in mind that only a closed User Story matters to us, because only closed User Stories make the Increment for the product and are valued by the customer. Partially closed subtasks in any User Story are scrapped pieces of information as they cannot be released.
