Business

Why software development estimations don’t always work – and what we can do about it

Adrian Kasprzak, Mar 02, 2019

5 min read

Software development companies use traditional time estimations to produce initial quotes for clients. That's a common practice which isn't likely to change anytime soon. But technology providers and their clients need to understand that such estimations are often inaccurate.

Software development estimation is a process that carries many flaws.

In this article, I take a closer look at the traditional software development estimation practice to show you why such estimations often don't work as expected and what companies can do about it to deliver more accurate estimates of the work required to complete the project.

Software development estimations – the basics

A traditional estimation is a practice of determining the amount of time (usually measured in hours) it takes for a single software engineer to complete a specific task. If the team follows the Scrum methodology, a task can refer to a single task, a story or an epic.

To estimate development time, tasks may be broken into smaller subtasks that need to be estimated as well. In that case, the process is applied to every subtask and then accumulated together to get the overall task estimate. The bigger the relative size of the task, the higher the risk that the estimate is inaccurate.

Since we're talking an estimation, it naturally takes place before development begins. Note that software development estimations might also include progress tracking and target date commitments that are based on these initial estimations.

Why do we estimate software development?

The most important reason for estimating the time it takes to develop software is that sometimes new features or software releases need to be introduced at a fixed date. For example, the development team might be working on a customer deliverable date deadline or an upcoming industry event. Some teams may be working to complete the task before a time-sensitive marketing opportunity arrives.

All of the above are legitimate reasons for estimating software. Another reason is that estimates make clients happy. Senior managers and executives are used to receiving estimates. They want to see metrics, status updates, and reporting. It gives them transparency and insight into the initiatives, deliverables, and actions taken by every single department geared at bringing the company closer to its business goals.

The metrics and reports that are part of software development estimations are designed in a way to indicate the effectiveness, progress, and impact of the project. These metrics need to show that investing in software makes sense.

Product development professionals are also expected to provide status updates and metrics about key deliverables. And deliverables are ultimately pieces of software, and that's why it's smart to estimate their creation.

Budget estimates help people to understand when specific deliverables will be available, and the project will be ready to enter into the next stage. That type of informational value matters more to some professionals and businesses than others but is prominent enough to make software development estimations a standard practice in the tech industry.

But estimations come with one significant disadvantage

Especially, if we're trying to estimate the time required for developing a non-minor piece of software. Such development tasks are challenging to estimate accurately.

The risk here is that once an initial time estimation and target delivery dates are provided, these values become set in stone and, as a result, set unrealistic expectations about the software development process.

Even worse – they might be considered as commitments.

And this is the central point of my article: estimates are not commitments, they're just estimates and should be treated as such.

Here’s a real-life example: In one of our projects, it took several sprints for our client to stop treating estimations as commitments. Once he understood that losing nerves over meeting estimates isn’t worth it in the context of software development, he decided to leave estimations out almost entirely. 

Why is it so difficult to estimate software development accurately?

At this point, you might be asking yourself this question:

If traditional software development estimation isn't accurate, does it make sense to do it given the required cost, effort, and time?

To answer this question, let's first see why estimations that aren't accurate. In my opinion, the primary problem with time estimates is that they rarely take into account the following issues that may crop up during the development process:

  • The productivity and experience level of the lead engineer and the entire team development team.
  • Staff issues such as early departures, late arrivals, sick days, holidays and others.
  • Customer requests, unforeseen defects, system and environment issues, software library issues, design and architecture problems, required research, and troubleshooting.
  • Unforeseen issues with software scalability, performance, testability, maintainability, or architectural flaws.
  • The time it takes to produce design, architecture, prototypes, mockups, PoCs, MVPs, and others.
  • Non-engineering tasks related to the project.
  • Administrative work required to complete the project.

As you can see, many factors may affect the development process, and it's tough to take all of these issues into account because they only become apparent once the development team starts writing code and building software. Experienced technology providers are aware of that and always add padding to estimates to account for such unknown issues.

Note: Requirements often change during the development process as well. If the initial estimate is considered as a commitment, the project instantly appears to be behind schedule – even though in reality it's not.

The traditional upfront planning, tasking, and time estimation may slow the project's progress and take up the time the team could be spending on more valuable tasks – for example, improving or creating products.

One of the most significant challenges in preparing estimates is that they're often developed by staff without in-depth technical knowledge. As a result, they fail to take into account these issues because they just lack the experience of leading a development team. At ARC, we address this problem by involving technical staff in making estimates. 

So how do we prepare better software development estimations?

Here are some best practices we have implemented at our company to ensure that the estimations we produce are as accurate as possible:

  • Involving business stakeholders in the estimation process early on. That way, we can define more accurately what is essential in the software development cycle and why. That business leaders and the development team share the understanding of the project goals, and everyone becomes accountable for that initial estimate.
  • Breaking down requirements to boost transparency. We do that to make sure that every requirement can be developed in a short time by a single engineer. Our team might not understand a requirement that can't be broken down for accurate estimation. The process of breaking down requirements helps all the stakeholders understand how much work it will take to develop the software. It creates a kind of transparency that usually shortens the time it takes to estimate development and reduces the approval time thanks to the shared understanding.
  • Building an amazing team. A team is not only talented developers but well-defined requirements that hold everyone accountable for the work – including the supporting cast. The project needs support from business analysts who write down requirements.
  • Effective Q&A testing plan is also essential. We always prepare tests early on to identify problems within the application when the code is still fresh in the developer's mind.
  • We ask small but essential questions. Once we estimate the requirements and assign them to developers and their supporting case, we need to take into account some details that may affect that estimate. Here are some questions we ask:
    • How long after the developer joins the project will it take them to be productive at 100%?
    • When will the first release of the product be ready?
    • How will vacations and holidays affect the project's progress?
    • How much will it cost to develop a feature?
    • If the project needs to be completed by us at a specific date, how many developers will it take to do it? How much development can a lead developer do when leading a team of two engineers versus a team of five engineers?

Producing accurate estimations is a critical skill a software development company needs to provide quality services to clients. That's why we continually evaluate and rethink our software estimation tactics, looking for new strategies to improve our process and create more accurate estimations for our projects.

If you're looking for a development team that is aware of project estimation challenges and has an excellent track record of completed projects, get in touch with us.