Software estimation is not an easy task, and most managers have trouble estimating even the "simple" projects. Several authors have attempted to devise their own systems to generate the perfect estimate, but they all fall short in practice in one way or another. I'd like to lay out my approach to improving software estimation accuracy, which is not only forward-thinking but also takes into account the past. Hopefully, this approach will make at least one manager successful in their project management estimates. In the process, I'm going to completely destroy some conventional wisdom.
The goal is simple, to arrive at an estimate that is both reflective of the time and effort involved. To achieve that, we need to adhere to the following principals:
- Break the project into its smallest pieces.
- Developers must be looking at code before they estimate.
- Look to the past.
- Add buffers for risk
Finding All The Pieces
Before doing any of the estimation work itself, we need to first identify all of the tasks that must be completed. Usually, this will be a somewhat high-level list. From here, we keep breaking it down until we have all of the tasks and the components involved. I'll explain the importance of components later. These are things the developer(s) will touch during the project. The "project" may indeed be a complete project, but far more often, it will be a new feature or modification.
The developers themselves will need to be the ones who ultimately break up their work into tasks and components. As a manager, unless you're hands-on and completing the work yourself, you're not going to know all the ins and outs even if you've been on the project for a while. This leads me to the second important principle.
Looking at the Code
If you get an estimate in 15 minutes from a developer, you know they haven't looked at any code to figure out the effort involved. An estimate without the code research to back it up is called a guess. A guess is useless in an estimate.
The developer(s) should be looking to obtain 2 things from the code. First, they need to be able to see all of the pieces involved and get an idea for how long it will take. This is obvious, but looking at code reminds the developer of things they may have forgotten that were in there. It also helps them get prepared and focused on the solution early.
The other important result of code research is figuring out how complex the rest of the system is and how it will affect the timeline. Often, we find ourselves in a situation where we need to use or even modify someone else's code. That could be a former employee, an outside vendor, or an open source software component. We don't always know ahead of time what we're up against. In fact, this new feature may require something new that we haven't installed yet. This also leads into risk, which I'll discuss later.
You can expect a developer to take a day or two to return with a good estimate from this research. Those days will be worth it in time and frustration avoided later.
Looking to the Past
If you get nothing else from this article, this is the one point you should take away. In almost all of the software estimation books and articles I've read, none of them even mention past efforts at all. It's not an exact science, but the basic premise is this: Average up all of the previous times your team has done each task and compare that to the current estimate. Then, for each difference, take the one with the longer timeframe.
For example, let's say Joe needs to add a screen with a list view to a mobile app. It doesn't matter what data he displays on that screen. What matters is that he's adding a list view and pulling from some data source. For the list view (pulling data from the data source is a separate task), it took Joe 3 days on average. Keep in mind that it doesn't matter what a list view is (this technique works well for technical and non-technical managers as well) or what it's supposed to look like. Now, we look at the estimate Joe just gave us for this new list view, and it's only 1 day (yes, this disparity is quite common). Simply take 3 days as the final estimate. Over time, and with more experienced developers, the disparity will be less.
If the new estimate is longer than the time it took previously, you still want to use the new estimate, but you can always include the old estimate in a "best case scenario" estimate later if you feel the need (or the pressure from above). Generally, Joe probably has a reason he's estimating longer, so it's best to stick with that and avoid surprises.
Now, we get into the importance of the components we listed out earlier. The other thing to look for is how long previous tasks that touched that component took. This helps to guard against situations where it shouldn't take more time, but due to how complex the component is, it does. This view is best applied when you've done a similar task on the same component. For example, "last time we added a new method to the Widget API, it took 4 days instead of 2".
The trick with the past isn't finding the exact same tasks. Otherwise, they'd be done already. It's finding similar tasks with close to the same level of effort as our new tasks.
What if you're just starting out on a new project at a new company? Well, you won't have the past data to work with, but you can apply the same technique to previous projects the developer(s) have worked on for different companies. Your first estimates will be less accurate, but they should hone in quickly as you progress.
The final piece to this is keeping track of the actual time spent on the new projects and their associated tasks. Yes, this means more record keeping, but it is both enlightening and well worth the effort. The key here is to keep track of the actual calendar time, not the estimated number of hours it took (because that's only a guess also). This keeps the units used in the estimates consistent for both the past and the future.
The other important aspect to looking at the past is to not specifically account for the routine breaks such as vacations, sick time, etc. If you keep track of calendar time, you automatically get vacation time and the like accounted for as a bonus. That's why you want to use an average for the past tasks also.
As with any type of project (software, construction, etc.), there is always a certain amount of risk. That risk is usually the unexpected complexities. It can also manifest itself in the form of unplanned vacations, etc. Obviously, if you know someone is taking a vacation during the project, you should go ahead and add that to the estimate if it means no one will be working on some tasks during that time.
If you're just starting out, you might want to add a 20% buffer, but feel free to use what you feel is best based upon factors such as shifting priorities and other common events. You might also decide to use less of a buffer, and probably will as you gain experience with the team and the technology. Improving your risk estimation will also help your overall software estimation accuracy improve over time.
We've all heard it said that when a developer (or engineer) gives you an estimate, you should double or triple it. Well, while engineers aren't known to be the best estimators, these techniques allow you to just throw that nugget of "wisdom" out the window. Looking to the past will do that for you, and only when it's really needed. Multiplying an estimate is just a misguided "solution" for times when you don't know if the estimate is realistic or not.
Armed with the principals given here, you will know what's realistic and what's not. After a few cycles, you'll even get a gut feel for what to expect. It's not rocket science. It just looks like it to those who don't have the knowledge or experience.
The Result: Improved Software Estimation Accuracy
After going through the previous exercise, you should end up with an estimate that is both accurate and useful in terms of monitoring milestones during the life of the project. One thing to bear in mind is that you may receive push back from the higher-ups as you present them with the timeline. Of course, the shorter the estimate, the more likely it will be accepted.
Here's a lesson I learned the hard way early in my career. Don't fall into the common trap of shortening the estimate in order to please your boss(es). After all, you will have an estimate that is backed up by solid evidence. It is much better to have your manager get upset for a day at the beginning than upset for several months because you over committed and couldn't deliver.
These techniques work on projects using several development methodologies, whether they be the more traditional waterfall approach or the Agile methodology. Generally, the shorter the project, the easier it will be to generate an accurate estimate. There's nothing wrong with breaking up a huge project into smaller phases and estimating those separately.
With practice, you will hone your estimating skills, and these principals should make improving your software estimation accuracy feel like less of a black art.