For the last year, I’ve been using SCRUM at Pocket Kings here in Dublin. Although I finish up at Pocket Kings on the 28th of this month, I fully intend to continue using SCRUM for my own projects at Ideal Binary.

Version One is the SCRUM tool I’ve been using at Pocket Kings so that’s what I’m familiar with. Once up and running it’s relatively straightforward to use. It is an enterprise level tool though and if all you need is to track your own work (and not that of a team or group of teams), it may be overkill setting it up and hosting it.

My requirements are pretty simple. Essentially, I want a way to store my task estimates and also track my progress from the beginning to the end of each sprint. I also want to be able to get visual feedback (a Burndown chart) so that I can see how accurate my estimates are, and to what degree discovered tasks are entering the sprint, if at all.

Tracking discovered tasks can help identify improvements that can be made with future estimates. Also, being able to show a client discovered tasks on a Burndown graph can help them understand what can cause a project to overrun a due date, or why they may need to consider removing a feature if they want the project to be completed on time.

My team lead at Pocket Kings showed me how to get started implementing a simple system that can provide this with none other than Google Docs.

What I’ve implemented here is somewhat different from what I was shown, but it provides me with everything I need. Below is a snapshot of the spreadsheet with data from a hypothetical sprint. One quick point about this hypothetical data – in general I try to produce task estimates that are around one to two hours in duration. If I find I’ve estimated a task at more that this, I like to break it up into smaller tasks. For demo purposes, I haven’t broken up the large tasks into smaller ones.

Anyway, to set the spreadsheet up, you enter a start date and an end date. Then you enter your tasks along with the task estimates. After this all you have to do is update the details of each task on a daily basis just like Version One. The formulas take care of the rest.

As you can see, below each task there are three rows. These are used to track changes in details relating to the task. These are:

• Estimated Remaining – This is the estimate for remaining work to get this task finished.
• Effort - The effort made to complete work that was planned for this task.
• Discovered Effort – The effort made to complete work that was not planned for this task.

Discovered Effort may be used to track required work that we simply didn’t anticipate or it may be used to track feature creep. This happens when we or the client decide to add functionality during a sprint that wasn’t planned. This isn’t necessarily a bad thing, so long as it is understood that there is a cost associated with it.

Data from the rows described above are gathered from each task and totals are presented at the top of the spreadsheet. It’s these totals that we use to produce the Burndown graph.

The Burndown graph for our hypothetical data is shown above. You can see we’re a few days from the end of the sprint. Our Estimated Remaining work is burning down and is inline with the Target Burndown. You can also see we’ve hit some discovered tasks on the 4th and 7th day of the sprint. Regardless, visible effort is being made and we’re burning down nicely. This sprint looks good.

The above system is relatively simple. I’ll most likely end up installing Version One when my tracking requirements become more complex. The reason I’m using Google Docs and not Microsoft Excel is that I work with both Apple and PC platforms and it’s nice to be able to access this stuff in an easy consistent way no matter what platform I’m using. Google Docs lacks some features present in Excel, but there are no show-stoppers here. Google Docs is also free.

I’m very impressed with what can be achieved with Google Docs.