Myriad discussions in software engineering have persisted over the decades. How exactly to estimate work is one of them. Should they be created by architects or by the team that will execute the work? Is it best to express them in hours, story points, or T-shirt sizes? Are you supposed to add estimates to bugs and other urgent work retroactively?

But where does the need for estimations come from?

When your team follows a waterfall approach and needs to plan resources for each phase, there is hardly a way around them. That need is no longer relevant with modern software development and self-managing teams.

Teams often adopted estimation practices when introducing SCRUM as the framework of choice. Did you know the 2020 version of the SCRUM guide removed the last mentions of estimates altogether? And even before that, estimates were never intended to evaluate how much work would fit in a sprint.

So why are so many teams still using estimations? Do they still bring any value, and where does that value stop?

The value of estimations

Although estimations are misapplied, that does not mean they can't provide value. Taking the time to understand the amount of effort something would cost makes sense — especially during prioritization. When two things are equally impactful, or the difference in impact is slight, the amount of effort can be decisive.

Theoretically, it would seem logical to always do the most important thing first. However, important things sometimes require vast amounts of work. Low-hanging fruit can be a welcome change for team morale and show customers that the product is still moving forward.

When two things are equally impactful, or the difference in impact is slight, the amount of effort can be decisive.

Estimations help a team properly define the scope of work, determining a timebox or maximal effort to spend on a specific topic. The most impactful thing might be redesigned simply because the cost of it does not create a return.

At a lower level, estimations can help a team get aligned when it comes to creating a mutual understanding of the complexity of a task. Misaligned estimates show that some members see hidden complexity.

In other cases, the fact that the team feels uncomfortable estimating the work at hand may indicate that time-boxed research (prototyping!) is needed to fully understand the effort required. Estimates are then merely a tool to surface this misalignment within the team.

Estimations are a way to start a conversation about confidence. The value is the discussion, aligning the team around the complexity and scope of the work. If you can create these conversations without estimates, even better.

Where the value of estimations stops

Experienced teams who have been on the project for a substantial amount of time should have a broad understanding of the application. They already work more predictably and will signal if something unexpected arises along the way. There is a reduced need for estimations here.

Estimations can force junior teams to think things through before they start working on new features. However, junior teams have difficulty grasping complexity. Their estimates are often inaccurate — demotivating — which discredits the team with the rest of the company.

It becomes tricky when people attach more value to estimations than they should. Companies are often in charge of their own delivery dates and only imply deadlines upon themselves. Once these dates are set, some companies make them hard deadlines. This can create tension and stress if teams crunch to finish competing priorities on time.

Estimations might seem necessary when it comes to sprint planning when teams try to fill a sprint with precisely the achievable amount of work. However, you'll often be wrong. Defining estimates in a time component is difficult.

Will the team be allowed to focus on nothing but this initiative, or will there be distractions? Will customers give input that impacts the amount of work? The worst thing one can do is ignore customer feedback to be able to deliver on time.

Estimations might seem necessary;... however, you'll often be wrong.

Will the entire team be available? Team composition is likely changing with new team members joining, holidays and sick leave being scheduled, and people leaving the team. While estimates and velocity might give a manager the feeling of being in control, it's a brittle and false sense of security.

It's always right to ask yourself what the added value of low-level estimates are. What will you do with any work you couldn't tackle? Often, you'll just move it to the next sprint. Here, the estimation doesn’t matter. The work just needs to be done and is the highest priority.

Finally, people are often surprised that SCRUM has yet to recommend using estimates to fill up the next sprint. As of the last version of the scrum guide, any mention of estimates has been removed.

The alternative to estimating work: building trust

What it all comes down to, then, is trust. If everybody is aligned on the goal and how to reach it, you count on your team to escalate as soon as unforeseen issues arise. Then the need for accurate estimates is soon eliminated.

Note that transparency plays an integral part in the creation of the trust. It's essential to provide clear visibility on what everybody is working on and to keep close feedback loops on progress (or why you've halted). Loop in people who are higher up the chain of command so they are also aware. Often it's these people who miss control, control that estimates cannot provide.