How to Improve Software Estimation

Estimates…the word can strike fear in the heart of software developers. The information we work with is volatile, the technology we work with and integrate our code with is not just complex, but is prone to change itself. On top of that, when a developer gives an estimate, it often ends up being taken as a commitment by those asking for it, when in fact, an estimate is just a guess, and usually an ill-informed one at that.

Software estimation has been compared to an estimate for building a house. If we can specify it all up front, we should be able to make an “accurate estimate, right? At least given that nobody changes their mind. But we all know that to be true, because of two things: people always change their mind, and the things we are working with are either more complex or more difficult to work with than we could imagine. It’s human nature to be optimistic around estimation, and this is a well-documented fact.

So how do we get better? How about we eliminate the pain, and start with simply not estimating anymore? There is a trending topic in the software development community around “No Estimates,” which doesn’t quite mean what it sounds like it means. While the name would imply that it shuns estimates because we all hate doing estimates them, it’s really about making decisions using alternative means and without using data from estimation. A fine line, yes, but the core of this thinking is that estimates are waste, and we can achieve better decision making without this waste.

I believe that it is possible for a team to get to a place where estimates are not required to make decisions, but it takes a specific scenario for this to be possible – involving a team that has been working together for a reasonable period of time, a committed and involved Product Owner, and work broken down into very small, similar-sized chunks. Unfortunately, this isn’t the world that we frequently live in at AgileThought. We often deal with new and undefined products that need to be built, have multiple sources of input about product vision, using teams that are yet even been to be organized, and with technologies that have never integrated together before. Yet, our customers demand that they know project cost before we write a single line of code. How can this be a reasonable demand? I’ll make the argument that it is a fair demand, but there is an expectation back to our customers that what we estimate is wrong (at least it is not highly precise) and there needs to be a collaborative process in place to make their investment successful and valuable.

Our customers who come to us for greenfield product development work need to understand cost. This need for cost estimation comes from the fact that these projects often lack funding, and the only way to obtain funding is to understand cost. The only way to understand cost is to do an estimate. This isn’t always the case, but we find this scenario true most of the time for greenfield development projects. So how do you come up with a cost estimate for a greenfield development project? In our experience, there are some very specific things that can be done to improve the estimation process.

Use multi-point estimation

Do not estimate at a single point value – always estimate with at least a range, and ideally a three point estimate. Two different models for three-point estimation are low/probable/high and low/high/confidence. We use a model of low/high/confidence, where we state what we believe to be our best case estimate (low), our worst case (high), and a value of how confident we are in that estimate. Multi-point estimation helps you think through what the best and worst case scenarios are, and the third point can help you calculate a likely level of effort based on some statistical probability.

Use collaborative estimation

Never estimate alone. Use collaborative estimation, like estimation methods such as Wideband Delphi and Planning Poker use. This is where the important discussions happen, and you can leverage multiple points of view.

Document your assumptions

We are fond of saying “assumptions are our friends” – they help us document why we made a specific estimate in the first place. If you base an estimate on what you believe to be a fact – and that fact becomes untrue – then your estimate is now invalidated, sometimes to a large degree. But these facts need to not just exist in your head – they must be documented and delivered with an estimate. For example, if you are estimating how long it would take to integrate with a web service, you should document the assumption that the web service is already defined, will not change, will be available for development and testing cycles, and will provide a clean set of test data. While these assumptions seem like common sense, it’s better to document them than not.

Use timeboxing for standard activities

For common project activities that can be timeboxed, used timeboxing. For example, we often timebox knowledge transfer to our clients development teams. Use timeboxing where it’s not possible to estimate, and hold yourself accountable to those timeboxes during delivery.

Incorporate organizational friction costs

You must understand what degree of effort will be needed to collaboratively work with a customer. Some customers are friction-less, others have a high degree of friction, with respect to the amount of effort to do anything, from obtaining consensus on acceptance criteria to completing a production deployment. These costs need to be incorporated into an estimation model so that you aren’t surprised during project delivery.

Use reference class estimation

Look at other projects your teams have done in the past as references for future estimates. Past projects can inform project estimates and give you an idea if you are in the ballpark or not. After all, if you don’t take into account the lessons you learned in the past, you’ll be doomed to repeat your mistakes.

Even with all of these estimation practices and principles, we and our customers must realize that software estimation is not just difficult, but essentially impossible to do with high precision, especially for projects of decent size (greater than a few weeks). It’s our duty as software professionals to deliver an informed, honest estimate that a team has a reasonable shot at achieving.

Interested in Improving Your Estimation Process?

AgileThought can help your company not just improve your estimation techniques, but can help your company adopt agile development principles, practices and frameworks that will greatly enhance the predictability, quality, and speed of delivery. Contact us through the form below to schedule a discussion on how your organization can be transformed with agile.