One of the things that makes agile work well is a daily sense of progress that can be reflected in, for example, a burn-down chart. For burn-down charts to be meaningful, the estimate of amount of work remaining in a sprint need to be accurate. Re-estimating work remaining in a task is helpful, but the best measure of progress is the binary "done/not done" state of the items in your backlog.
One of the things that makes agile work well is a daily sense of progress that can be reflected in, for example, a burn-down chart. For burn-down charts to be meaningful, the estimate of amount of work remaining in a sprint need to be accurate. Re-estimating work remaining in a task is helpful, but the best measure of progress is the binary "done/not done" state of the items in your backlog.
Assuming that you have a clear definition of "done" for a task, it's easiest to measure progress when you have tasks that are small enough that you can mark them complete on a daily (or more frequent) basis. Breaking work down into a reasonable number of reasonably sized tasks is something many find challenging. (Note: I'm talking here about development tasks as part of a sprint backlog, rather than splitting User Stories in a product backlog, though there are some parallels.)
I've worked on teams when people refused to break down large task into 1-day or smaller parts. The common excuse for not breaking down work is that the person who signed up for the work understood what the work was and the estimate was accurate. Of course, we had no way of knowing that the estimate was at wrong until the work was not done at the end of the week or so.
What was interesting to me is that those most resistant to decomposition weren't less experienced programmers, but rather the people the team acknowledged as "experts" and "good designers" who were good at decomposition as it applied to designs. So the theory of attacking complexity through looking at smaller pieces was something they were comfortable with. Not only that, they actually worked in a way that led to discrete units of work being completed throughout the project, whether in terms of frequent commits or even simply being able to finish a work day with a sense of accomplishment, even if the great task was still incomplete.
Breaking down work isn't as hard as some make it sound. From a development centric perspective some of the things you already do which can guide you in task breakdown:
- Thinking about when you might commit code. It's good practice to commit code frequently; consider the Task-Level-Commit pattern from Software Configuration Management Patterns
.
- Considering what the tests you write as (or before) you code.
- Deciding what you want to accomplish before leaving work each day so that you end the day with a sense of accomplishment.
What these items have in common is that the define natural boundaries in the development process.
The main difference between doing this kind of planning and good programming practice is making your plan visible to others. This takes discipline, and a certain amount of risk, since if your plan goes awry it's visible. Part of being a successful agile team is understanding that plans can be wrong, and using that experience to figure out how to do better in the future.
You may discover part way through your planning that the task breakdown you did no longer makes sense in light of something you discovered. That's OK, but at least you have a good sense of what work was done, and you can figure out what tasks are left (and estimate them!)
By breaking down work into smaller parts you have the ability to:
- Evaluate your progress in a definitive way. as it is often easier to define "done" for a smaller task.
- Get feedback from your colleagues before you dive in to a problem.
- Share effort if any of the work can be done in parallel.
- Simplify updates and merges, as the changes to the codeline will all be small at any point in time.
It is possible to come up with too many sub-tasks, such that the overhead of tracking them on a backlog negates their value as a tracking tool. In that case, there is nothing to prevent you from taking note of the very small things you do each day and combing some of them into day or half day items that do appear on the backlog. And if you really only want to have large tasks on the sprint backlog, consider doing your own fine grained breakdown that you can use to help you give a better estimate for time remaining. I tend to favor backlogs with tasks of a half to one day, and then making personal notes about smaller steps to complete those tasks on my own.
The value of working in small steps isn't a new idea. in 1999 Johanna Rothman wrote about the value and mechanics of managing your work in terms of which she calls "inch-pebbles" (as opposed to "milestones") and Fred Brooks advised "allow no small slips" in The Mythical Man-Month
Agile teams work because they have mechanisms to give frequent feedback on status. Accurate estimates of work remaining are an essential tool for evaluating progress, and small tasks help you estimate accurately. Decomposing work is not easy, and takes discipline, but the benefits are great.
