Software Estimation: How to Get It Right the First Time

Georges Lteif

Software Engineer

Last Updated on May 19, 2022.
Subscribe now to stay posted!
About Us
12 min read

1. Overview

Many IT professionals believe that estimating software with arbitrary precision is near impossible. And that’s, in fact, very true.

Difficult as it is, estimating software development tasks is a necessary evil, and you need to get it right, at least within a small, consistent margin of error.

In effect, unreliable estimation is cited as one of the top 10 reasons IT projects fail.

Luckily, a combination of superior processes and good estimation techniques can help you achieve enough precision to make task estimation outcomes valuable and reliable. 

In this article, we will have an in-depth look at:

1. Why it is essential to get the estimations right
2. Challenges of software estimation
3. Powerful software estimation techniques
4. A working formula for how to implement those techniques to achieve the best results

---

2. Table of Contents

---

3. What Is Software Estimation

Software estimation is the process of finding out how much effort, usually in time and material, would a project cost.

The time is typically estimated in person-days, while material refers to the number of resources involved.

A prerequisite for starting the software estimation exercise is the sign-off of the business requirements. The outcome of the estimation process is a detailed project plan.

This activity usually happens in the Analysis phase of the Software Development Lifecycle (SDLC).

There are three main methods for estimating effort:

1. Expert Judgment
2. Statistical Analysis such as those applied in Six Sigma
3. Bottom-up approach

We will discuss each in detail in the following sections.

---

4. Why Is Estimating Software Important

Here are some advantages to getting those estimations right.

4.1 Impact on Budget and Schedule

Project managers estimate software effort to determine the cost and schedule.

These directly impact the customer’s expectations in terms of budgeting and planning. All clients will expect to finish the project on time and within budget, and the software has to perform as promised.

4.2 Improving Team Morale

Team morale is crucial for performance and the long-term mental well-being of team members. Unreasonable deadlines induce stress which lowers team morale, especially if it’s endemic and not entirely out of control.

Involving the team in the effort estimation process will create a highly desirable outcome: Everybody has a say in determining the required effort of the tasks they will perform and can be held accountable just and fair.

Getting software estimations right is not just good for your customer; it’s also great for the business.

4.3 Managing the Client’s Expectation

It is undeniable that IT projects are complex enterprises, making them difficult to complete on time and within budget.

Despite that fact, customers will not hand you a blank cheque, and they will still expect the vendor to do their utmost to meet the deadlines.

If your customers are large organizations, it is not unreasonable to assume that they also might be juggling several projects simultaneously, hence the importance of sticking to agreed-upon plans.

Customers will also be operating under a fixed budget, and this becomes all the more important if the project requires the allocation of resources or hiring external consultants. Any delays will directly impact running costs, something they will try to avoid.

4.4 Smooth Delivery

Opportunities for process improvement can be found in any stage of the SDLC. The Analysis stage, and particularly the effort estimation part, is no different.

Estimations have downstream impacts on the quality of the deliveries, as we shall attempt to show shortly.

Let’s consider the familiar scenario of projects running out of time. Here are some of the usual sacrifices that are made:

1. Quality: usually of the code, feature, or product. A sacrifice in code quality will increase technical debt. If this practice is consistent, it will have long-term consequences. Cutting Software Testing activities is another example of quality sacrifice, and this particular one means immediately translates into more testing cycles, customer frustration, and delayed production dates.

1. Scope: this leads to delivering software that falls short of customer expectations. In extreme cases, the software can be unusable.

1. Delays: This means slower time to market, potential profit loss, losing to competition, and an unhappy customer who is reluctant to do business with you in the future.

---

5. Why Is Software Estimation Hard

5.1 Overview

Two main reasons make software estimation difficult: novelty and project unknowns.

The first reason has to do with the amount of uncertainty that’s usually involved in complex IT systems, and these typically fall into two groups: known unknowns, and unknown unknowns.

Both are risky except that you can prepare for the first type. For the second type, there is little that can be done except add a contingency to your project and learn from previous mistakes.

The significant contributor here has always been unclear or changing requirements.

Agile and DevOps have some built-in mechanisms to deal with this type of problem, the details of which are too minute to include in the scope of this article.

The second reason for failing estimations is that no two projects are the same. Every project has the potential to present a novel aspect, and the source of this novelty can be 

• Innovative features that are the result of changing customer preferences
• Emerging or new technology that might sometimes be immature or where documentation is difficult to come by
• Inconsistent delivery processes

5.2 Precision and Uncertainty

In most cases, you will never really find out how much effort a task needs until it’s almost done.

Naturally, you can always provide a bracket wide enough to be accurate. For example, 1-10 years is a very accurate estimation for building a web application, but alas, it is not very useful.

What you need is precision. Therefore, a more precise and helpful answer to the question above would be 8-12 months.

The cone of uncertainty is typically used to illustrate how the variance changes as the project advances. Have a look at the graph below.

