Breaking User Stories into Tasks | David Tzemach
Updated: Mar 3, 2022
As part of the planning meeting, the Scrum development team initiates a process of story breakdown. Stories are divided into smaller containers of work called Tasks. These tasks determine the work that needs to be completed by the team to finish a user story. A good breakdown of a story will include duties covering all implementation aspects.
Story Name: Develop the Authentication Window
Tasks:
Create a design for the authentication process.
Investigate authentication methods.
Develop the user interface.
Develop the authentication process.
Ensure integration with component X.
The process of story breakdown is not as easy as it seems, so I want to share some interesting observations from the industry:
There is no need to wait for the planning meeting to perform the story breakdown. The team can often begin this process earlier using pre-planning sessions or even as part of the refinement meetings.
The process of story breakdown often reveals additional work the team will have to do. It directly results in increasing the time to complete the story. However, this will be a more realistic estimation.
During story breakdown, there is a probability that the team will need to split the story into smaller stories (leading to re-prioritization by the Product Owner).
During the task breakdown, the team may discover that they need more information.
There is an excellent chance that the team will add or remove tasks during the sprint.
The process of story breakdown is more effective when the Product Owner is involved.
The team will fail to perform an effective breakdown process if each story does not contain the necessary information such as DoD, DoR and acceptance criteria.
How Detailed Should Tasks Within a User Story Be?
Whether splitting stories or creating tasks, the debate is ongoing by many Agile coaches and teams regarding the level of detail a user story and associated tasks need. While in stories, we have a few guidelines (derived from the Scrum guide itself) that make it easier for everyone to understand what details should be included (acceptance criteria, technical detail, format, etc.), it's different for tasks. Each team will need to decide what information should be included. There are no restrictions on what they can or cannot do.
Some people believe the time spent discussing and adding details to tasks is wasted; rather, this time would be better spent on the actual implementation process. Others believe ignoring team discussions and not adding details will leave the team lacking fundamental knowledge to implement the user story correctly.
I have been involved in numerous discussions and have written below a few simple guidelines that have worked well for my teams:
If a task takes more than one day, it should be broken down, so the team can finish each part within one day.
Only the Scrum development team can determine the level of detail they require for each task.
One person should complete a task within the team (team members may choose to pair up if they need help or an available member who is idle).
As long as the team keeps to the story estimations, they can add as many tasks as they like.
A user story will not be part of the planning session unless the team agrees that they have all the required information to break it into tasks.
All team members should take an active part and share their thoughts to add tasks related to research, programming, and testing.
Different Agendas Related to Task Estimations
There are different opinions about estimations of tasks, such as “don’t estimate them at all” or “estimate them to fit one day of development.” These are all good practices in the industry.
However, what works best for my teams is to give stories relative estimations and not to estimate tasks at all due to the assumption they will not exceed one day of work of a single team member. One-day tasks will allow the team to enjoy a few essential benefits such as:
One-day tasks help development teams to focus on a small chunk of development work at a time.
One-day tasks help the team increase development efficiency by reducing the complexity of tasks, allowing more team members to take ownership.
One-day tasks make it easier for the team to increase the transparency of their work progress.
The team can inspect and adapt their work daily.
The SMART Model of Task Creation
One way to ensure that tasks have all the suitable characteristics is to use the SMART model. SMART is a term that started in the project-management world in the 1950s. It was used to create valuable objectives for setting project goals and creating tasks.
Let us examine SMART more closely:
S - A task must be specific
A task must be specific enough for each stakeholder to understand what it requires and the scope of work. This helps keep the team focused on one main development activity. It also helps the team know whether the tasks add to the whole story. One must also ensure that tasks do not overlap with one another.
M - Measurable to understand when it can be marked as done
A task must be measurable so that the team can know when it is done. The team decides which criteria define the task as done. The idea is to give the team the tools to understand their progress and remaining items.
A - Achievable by its owner
The task owner should be able to complete the task. If the task owner does not have the capabilities to complete it, it should not have been under his ownership. Alternatively, the task should be broken down into smaller tasks to reduce complexity and allow success.
R - Relevant to what the story aims to achieve
Every task added to a story should support its goal. Stories are broken into tasks for the benefit of the Scrum development team and other stakeholders, who will want to know how each task contributes and whether it was justified.
T - Time-boxed to reduce wasted time
It is easy to understand why tasks ' duration should be time-boxed in a framework that embraces timeboxing as one of its core principles. This enables stakeholders to view when the tasks and related stories are expected to be completed.