Before I talk about schedule development, I want to touch on estimates a bit more since I've received some questions on this. For those of you that are new to Agile estimation, I strongly suggest reading Mike Cohn's book Agile Estimating and Planning. It covers many of techniques I discuss in this series.

The primary question I received was "How can you be sure your estimates are right?" The first thing we need is an Expert Opinion. According to Cohn, If you want to know how long something will take, ask an expert. In the PMBOK, this is called Expert Judgment. (6.4.2.1 in the Third Edition) While this is a good start, I've found that some experts (read developers) are talented estimators while others are horrible, most are somewhere in between. Due to this fact, we need a few tools to help assess our expert's ability to estimate.

The first tool we need some historical data, in lieu of historical data estimating becomes an educated guess. If you don't have historical data, start collecting it today. For reference, you will need to collect the initial estimate and the actual time taken to complete. Once you have some historical data you can produce the deviations I discussed in my previous article and the histograms shown below.

The second tool we can use is an estimate histogram. For features (vs. bugs) you can compile histograms for each expert on tasks they have estimated to be 1,2,4,8,12 and 16 hour efforts. Remember that any task over 16 hours should be broken down into smaller chunks. What you are looking for is each expert's ability to accurately estimate.

Figure 1 – 4 Hour Estimation Histogram

As we can see from Figure 1, Joe (our hypothetical expert) tends to overestimate the amount of time it takes to complete a 4 hour task. While 32 of Joe's tasks that he estimated to be 4 hours in duration actually took 4 hours, 72 of them only took 2.5 hours. In this case, we can leave the estimate as-is since the median of 2.5 is only 1.5 hours off of our expert's estimate. This is in-effect gives us a 1.5 hour buffer which, as you will see, is what we want. If we produce histograms for all other effort sizes we may find that Joe tends to underestimate larger efforts, this would look something like Figure 2.

Figure 2 - 16 Hour Estimation Histogram

Knowing that Joe has a tendency to underestimate larger tasks, it may be in our best interest to try to get Joe to break larger tasks down further. Alternatively, as Mike Cohn suggests, we can provide feature buffers to reduce the risk of poor estimates. Both these methods are valid and have a basis in the Theory of Constraints. We are assuming that Joe's issue with underestimating longer tasks is going to create a constraint during the iteration. My experience has shown me that this is typically true and the use of buffers can help protect the constraint. This is also referred to as Critical Chain Buffers on which there is ample work available online.

To calculate buffer times, you can use the simple "just add 25%" method which may work. In the case shown in Figure 2, adding 25% to a 16 hour estimate would only give us 20 hours, still under the 32 hours seen the most. However, there is only about a 40% chance that Joe will finish a 16 hour task in 32 hours. This is because 60% of the area of the 16 hour histogram occurs from 4-31 hours. A better approach to calculate a buffer is to use two standard deviations which, in this case is about 12 hours. This would give us a buffered task time of about 28 hours. Mike Cohn discusses this in more detail in Chapter 17 of Agile Estimating and Planning. Eliyahu M. Goldratt suggests in his book, Critical Chain, to simply use the median value for a given task, which in this case is about 30 hours, so we can use a buffer of 14 hours.

Whatever method you find works for you, create the buffer as a separate task that is dependent on the primary task. You will want to be able to continue to track estimates independently of the buffer. The goal of this process would be to center the curve over the estimated time.

Now on to Schedule Development...