Skip to main content

The Indivisible Task

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, 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.


Popular posts from this blog

Continuous Integration of Python Code with Unit Tests and Maven

My main development language is Java, but I also some work in Python for deployment and related tools. Being a big fan of unit testing I write unit tests in Python using PyUnit. Being a big fan of Maven and Continuous Integration, I really want the  Python unit tests to run as part of the build. I wanted to have a solution that met the following criteria:
Used commonly available pluginsKeep the maven structure of test and src files in the appropriate directories.Have the tests run in the test phase and fail the build when the tests fail.
The simplest approach I came up with to do this was to use the Exec Maven Plugin by adding the following configuration to your (python) project's POM.

<plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>exec-maven-plugin</artifactId> <executions> <execution> <configuration> <executable>python</executable> <workingDirectory>src/test/python</workingDirect…

Displaying Build Numbers in Grails Apps

Being a fan of Continuous Delivery, identifiable builds, and Continuous Integration: I like to deploy web apps with a visible build number, or some other way of identifying the version. For example, having the build number on the login screen for example. In the Maven/Java world, this is straightforward. Or at least I know the idioms. I struggled with this a bit while working on a Grails app,  and wanted to share my solution. There may be other, better, solutions, but the ones I found approaches that didn't quite work they way that I'd hoped.

My requirements were:
To display a build number from my CI tool, where the number was passed in on the command line. In Bamboo, for example you might configure a grails build as
-Dbuild.number=${bamboo.buildNumber} warTo only change build artifacts and not any source files.To not misuse the app version, or change the names of any artifacts.To be simple and idiomatic.I realized that that Grails itself changes the application metadata (appl…

Motivation Visibility, and Unit Testing

I've always been interested in organizational patterns (such as those in Organizational Patterns of Agile Software Development). I've recently found myself thinking a lot about motivation. I'm now reading Drive: The Surprising Truth About What Motivates Us and just finished Rob Austin's book on performance measurement. Being the parent of a three year old, I'm finding more and more that "because I said so, and I'm right" isn't too effective at home. My interests in motivation are closely related to my interest in writing software effectively. Writing software is partially a technical problem about frameworks, coding, and the like, but the harder (and perhaps more interesting) problem is how to get a group of people working together towards a common goal. Agile practices, both technical and organizational, build a framework which makes having the right amount of collaboration and feedback possible. But there's a bootstrapping process: How do yo…