Monday, October 08, 2007

Estimating Software Development

This blog entry was prompted by some thoughts I wanted to express about what it meant to make estimates for software projects in an agile way, and also by Steve Mcconnell's recent blog about Building a Fort.

The traditional way of estimating software development uses what I'd call a bottom-up approach. You discuss the requirements for the project in great detail with the customer, breaking the project into small pieces. You then estimate how long each of the pieces will take to develop, and then you add everything up to get the estimate for the entire project. In general, I don't think this is really a good idea for software projects. First of all, requirements really do change as time goes on, and an up-front estimate doesn't take that into account. Second of all, communication about requirements using words is a tricky business. I've witnessed, and engaged in, so many discussions where people seemed to agree when in fact they had very different visions. The converse is also often the case: It seems as if people completely disagree, and keep arguing about various points, when in fact they actually have a lot in common. They just don't realize it. So communication is really tough, especially when it comes to software projects where there is always so much room for interpretation. It's very likely that the breakdown of requirements won't be as accurate as it may seem at first. Finally, estimating the amount of time needed for a whole bunch of small requirements without having actually done any real work yet is dangerous too. Will something take two hours, two days, or two weeks? It's hard to say, but it's easy to give something a value and then to assume that it must be accurate. After all, the process to get that value was time consuming and very detailed!

In agile software development we try to be more realistic. I see it as as combining a top-down approach with a less detailed bottom-up strategy. The top-down way of estimating is simple. Try to compare apples with apples. If you (or your company) are asked to develop something, base the estimate on a similar project you've done fairly recently with comparable technology. That will give you a wonderful first-order estimate without breaking down the requirements at all. Next comes the agile version of bottom-up estimating. This involves breaking requirements down into a list that the customer prioritizes. For a smaller project, these chunks may be about a week's worth of work - the maximum size of most XP stories. For larger projects, they each might be about a month of work - the size of a Scrum sprint. The point is to provide an estimate that is based more on the sense of the scope and difficulty of each broad set of requirements without analyzing them to death. Once you've estimated each of the items on this prioritized list - it's called the Product Backlog in Scrum - you can compare the total estimate you arrive at with the earlier estimate using the top-down approach. Combining these two techniques should produce the kind of estimate that can be used to bid on or evaluate whether to go ahead with a project.

The important thing is that after each month-long iteration, or even earlier depending on the size of the project, you'll be able to compare the original estimate with the actual development time. After the first month, would the customer agree that you've completed what they expected to see? If you fall short, how much more time does it wind up taking for the the customers to say, 'yes, this is what we thought we would see for the first iteration'? That ratio is called the velocity. Say you took 25 days to complete what was estimated to take 20 days. That means your velocity is 20/25 = 0.8, or 80%. You can use the information to plan the next iteration, and so on as the project goes ahead.

There are a couple of nice things about this way of doing things. The first one is that you don't have to argue so much with the customer about what a requirement means. Say you estimated 20 days for feature X. After 20 days you present your software to the client. The client says, 'no, this isn't complete. You missed this and that'. I've seen my fair share of projects go completely off the rails when arguments like that break out, but with this agile approach, it doesn't matter so much. You discuss the missing pieces with the customer. Let's say, using our earlier numbers, that you take an additional 5 days to get everything done in a way the customer is happy with. That means, in a certain sense, that your velocity of 80% represents the difference between your original understanding of the requirements and the customer's expectations. Instead of creating arguments and finger-pointing, you can simply continue to monitor velocity and use it in your planning and budgeting. That's the other good thing - it's an adaptive approach. The customer is allowed to update the product backlog after each iteration - changing priorities, adding some new requirements or perhaps removing some that no longer make sense or just happened to emerge naturally as other features were being developed. The developers can then review and update their estimates and provide an ever more accurate planning picture. It's not very hard to track the velocity as a curve that makes the progress being made very clear to all parties involved.