Variability is intrinsic to software development.

Since there are so many elements that can change the trajectory of the effort, it’s difficult to deliver an accurate and precise estimation without a complete definition of what it entails.

Two Sides Entailed in Gaining Definition

 1. Defining a Requirement

2. Defining Solution to the Requirement

In building custom software, we are almost always trying to do something new which inevitably involves traversing unfamiliar terrain. Your product may involve scaling a new peak on the horizon and with no roads in place and no prior experience in this land, it’s difficult to anticipate every challenge you will encounter and how you will overcome it.

With this, it can be difficult to anticipate what the journey (or the solution) will look like. Establishing requirements help us draw on previous experience and predict potential challenges.

Think of a Rubik’s Cube. A 3-sided Rubik’s cube might take a pro 30 seconds or three minutes to solve. But they won’t know exactly how long it will take until they actually do it. On the other hand, a five-sided cube might take anywhere between 10 minutes and 10 hours. Building software is very similar to solving Rubik’s Cubes and we often use this analogy when we discuss software builds and agile planning with our clients. Requirements allow us to identify all or most of the tasks involved and also the general difficulty.

What’s a Good Estimate?

“Good” estimation is seen by experts in the industry as giving estimates that are within 25% of the actual result 75% of the time.

The bottom line is that there are so many factors that play into software estimation that even the most expert estimators rarely hit the mark. And when the mark is missed, 80% of the time it is an underestimation problem.

Reference: Software Estimation: Demystifying the Black Art, Steve McConnell

Main Factors in Estimation Accuracy:

• Incomplete Requirements: Small omitted requirement details lead to large differences in effort.
• Changing Requirements: Business needs are constantly changing in-flight, and teams need to adapt.
• Bias: hHumans are doing the estimating, predisposed to value-influencing judgments.

Working with Incomplete Requirements

During estimation, it’s not uncommon to have incomplete requirements. As consultants, it’s our job to dig as deep as possible, ask edge-case questions, understand the required interactions, and know where to fill in the gaps.

If you’ve never built custom software before, it’s easy to assume you are giving all the necessary requirements. But to a developer, those requirements might still leave too much room for interpretation. What’s in your head might not be the same as in what’s in the team’s head. We run into issues with accurate estimations when we still have questions about what needs to be delivered.

It’s important to understand all of the compounding factors outside of development that increase the load of the estimate. That is why we recommend making range estimates. Ranges give much more realistic and accurate predictions which provides an alternative to one number that is expected to be the final bottom line.

The benefit of having skilled teams that are accustomed to building software is that there are anticipated percentage ranges that we can anticipate. These are unearthed as key questions to determine effort beyond initial development.

Examples of Key Questions:

• How many iterations does the client want to budget for?
• How much project management is needed?
• How important is the user’s experience?

Changing Requirements are Common

If you give an estimate based on one set of requirements, even the smallest change in functionality can drastically change the amount of effort required to complete the project.

Imagine that you start by building a two-door car. As you build the frame, you find out that your family is going to grow. Now you need to build four doors with a roomy back seat. Imagine you are building a home, but you need to suddenly move the staircase to the other side of the house and move a bathroom downstairs. These types of changes can be analogous to software changes that significantly change the scope of the work.

Because the competitive landscape constantly changes, so does the need for your business to adapt. Ensuring that the client and the developer understand these realities is vital to a project’s success.

Scoping and Estimating

“Scoping” and “estimating” should be frequently used verbs among the teams. Being open to assessments along the way during a project will allow the teams to have the agility needed for a good partnership. This is where the project management approach and methodology matter. If it’s a fixed bid project often run in waterfall fashion, any changes are seen as “scope creep” to be managed. On the other hand, if it’s an agile project, changes are part of the process and they are simply added to the “backlog” to be considered and planned in following sprints.

Human Psychology Often Leads to Underestimation

As human beings, we’re predisposed to factors that lead us to wishful thinking, anchoring bias and cognitive dissonance. Each of these gets in the way of estimation accuracy, especially without all of the necessary information.

We use as many tools and methods as we can to counteract this. However, no perfect estimation tool exists. It’s also rare to find perfect situations without roadblocks throughout the project.

• Knowns: It is easy to estimate what you know.
• Known Unknowns: It is hard to estimate what you know you don’t know.
• Unknown Unknowns: It is VERY hard to estimate things that are entirely unexpected.

Wrap Up

Teams go through elements of discovery during the entire project. You might encounter an unforeseen obstacle that you have to adjust and account for, which then requires more support, more communication, new requirements, or a new team.

It’s difficult to anticipate every one of these needs at the beginning of the project because learning along the way is a part of the process. However, by following a good process for estimating, you can begin to create a realistic range of outcomes so that you have an idea of what to expect from your project.