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.
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.
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, and being able to identify these slips is key to having effective sprints.
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.