Stop Adding Tasks to User Stories

Creating tasks for each user story before implementation may seem like it is adding value and saving you time in the long run, but is it? Is it really? Or is it something you have always done without questioning its value?

Despite the Scrum guide making no mention of task-creation (or user stories for that matter) during sprint planning, many Scrum teams spend hours creating tasks, assigning people to those tasks, and estimating hours per task. I’ve worked on various Scrum teams for fifteen years, and we always created tasks before we started any work. It’s just what we did. We never thought to analyze whether the time and effort we spent tasking was worth it.

Let’s take a few minutes to break down and analyze the process and assumed value-add. First, here are the steps many Scrum teams follow to create tasks in sprint planning:

Common reasons people cite for tasking:

1. To figure out all the steps needed for each story in advance. The theory is if you plan upfront, it will save you time since you won’t have to spend time figuring out the steps while implementing the story.
2. To figure out who will take on which tasks
3. To create hour estimates for the work
4. Because our ScrumMaster told us to

Now let’s analyze each reason:

1. To figure out all the steps needed

If the user story is complex and something you haven’t done before, determining tasks for it upfront will be difficult. You may spend an hour or more making your best guesses to come up with tasks. Then once you start working on it, realize many of your upfront assumptions were not right. Instead, the right steps emerge, and the tasks change as you learn more. In this case, at best, the time spent creating tasks in sprint planning was wasted time. At worst, the initial incorrect tasks may send you off in the wrong direction and cause you to build the story in a sub-optimal way, which you may not discover until the end of the sprint. Now you will have to go back and refactor it in another sprint.

If the user story is similar to previous stories you’ve implemented, creating tasks is easy. After a few sprints, teams come up with “boiler plate” tasks for these types of stories. When implementing, individuals often don’t look at the tasks until they are finished, rather simply going through the motions of closing each task. That seems silly. If there are common steps many of your stories follow, why isn’t that part of your definition of done? Or part of a shared understanding? Even saving a few minutes every sprint NOT doing something that doesn’t add value and isn’t necessary will start adding up to saved time you can use to create increments of value.

2. To figure out who will take on which tasks

This reason may make sense for team members who are new to working in Agile. In traditional development, each individual’s work is identified way, way, way upfront (often 6+ months in advance).  In waterfall development, the emphasis is on planning the work of individuals who largely work in silos and in a fair amount of isolation. In Scrum, the emphasis is on team collaboration. A Scrum team collectively succeeds or fails. A high-functioning Scrum team often swarms and pairs to get work done faster and with higher quality. Assigning tasks upfront can create an invisible barrier that may prevent teams from true collaboration.

3. To create time-based estimates

I always thought it was odd to estimate tasks. In Agile, we are so conscientious about keeping estimates high-level and not estimate in hours (using something like story points instead). And then we end up decomposing each story into tasks and then estimating each task in hours to determine how long the story will take to complete. Wait, what? Why?

4. Because our ScrumMaster told us to

If you are tasking because someone told you to, then first ask yourselves, is this tasking effort adding value to our team? If the answer is truly yes, then great. Keep doing it. If you aren’t sure, have the discussion, do some experiments not tasking upfront, and decide if your time would be better spent doing work rather than trying to plan the minutia of it.

Join NextUp’s User Story Workshop on January 19, 2022, to learn how to create valuable, actionable user stories and more effective estimation techniques.