Creating accurate software estimates
One of the largest challenges, if not the largest challenge we face in our business almost every day is the answer to the question, “How much work do you think it will take to build it?”.
Part of this problem is the high cost of solving unknown problems. Software is unique from virtually all other trades in the world. When a specific problem is solved, the cost of solving the same problem again approaches zero. This allows for incredible progress on solved problems, and in relative terms, frustratingly slow progress on new problems. Sometimes, even the solved problems, when approached slightly differently, turn into new problems that need to be solved.
Another issue that compounds the difficultly of estimation is the large number of unknowns in any software project. Even the most fully formed spec cannot uncover the complications that are discovered only once construction of a software project begins. So not only do you not know the difficulty of solving known problems, you can easily expect a certain number of unknown problems to be discovered during the course of development.
So how do we create an estimate that encompasses both the solutions to problems we know of and solutions to problems that we have not yet discovered?
The very first thing we do when we begin a new relationship with a client is try to set some expectations for our work. It’s important to make sure we get off on the right foot, so we communicate the following right away:
- We will always be honest with you.
- There is much we still don’t know about your software project.
- Development is as much about discovery as it is about implementation.
We consider this to be one of the most important parts of our relationship with our clients. Setting expectations early and often is a key ingredient of good software.
Discover the unknown
When we’re ready to create an estimate, the next step is to break down the requirements into small pieces. Within each piece, we can identify the features that we know contain unknowns and use experience to take a guess at where other potential unknowns may be hiding.
For example, if our customer wanted to create a blog system similar to the one powering this site, we may break it down into the parts we can identify: Posts, Tags, Authors, etc. Posts have a title, a date when posted and so on. Experience tells us that creating a Post can be done easily, but Tags can be much more difficult depending on the requirements.
As a part of the estimate, implementation questions will arise. This is to be expected. Our job at this stage is simply to identify what we know we don’t know.
Build on what we know
At the core of every estimate is the effort we know will be required. From the work we’ve done in the stage above, we can identify the things we know how to do. These are the things we understand well and use as the absolute bottom for our estimate.
By using the knowns as the baseline for our estimate, we can also identify where an estimate hasn’t been correctly specified. If there’s a feature where we can identify no part as known, then we need to go back to our customer to get a little more detail, until we can find a way to understand it better. We aren’t looking to understand everything, but we need to understand the types of problems we need to solve to have any hope of an accurate estimate.
Continuing our above example, we know it’s simple to add an arbitrary number of attributes to a Post: Creation date, Published date, Content body, etc. These make it easy for us to establish a minimum for effort required, so we can be sure we’re never committing less time than is possible.
With the base numbers above, we can start to add a guess for the effort required on the unknowns. We like to use a best case and worst case scenario to define the limits on the estimate. We’ve been in this business long enough to know that even problems that look difficult can have a simple solution. (And yes, sometimes the problems that appear simple can be incredibly difficult.)
The knowns from above define the absolute baseline for the work required. We know that no matter what we estimate for the unknowns here, we can never go below the time we know a feature will take.
Our initial estimates tend to have a very wide range between the best-case and worst-case scenarios. We want to make sure that at the top end that we’ll be able solve all problems we’ve identified in addition to the ones we haven’t found. At the same time we want to be optimistic that we could find simple ways to solve some of the problems. It’s not unusual for the spread between best and worse case estimates for any large feature to be several weeks in length (depending on the size of the project).
After all of the work above, we have a pretty good idea of the ranges for what it will take to solve the particular problem we’re presented with. While there are things we won’t understand, we usually do a pretty good job of figuring out the parts of the project that need clarification and can base on top of that.
However, most times even this isn’t enough. When a customer asks “How much will it take to build it?”, generally the idea they present to us isn’t fully formed, even if it appears to be so. We can provide an estimate for the requirements we’re given, but we know that once the customer gets to actually use the software, their needs generally have a habit of changing.
Changes are beyond the scope of the estimate we provide, but in reality, the true purpose of an estimate is to set expectations between two parties. By clearly communicating our estimate process and working closely with our customers to identify the unknown parts of software project, together we can discover the solution that “just works” to solve their problem.
For further reading on this, here’s a list of articles we recommend: