Whether splitting stories or creating tasks, the debate continues on many agile teams about the level of detail that should be included in a user story and associated tasks. Some people believe that the time spent during sprint planning meetings debating details and estimates would be better spent implementing. Others believe that not enough time is spent on details and estimates, leaving the team with a lack of clarity on what needs to be done during the sprint. To be the most efficient with their sprint planning and focus on having working software by the end of their sprint, agile teams need to go into just the right amount of detail.
What are sprint tasks, and are they needed?
Sprint tasks are used by teams to decompose user stories or product backlog items (PBIs) at the sprint planning meeting to a more granular level. In scrum, planning and estimates become more detailed over time. At a high level, a project may start as epics, themes, or features, which are then broken down into user stories. Tasks are used to break down user stories even further. Tasks are the smallest unit used in scrum to track work. A task should be completed by one person on the team, though the team may choose to pair up when doing the work.
Typically, each user story will have multiple associated tasks. Sometimes these will be created by function, such as design, code, test, document, or UX. Some might say this sounds like waterfall, but using this approach on each story is acceptable and considered agile. Because the team is cross-functional, having tasks arranged in this manner allows team members to work in parallel on their area of functional expertise to complete the story as a team.
Likewise, some people feel that it's "anti-agile" to have "too many tasks" for each story and fear it will introduce overhead, such as estimating, monitoring, or tracking tasks. One option teams have that can minimize these processes is to create tasks, perhaps just with sticky notes on a physical task board.
What does the Scrum Guide say?
Though there's plenty of scrum literature that give recommendations and best practices associated with estimates, user stories, and task creation, the terms "user story" and "task" don't appear in the Scrum Guide by Ken Schwaber and Jeff Sutherland.
Regarding the sprint planning meeting, the guide says:
The work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum Team. Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches the Scrum Team to keep it within the time-box. Sprint Planning answers the following:
• What can be delivered in the Increment resulting from the upcoming Sprint?
• How will the work needed to deliver the Increment be achieved?
The Scrum Guide doesn't suggest that tasks are required, and it doesn't recommend task size or a specific estimation process. It does suggest that refinement of product backlog with details and estimates is an ongoing process and "usually consumes no more than 10 percent of the capacity of the development team." So, while the Guide doesn't suggest how much detail should go into user stories or tasks, it does advise time-boxing the time spent in planning and refinement.
Tasks shouldn't take more than a day
There may be differences in opinion on estimation or other processes related to task management, but trying to keep the tasks small enough that they can be done in a day or less seems to be the generally accepted practice.
Although the Scrum Guide doesn't specifically refer to tasks, the guide says:
"Work planned for the first days of the Sprint by the Development Team is decomposed, often to units of one day or less."
There are several reasons that experts recommend this:
- Daily tasks would match the cadence of the daily stand-up. By having tasks that take a day or less, progress (or lack thereof) is clear at the daily stand-up meeting.
- Daily tasks increase the transparency of what everyone on the team is working on.
- The team is able to inspect and adapt daily.
- Limiting tasks to a day or less can help developers create flow, with focused, uninterrupted time.
That being said, there's no "rule" that tasks must be time-boxed to a day, and some teams may be finding success in not limiting the size of their tasks. The team should reflect on whether they're meeting the goals of the sprint and adjust accordingly.
The benefits of creating tasks
Regardless of the size of the tasks, at some point, typically the sprint planning meeting, the team needs to get any answers or clear up any assumptions they may have made regarding a user story. Up until this point, the user story may have only served as a placeholder for a "conversation," but as it nears the top of the prioritized backlog, the team needs to understand all the acceptance criteria and get a complete understanding of the definition of done.
Breaking the user story down into tasks helps the team determine how they'll approach the story. By getting into this level of detail, any unknowns will be uncovered. The team discusses edge cases and error conditions, getting answers from the product owner about expected results in various situations. Brainstorming in this way allows the team to collaborate on the best way to implement the story, which reduces miscommunication as the team discusses the best approach. The team may benefit from having a template with common types of tasks or things that need to be considered with each story.
Creating tasks helps clarify any unknowns that may lead to splitting the story or creating "spike tasks." Creating a spike task is described in Sprint Tasking Tips by Charles Bradley:
Essentially, create a task to remove the uncertainty around what the tasks should be. The way I usually coach this, there is the "spike task" which has some sort of estimate, and there is a "big bucket placeholder follow on task" which also has a rough estimate—usually larger, but not always. Then, the purpose of the spike task is simply to remove the uncertainty. Once the spike task is complete, the person or people who completed [it] can propose a set of "follow on tasks" to the Dev team, that will replace the placeholder tasks.
It's noted that spike tasks should be rare and are an indication that there may be a need for better backlog refinement.
Splitting stories is another option that can occur as a result of tasking. If you discover unknowns in the process of discussing a story and the tasks that will be needed to complete it, there may be the option of keeping the story simple and adding a second story for the next iteration. After completing the simpler story, the team may be better equipped to task and estimate the more complicated pieces.
What about estimates?
Though there's general agreement that tasks should be kept to a day or less, there are differing opinions about estimates, tracking, and monitoring tasks.
Some people feel that tasks should be estimated in hours and re-estimated daily, so the burndown chart shows a proper reflection of the status of the sprint. Arguments for this approach include the need for transparency, and the fact that daily updates reflected in the burndown chart would help provide visibility into times when the team might be at risk of not completing the stories on the sprint backlog.
The primary argument against estimates, tracking, and monitoring tasks is that these are micromanagement activities that create overhead. One way to get around this might be to get creative in minimizing processes that aren't adding value. One way teams are doing this is by "right-sizing" tasks into similar chunks of time, such as a day or half a day. Doing this is easier than estimating hours when things like interruptions, reading email, and meetings happen throughout the day.
Getting the right level of detail for the user stories and associated tasks during a sprint planning meeting can be a challenge. The team needs to have enough detail to implement the story, but they also need to be efficient in their sprint planning meeting. Creating tasks that take about a day or less is the most common practice. Though the team should avoid getting bogged down with unnecessary processes, discussing the approach and the tasks needed to complete the story will help the team reach a common understanding of what needs to be delivered at the end of the sprint. As the team gains experience and continues to inspect and adapt, they'll soon find that their stories and associated tasks will give them just the right amount of detail needed for a successful sprint.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
