In my post Planning the Project – Part 1, I talked about the use of financial metrics to determine if we should execute a project or not. In my last post I empirically showed that slight variations in a group of dependent processes can have very dramatic effects on the outcome. So the question is, how do we use these two bits of knowledge to help us estimate? In simplest terms, we want to use some estimation techniques that take statistical variation into account and use NPV and IRR to gauge financial impact. We can use a number of techniques to estimate time and therefore cost. A few of the more popular ones are:
- Proxy based estimation. (PROBE)
- Parametric estimation.
- The Planning Game or Planning Poker.
- Putnam model based estimation. (SLIM)
- Evidence-based Scheduling. (EBS)
- Other various algorithm based models. (COCOMO, SEER-SEM, etc.)
Before we start using any of these techniques, it's good to have a couple of releases under your belt to gauge the velocity of your team. Depending on the Agile methodology, we may want to estimate features, Product Backlog Items, Scenarios, etc. We will want to start by having the teams make a guess at how long it will take to complete these items. I recommend breaking down any item that is estimated for more than 2 days into smaller chunks. Then you will also need to monitor the actual time needed to complete the item. Over a couple releases you should get a better understanding of how good certain individuals are at estimating and how quickly they can actually get things done. Given that information I like to build a "risk factor" or deviation for each developer that is providing estimates. Using this risk factor I can produce min/max estimates more accurately.
Now that you have some data in hand it's time to generate some estimates. I like to use a combination of Evidence-based Scheduling (EBS) and Proxy based estimation. Joel Spolsky has an EBS primer here. Proxy based estimation is simply the act of using similar pieces of completed code as the basis for current estimates, but here again we need data. Let's look at the widget example from Part 1 and look at the specifics. A 6 man-month project is a two month project for a team of three developers. Assuming we use Scrum, we are looking at three development sprints followed by a release sprint. The two week release sprint will be used to stabilize the software by eliminating all the bugs that are deemed unacceptable for release. Each Product Backlog Item (PBI) will be broken into one or more Sprint Backlog Items (SBIs) and used to generate the estimate. I'm just going to use the first PBI which will take the first week of the first Sprint for purposes of discussing estimation. All the other PBIs will be estimated the same way.
Figure 1 - PBI/SBI Estimation Example
Using the historical estimation data you can produce a deviation for each developer that will give you a pretty good range. You can see from the Figure 1 that we have a margin of error of 6.6 days, this is 5.5% of a 120 man-day project. I would be nice if we could reduce this, but let's review what we are trying to do. We are building an ESTIMATE, not an EXACTAMATE! What these numbers really tell you is the confidence you can have in completing the sprints and the release on-time.
I can hear people screaming now, "But Chad! You shouldn't do this in Agile!" Really? I disagree. Agile is not an open checkbook that allows development to just keep working on projects indefinitely, it is a mechanism to Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.1 We still need to create estimates that allow the business to plan on a software release by a certain date. Remember, we can choose to add or remove scope as necessary but we MUST meet our release dates. We estimate to gain a level of confidence that we can, in fact, meet those dates. As we move forward in the release and learn more we will continue to plan and execute as we monitor the project during the execution phase. This is the "Plan-Do-Check-Act" cycle prescribed by the PMBOK.
If you haven't already figured it out, I'm working my way through the Planning Process Group section of the PMBOK. (3.2.2 in the Third Edition) This article covers .3 through .8 and a bit of .9. I'm going to go into a bit more detail on Schedule Development in my next post.
- Principles behind the Agile Manifesto - http://agilemanifesto.org/principles.html