Business
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.
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.
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.
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.
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:
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.
Here are some best practices we have implemented at our company to ensure that the estimations we produce are as accurate as possible:
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.
