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