At project inception, the estimation variance is highest except that, at this stage, you need the best precision you can hope for.

It drops down to zero in the later stages, which is excellent except that, at this stage, this knowledge is much less helpful.

5.3 Estimation Challenges

We have identified six top reasons that we believe are behind software estimation difficulties.

5.3.1 Unclear Requirements

It is inevitable that if you start with unclear requirements, you will most certainly underestimate the amount of work involved.

Sometimes, you might encounter a situation where the requirements can never be fully known at project initiation. This lack of clarity is especially true when the customer cannot articulate (and perhaps document) their business requirements for one reason or another.

This lack of clarity can be OK if everybody acknowledges it and understand its consequences. In similar cases, Agile practices would need to be used as they provide ways for dealing with uncertainty.

However, it remains true that if the requirements can be documented early on in the project, before any design or development starts, it must be done.

5.3.2 Scope Creep

Whenever new features are added to the scope without revisiting the effort estimations or the schedule, you have what is known as Scope Creep.

Unfortunately, scope creep is more common and readily accepted when the requirements are not documented and signed off with enough clarity.

It is typically the project manager’s responsibility to keep an eye on the scope and prevent any additional activities from taking place if they impact the deadlines.

With proper processes in place, change management helps avoid scope creep.

5.3.3 Novel Features

Having repeated the same task several times, you sort of asymptotically arrive at a level where you are comfortable enough with its estimates.

But because software products have become very complex, and no two projects are the same, there will always be a degree of novelty in every new one. And with originality comes risk and uncertainty.

Unfortunately, these risks cannot be easily mitigated because they are Unknown Unknowns.

Unless this is an R&D project or you are attempting to satisfy a specific customer requirement, it would be safest to stick with known technologies, methods, and designs.

5.3.4 Legacy Code

Legacy code presents challenges on many levels, and estimating changes can be among those challenges.

On a positive note, legacy code is usually old enough to ensure a degree of familiarity, especially when changes are small and isolated. Significant modifications, however, can be daunting to estimate.

5.3.5 External Dependencies

Dependencies usually come in two flavours: external from partners and suppliers or internal from teams within the organization.

Dependencies can be classified as known unknowns; this makes them easy to account for, although they always present a varying degree of risk.

5.3.6 Resource Efficiency

Resource efficiency can vary with seniority and capabilities. This should be factored in during the planning phase. Staff can also:

1. Take days-off
2. Get pulled into other projects in emergencies
3. Be distracted by admin work

Poor production processes will also impact delivery dates allowing them to fall behind original estimations. Poor performance, if known beforehand, would need to be factored in project estimates.

5.3.6 Poor Planning and Design

It’s no secret that if you don’t thoroughly analyse the business requirements and produce a good design, you will fall short on the estimations.

Lack Of Clarity And Execution Strategy is cited as one of the top reasons for IT project failures in general.

During the design phase, you try and uncover as many issues as you can so that you don’t have to make any costly decisions later on.

Naturally, the design phase itself needs to be estimated as well.

---

6. Software Estimation Techniques

Several techniques are commonly used in the industry for estimating software. These techniques fall broadly under three categories:

1. Top-to-Bottom approach: which relies on expert judgement for estimating individual pieces of work. This method is probably the most unreliable as it doesn’t involve the technical staff executing the tasks and may not consider the specific capabilities of each of them.

1. Bottom-Up approach: this is the most reliable and accurate of the lot. It does, however, require more effort since technical staff will be needed to estimate their tasks.

1. Statistical Methods: which look at historical data and try to come up with the best estimate of what the next project will look like. This method is somehow cumbersome and prone to error; historical data tends to be sparse or biased.

The below figure shows the reliability of the different methods.

---

7. Estimating Software Effort in Waterfall

The Waterfall software estimation technique lists all the significant tasks in a project and breaks them into smaller pieces for easier management. Then, an estimate is provided for each task in person-days.

Project managers create a schedule once the estimation exercise is complete and a critical path is determined.

The critical path method (CPM) is a project modelling technique developed in the late 1950s where a critical path is defined as the shortest possible time the project needs from start to finish. 

The critical path is delicate, and any delay in tasks on the critical path will eventually delay the whole project.

Project managers usually put significant effort into getting the estimates right to mitigate such risks.

This emphasis on correct estimation helps assimilate potential delays and make the critical path more resilient.

---

8. Software Estimation Techniques in Agile

Estimating software effort in Agile works in a somehow different way.

Like Waterfall, Agile also breaks big chunks of work into Epics, User Stories, and tasks, but instead of estimating effort in person-days, Agile uses Story Points.

One of the fundamental concepts of Agile is acknowledging uncertainty and changing requirements, even late in the project. This concept makes effort estimation in a precise number of days inherently tricky. Of course, the other challenges we listed earlier remain highly relevant.

Story points allow you to avoid two mistakes: A) undue confidence in estimates and B) the ability to keep the critical path intact throughout the project.

