Saturday, January 24, 2009

Measuring value during an iteration

I'm currently working on a large agile project where we measure task burn-up. Our user stories are decomposed into individual tasks and the tasks are estimated. When a developer or a development pair completes a task, they mark that task complete in the tracking system. A daily chart is then generated by the tracking system that displays a line graph of units of tasks completed in the current iteration. The cumulative total task units from the estimates is another line on the graph, and it typically stays horizontal across the entire iteration. Up until recently I hadn't given much thought to these generated charts.

Now I'm wondering what value these charts actually provide. If management is interested in seeing that people are busy working and completing tasks, then these charts are spot on. They definitely will show the amount of work completed during the iteration and when it's completed. But really, is that metric all that important? I tend to say no. One issue off the top of my head that I have seen happen in our group is the completion of tasks on stories, but not fully completing the stories. For whatever reason, our user stories are drifting from one iteration to the next, never reaching the point of completion. Therefore, I conclude that we're keeping ourselves busy, but not adding any value to the overall product.

I want to know how much value I have built into the product. To measure that quantitatively, you need to measure user story burn-up. If you measure user story burn-up, you will focus the development team on completing stories. I think the emphasis needs to be on the user story; the task is a planning construct that just helps us decompose the story into units of development that can be worked on concurrently by a number of developer pairs. I don't know if I really care about task estimates anymore either. I'm drifting towards estimating at the user story level only.

1 comment: