When forecasting a project, it's fairly easy to predict with good accuracy what the total duration of the project will be. This is helpful information, but we always want to know more -- we want to know how long each task will take so we can schedule it and test whether we are on track.

Let's come back to the problem at hand, we need to schedule work and then monitor progress. So suppose I have an Agile team of two devs (a very small self-forming team), on it is that junior developer and the other is the senior lead. In Agile, we work in sprints, often 2 or 4 week intervals. This is so that we can incrementally deliver results to make the customers happy (they keep getting presents every two weeks) and so we can make corrections as the project unfolds. We'll make this project work in two week sprints.

The first question is when will the work be done? That answer is easy - two weeks. The more difficult question is what work will be done in two weeks? If we took the traditional approach, we would say we have 80 hours for each developer, so a told of 160 hours for the week. I could then go about assigning and estimating each task. But then I start thinking about how much time I need for testing, coffee breaks, meetings... and what if I run into some unexpected trouble on the task, I'd better throw in some room for that. In the end, we wind up with a pretty bloated plan that's built with a lot of detailed assumptions. And what do we know of detailed forecasts? They are more wrong then high level ones. So let's get out of the weeds.

Now let's take an Agile approach, let's throw the concept of hours out the window and come up with a random, meaningless unit of measure - gummi bears, jelly beans, m&m's. It should be candy because that always makes people smile and makes the process a bit more amusing. I then ask the question, how many gummi bears is this task worth? The gummi bear represents the level of difficulty - it does not matter who is doing the work, the junior dev might take more time for the task, but we are not measuring time, we are measuring estimated difficulty. We do this for all the tasks, and when we start the sprint, anyone can take on any task because we have not assigned anything. Suppose we end up with an estimate of 20 gummi bears for all the work, this might work out to be a 20 / 80 split between my team members, but it effectively represents all the work that can get done in two weeks by this team.

It's really an amazing thing, if you estimate by consensus, the team will have a very accurate estimation of work by the 3rd sprint. We might find out that we can accomplish 25 gummi bears per sprint, this lets us know exactly how many tasks and which ones can fit into a sprint. It takes out all of the overhead and nonsense of tracking actual hours per task. But how do we measure progress with gummi bears?

The burn down progress is calculated using the slope (y=mx+b), i.e. for day 0 = -2 * 0 + 20, Day 1 = -2 * 1 + 20 and so on. As we progress, we mark tasks done and subtract that from the total gummi bears that need to be done. In this chart, we were a little hung up in the middle and rose above the burndown line. Our goal is match the burn down line, above or below just shows some inaccurate estimations.

I have used this effectively on several projects and I am amazed at the accuracy and how much it frees up your time to do actual work and not project management. I invite you to give a try.

Mark Wojciechowicz

Labels: Agile