At the beginning of each sprint our team will pull in a handful of user stories and then, one by one, write slightly more detailed tasks for them as well as assign specific hours to each task.
Having individual tasks helps us establish our sprint burn-down by having a specific total number of hours up front, as well as make it more feasible to keep track of who’s working on what and what all has been completed.
However, I recently read that some mature Agile teams have eliminated the use of writing tasks altogether and head right into their sprints armed only with their user stories as the modularized sources of work for the sprint.
I’m having a hard time seeing how eliminating task planning could still provide an Agile team with small enough units of work so as to keep the sprint organized and transparent. Has anyone here tried or use this approach and if so how do you keep track of exactly who is working on what?
2
Our team actually does it both ways, depending on the user story. Well, we actually still do one big task called “Fix it” or something, so the burndown chart will still work on our tool.
The difference for us is how easy it is to predict the tasks in advance. For example, we do embedded software, and whenever we have a brand new board to get booting it’s very difficult to predict the individual parts, but by experience we know how long it usually takes for everything together. One time the clocks might be perfect but some power rails are unstable, the next time it might be the other way around.
Also, some teams break their user stories down into smaller parts than others. Our team averages around 12 per sprint. Other teams at my company average 3 or 4 per sprint. The smaller your stories, the less you need tasks.
It boils down to choosing what works best for the style of your individual team. If you can’t imagine working without tasks, that shouldn’t make you feel inferior. On the other hand, if you feel like tasks are a hindrance, you should feel free to discard them.
1
I’ve worked on the ‘big picture’ thing with an Agile team before – work beautifully. We spent all our time doing work, rather than doing the process planning and task creation and project organisation.
You should try it, its amazing what you can do when you step away from the proscribed processes.
Naturally, it depends on you though – if you need tasks to make you productive, then keep doing them. If you don’t need tasks to be productive, scrap them immediately. Isn’t that the spirit of Agile?
4
It all depends on how the team wants to manage its time and consume stories, and how well that works for the Scrum Master and other management staff that care about metrics.
Task breakdown is a good way for a team to verify the original estimated complexity of the story (usually estimated way back in a “milestone planning meeting” given only a high-level view of the requested features), and to plan out the division of labor based on the various “critical paths” through the stories in the sprint backlog. By breaking the stories into tasks, you can see your progress from day to day on a burndown chart, without having to log actual hours spent and estimated hours remaining on each story; when the task is done, those estimated hours come off the top, and the results are the same as if developers were constantly inputting estimated remaining time (and who wants to be doing that all day?).
It’s useful to the point of necessity in two common situations:
-
Your team’s “hours per point” metric is greater than a developer-day. If one developer would regularly report that they’re working on the same story for two or more standups, then to get an idea of progress from day to day through the sprint, it’s virtually a requisite to describe that progress in terms of smaller pieces of the larger story (just like most everything in Agile is described), i.e. tasks. Otherwise, if a developer was assigned a story that will take him the entire iteration to complete, then his story’s points value just sits there in the burn-down until the last day, when he either makes or breaks the sprint.
-
Two or more developers will be working on the story. If two developers have to divvy up the work, then it’s critical that they break the work down into chunks that they can share between them, to avoid both of them doing the same work or neither of them doing something important.
Now, if the nature of the stories that your team regularly brings into a sprint is such that one developer could complete at least one a day, then that baseline for a “one-pointer” means that a points-based burndown makes more sense, and task breakdown is less of a concern. Your stories are already “bite-sized”, either by doing a story breakdown of larger work or simply because you’re in “maintenance mode” and only small incremental changes are being requested, such that even if you only report completed stories, your burndown will pretty accurately reflect remaining work.