I’m often asked if it is necessary for teams to create tasks on Scrum projects. While the Scrum Guide does not mention tasks specifically, it does say that “Work planned for the first days of the Sprint by the Development Team is decomposed by the end of [the Sprint Planning] meeting, often to units of one day or less.” Generally, I agree with the Scrum Guide approach; however, whenever I work with teams that are new to Scrum, the team members usually have a very negative opinion of writing tasks.
From the team's perspective, it's easy to see why they should be skeptical. On Waterfall projects, teams are asked to break down work for months (and in some cases years) ahead of product delivery. They know that identifying tasks even a few months out is a waste of time because the time horizon is too long to provide an estimate with a high level of confidence. In the Waterfall scenario, the Project Manager tracks these tasks in the WBS (Work Breakdown Structure) and reports the status out to management. Often the practice becomes an excuse for the Project Manager to bludgeon the team with tasks they “committed” to do. Conversely, in Agile development, the WBS belongs to the team, not the Project Manager. The teams should be more focused on delivering valuable working software and minimizing waste, not task completion. The tasks by themselves don't provide any real completion value.
So when is it appropriate for the team to write tasks, and when is it inappropriate?
Next time you run into this quandary, ask yourself and the team, the following questions:
- How long has this team been working together? The shorter the time frame, the more likely they should write tasks
- How long has the team worked with the “requirements” (User stories, MMF’s) approach? The shorter the time frame, the more likely they should write tasks.
- How experienced is the team with working on Scrum Projects? The less experience they have, the more likely they should be writing tasks.
- How often do the backlog items fluctuate in size? The more variation in size, the more likely the team should write tasks.
- How well is the problem domain understood? The less the team understands the problem domain, the more likely they should write tasks.
- How well is the technology used in providing the solution understood? The less the team understands the technology, the more likely they should write tasks.
- How well does the team organize around the work? Visualizing tasks aids with organization of work and helps the team identify what tasks remain to be completed. The less the team is able to organize around the work, the more likely they should write tasks
The level of task detail should be left up to the team and the team should not waste a lot of time on breaking down backlog items into tasks. Remember, the idea is not to identify every task, only the essential tasks. If unsure, ask the team to write tasks in the first sprint or two of the project. They can always adapt the process based on the feedback the team provides at the retrospective.