(I originally posted this on my MSDN blog.)
Over the past few months there have been several interesting email threads on internal aliases at work that have helped clarify my thinking about various Agile topics. I thought I’d share some of the things I wrote in hopes that it’ll be useful for someone.
The first one I want to share is has to do with tracking Scrum sprint process. A few people, including me, were advocating a low-tech approach to tracking sprint tasks using stickie notes on a whiteboard and not bothering with hours spent on each task. Someone asked, “If you don’t track estimated vs. actual hours spent on each task, how do you create a sprint burndown chart?”
My answer:
If your sprints are fairly short, like two weeks, and if your stories are fairly small and granular, then you can do a rough burndown chart just showing the number of story points that have been completed so far in the sprint and get almost all of the value you need from the chart. I’m personally convinced that a lot of teams spent a lot of time collecting detailed metrics and then don’t actually do anything useful with those metrics to justify the time spent to generate them.
What does a detailed hours-spent burndown chart buy you? If your sprints are long (say four+ weeks), then it helps you do mid-course corrections and cut stories if you’re not trending well. It might also help you identify chronic estimation problems so you can work on fixing them.
I think both of those benefits can be gained by simply shortening the length of your sprint cycle. Over a two-week sprint, you’re not likely to drift very far off course. At the end of the two weeks, where you might have a mid-course correction in a long sprint, you simply plan another sprint based on where you are now. And if people made bad estimates of story sizes that caused you to over-commit and not finish the sprint backlog, both the estimation and the surprises discovered during implementation should still be fresh in people’s minds and you can discuss them in your retrospective. You don’t need detailed metrics to capture that information and hold it for weeks until you can get around to discussing it.
Sprint burndown charts based on hours spent vs hours estimated look really cool and they appeal to the innate engineer/geek sense in all of us. I’ve just found that when I weigh the benefit that data actually gives me vs. the hassle it cost everyone to collect it, it’s generally not worth it.
So to be specific, I prefer to put my stories up on a whiteboard with sticky notes for individual tasks in a column underneath each story. We don’t estimate the tasks in hours. (During the sprint planning meeting, we do a quick double-check of the decomposed tasks against the original size estimate for the story to make sure we’re still comfortable with it.) Then as the sprint progresses, people grab task stickies and move them to an “in progress” row as they work on them, and then to a “done” row when they’re done. A quick glance at the board will give us a ballpark feel for where we are, which in a two-week sprint is all we need. If we want a slightly better feel for how we’re trending, we might build a burndown chart based on story points completed vs. scheduled.
There’s very little overhead with this system, it’s pleasant to use, we don’t have to harass devs about entering their hours every day, and it gives us the information we need to deliver business value in a predictable manner, which is the whole point.
SaintGimp 