2015-04-17
Estimating
Estimating anything can be quite difficult work and project labor is no exception. At a company I worked at years ago, teams of people would work tirelessly at each year end to predict sales for the following year. The purchasing team would use a tool to generate a forecast at the product and customer channel level. The sales team would forecast by customer and the president would forecast the overall total sales number for the company. Who was the most right in the end? The one who forecasted at the highest level, the president. This is because all the low level noise washes out, if one product sold better than expected and another sold worse, it would even out in the end.
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.
Traditional Project Estimation
The traditional approach is to predict the amount of hours for each task. But to do that, you need to know who is doing the task - is this a junior developer or a senior level expert. A task that might take an expert a couple of hours, could take that junior developer several days. Project managers like to track these hours by having the team enter their estimated and actual time. Really, these numbers probably best represent how bad are estimating skills are. I have given this approach a try a number of times. It's truly a headache to constantly update a gantt chart and shift the timeline as the project evolves.
Agile Project Estimation
In Agile, this is sometimes done differently. I say sometimes because I have talked about the gummi bear approach to several people who have worked on Agile projects and they give me a look like they are waiting for the punchline. But this is serious stuff, this gummi bear and jelly bean thing, so I'd like to explain how it all works.
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
Measuring progress is done with a burn down chart. Here is an example using 20 gummis per sprint:
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
