The Living Room Architect

In our software projects we use story cards to describe the work we are doing for each two week iteration. Each story card is estimated using story points and the Fibonacci number scale. If you've lost me already and don't know what story cards are then I recommend reading Mike Cohen's book Agile Estimating and Planning. During each iteration planning meeting we break the story cards down into smaller task cards which are estimated in ideal days. Then during the two week iteration the team works on completing all the task cards. When the tasks are complete and all the Acceptance Tests associated with the story card pass successfully that story card is also considered finished.

During an iteration the task board might look something like this.


I'm not expecting you to be able to read the cards as long as you understand that the big cards in the left column are the story cards and all the smaller cards to their right are the task cards. As the task cards are completed they are moved from left to right across the board.

This is all great but where I've seen a number of Agile teams tie themselves in a knot is when they attempt to track all of the information on the task board in a spreadsheet or any other Agile tracking tool. Any of you who have tried this will recognise what I'm talking about and will have experienced the stupidly complicated spreadsheets you need to accomplish this. So here's my little tip for today.

You don't need to track the task cards individually. All you need to track is the sum of the remaining days for all the unfinished tasks on the board.

The task cards are extremely transient and are best when they are easy to change. Imposing any electronic tracking on them makes it harder for developers to change them and means they won't reflect what is really going on. A developer should be able to rip up a task card and/or introduce a new one at any time.

How does that impact the tracking of an iteration? How can you generate an iteration burndown without tracking the tasks? The answer is simple. All you need to update an iteration burndown each day is the sum of the days remaining for all unfinished task cards. So each morning after the stand-up you add up the remaining days for all remaining task cards and plot that number on your burndown. Tracking this way you remove the need to track specifically what happened to every single task, which ones have been ripped up and which ones are new because all you care about is the total remaining.

You can do one of two things with this total remaining days for unfinished story cards. You can enter the number into a spreadsheet or other tool for that specific day to generate your burndown. Or you can simple plot your burndown manually on a piece of paper stuck to the board.

This is a photo of one of our iteration/sprint burndowns plotted by hand.


All we did to generate this iteration burndown was at the end of each stand-up count the number of days remaining on the tasks on the board, plot that number and draw a line. This simple process gave us everything we needed in terms of tracking an iteration and was extremely easy to do saving us loads of time. Even when we decided there wasn't enough work for the iteration and added two new story cards along with their associated tasks simply adding up the remaining days for the task cards on the board gave us an up-to-date iteration burndown.

Forget about tracking the task cards and you'll find you've got a lot more time to concentrate on other things like writing new features.

What about distributed teams, I hear you cry? I still maintain that tracking the task cards electronically can be overkill. Pointing a web-cam at the board for remote workers would give them visibility. Talk to the remote developers during the stand-up each morning about tasks remaining and if you really need to, type the days remaining number into a tool that they can all see.