In both top-to-bottom or bottom-up techniques, you must assume that the developer’s estimations are reasonably close to the actual thing before you can do any planning.

Critical path projects leave very little place for surprises, and their deadlines are generally fixed.

So how do story points solve these two issues? We will talk about this in great detail in the step-by-step guide.

---

9. Step-by-Step Guide to Better Software Estimation

We propose the following software estimation technique. Its main advantage is precision, while its weakness is that it applies only to Hybrid software delivery models.

This limitation, however, is not overwhelming from a practical perspective, and this is due to the popularity of the Hybrid model vis-a-vis Agile or Waterfall on the one hand and the fact that software estimation is not as critical with pure DevOps or Agile.

9.1 Step 1: Break Down Major Tasks

The first step requires your team to use Epics and User Stories which are usually part of Agile or Hybrid project management methodologies.

If you are still using Classic Waterfall, perhaps it is time to consider moving to Agile or the Hybrid Model. If that is not possible, you can still break down major tasks into more manageable ones and continue with the next steps.

At this stage, we do not look at breaking up User Stories into tasks as that will come later.

9.2 Step 2: Generate a Rough Order of Magnitude

A Rough Order of Magnitude (ROOM) is a number or category assigned to each User Story whose objective is to indicate a rough estimate of the effort required.

People like use t-shirt sized scales when defining the ROOM due to its convenience. The advantage of using Rough Orders of Magnitude at this stage is multifold:

1. First, we don’t yet have a detailed design which means that a precise estimate cannot be made.

1. Second, because of the generous margin of error available in ROOMs, it is possible to use expert judgment to make the estimation. At this stage of the project, resources might not have been fully allocated, and a solution architect profile can typically be available, and that’s probably all that is needed for the moment.

The Rough Order Of Magnitude can be used afterwards by the project sponsors to decide on the project’s scope depending on how much budget is available.

9.3 Step 3: Create a Solution Design

Now that the scope is ready, you can create a detailed solution design.

A detailed low-level solution design document (LLD) will provide you with enough details on all the source code changes in scope.

In addition to that, a bi-directional traceability matrix in your LLD will help you estimate how much testing you need to cover.

Now that you have the solution design ready go back to the user stories and break them up into further subtasks if required.

Each modification in the solution design must be reflected in a Task belonging to a specific User Story. The task should be small enough to ensure the estimation is precise.

A task is small enough to require no further division when one developer can complete it.

9.4 Step 4: Assign Story Points

Now that we have tasks and subtasks defined, you are ready to assign story points to each user story or subtask.

But before we can do that, there is one prerequisite: defining a scale for our story points.

The reason you want to do that is straightforward: to avoid having to arbitrarily assign numbers, which may or may not mean much. A task that a senior developer can do in a couple of days may require twice as much as a new one.

It is better to create a sequence of 7 or 8 categories, each increasing in value in a non-linear way. You can use the Fibonacci (1, 2, 3, 5, 7, …) sequence or a power sequence (1, 2, 4, 8, …).

Story Point	Level	Category Description
1	Minor	Configuration change or document update.
2	Very Easy	Minor code updates such as cosmetic changes.
3	Easy	Extending an existing feature, perhaps adding a new parameter.
5	Average	Can be the addition of a web page or user report.
8	Difficult	Example: touching core components of the system.
13	Very Change	Refactoring large code units.
21	Major Update	Extending core components, supporting additional platforms…

The table above is one way of defining the categories.

9.5 Step 5: Calculate the Effort in Man-Days

This is where the magic happens.

You can start with a default one-to-one mapping between story points and person-days based on the table above. 

At this point, the story point to person-day mapping is only a rough estimate, and it is just a starting point that you will use to create your schedule. It should be made clear to stakeholders that the plan is subject to change depending on the actual value of story points in person-days; the latter is an entity that will be refined as the project progresses.

Here’s what you should do to determine an accurate story point to person-day ratio. For a period of 2 to 3 weeks (could be Agile sprints, depending on methodology is used), observe the total number of story points closed. Then, divide the total by the days, and now you have your ratio!

Proceed to update the schedule. Use this procedure every few weeks so that your ratio remains current.

---

10. Final Words

Getting the estimations right is a vital ingredient for proper planning and expectations management; it sends the client a message of confidence, optimism, and professionalism.

These signals make collaboration easier and project management smoother. Most importantly, it allows everybody to plan and prepare adequately, leading to better deliveries and efficient performance.

The proposed guide described earlier is not airtight and may not work in every situation. It is, however, a great start and a significant departure from the old ways, which is why, in our view, it warrants a genuine discussion.

As with any production process, good governance (monitoring, updating, and validation) is also essential to remain ahead of the curve with one minor difference.

In effect, effort estimation exercises are, by definition, repetitive and their outcomes is a quantitative measure (person-days). These two properties make them ideal candidates for applying Six Sigma concepts.

---