Estimations, as a way to slow down a team

Have you heard of the "Observer Effect"? It's a scientific term from the Quantum Mechanics field. It describes the phenomenon that the act of observing or measuring a system inevitably alters its state.

I'm not a quantum mechanics expert, but I have plenty of experience in Software Development. I've been part of teams, led teams, consulted teams, and helped apply various SCRUM practices.

In general, I like many aspects of software engineering and SCRUM.

In contrast, one of the widely adopted concepts I have mixed feelings about is: spending time on estimations (either as a team or individually).

Estimations usually involve figuring out how long it will take to deliver a certain feature. This can come in various forms, but most companies that I've worked with, are, for some reason, obsessed with it.

As an organization stakeholder, it is normal to favor estimations and enforce them. After all, every good process needs some level of predictability. Coming up with estimates that are communicated up the chain, helps to bring order into a chaotic roadmap.

Historically, I've been on both sides. I've been asked for estimates about how long my team will take to complete a certain feature. I've also asked individuals (with various skill levels) to estimate how long they think a certain activity will take.

(I'm not even touching upon the idea that estimates in the software world are always wrong )

Let me be the "devil's advocate" here and share my unpopular opinion about estimates in the software world:

Estimates are healthy for junior engineering teams

Software estimations are useful for teams that consist solely of junior to mid-level engineers!

Maybe junior to mid-level. Why?

• A junior engineer is more likely to get sidetracked and lost into the details of implementation, or steer towards overengineering. An estimation helps to put a guardrail on this and helps the engineer naturally limit the amplitude of their experiments and focus on the code problem only (e.g. apply the 80/20 principle more efficiently).
• Junior engineers, because of lack of expertise, sometimes need the estimation exercise, as a way to pause, take a step back, and strategize about the solution, rather than jumping to the first thing that comes to mind.
• An estimation, done together with management/stakeholders, can help align expectations. If you think a problem can be solved in 5 days, but management expects it in 1 day, communicating this misalignment in expectations, might help the management shift efforts into other low-hanging fruits.
• Some organizations use estimates as a lightweight pressure tactic to force junior engineers into performing better. While I don't usually approve of such practices, I also realize that humans need some sort of time to occasionally sharpen focus. As the engineer gains expertise, estimates become less and less effective as an output/productivity booster, and more of a friction point between management and engineering (with debates like: why you did this in five days instead of the estimated three).

Estimates are hurtful for teams of trusted, senior engineers

Senior teams usually work on tough challenges that have never been solved before in the same context. With lots of unknown unknowns. It's impossible (or rather, inaccurate) to try to estimate how long it will take to go to the Moon if nobody ever went there first. It's a rabbit hole.

Senior engineers have an established work discipline that revolves around delivering results, not filling spreadsheets. This includes solving problems around their area of expertise.

E.g. if you are a REALLY good and reliable JavaScript engineer - you know how to deliver features in JavaScript, that are solid, well-maintainable, scalable, following good practices, etc, etc.

But filling time sheets, Excel tables, and Story Points in Jira tickets - is outside your area of expertise. It forces you out of your natural daily flow and forces you to step into bureaucratic shoes occasionally. Which, let's be honest, is a boring activity for an engineer.

It's no wonder that a majority of team members "zone out" during synchronous planning sessions or estimating sessions. If you force a senior engineer to estimate their work, it naturally steals from the productive work hours of their day.

This, I think, is a good analogy for the "Observer Effect" from quantum mechanics.

Summary

I'm not saying Software Estimations are useless in 100% of cases. Like every topic, there are nuances. There are some scenarios where asking for estimates is useful, for example:

• A team is performing below some standards and you'd like some visibility into individuals' output
• The team consists purely of junior engineers, due to the reasons I outlined earlier.
• The tasks are fairly repetitive or have a predictable complexity (there are no unknown-unknowns) so estimates are closer to reality
• You are forced to provide estimates somewhere up the delivery chain (e.g. your client asks for it)
• The organization needs estimates from various teams as a high-level mechanism for monitoring the load of teams or distributing resources/people/effort. In this case, estimates should not be looked at individually, but rather as ballpark guesses of when certain teams expect to have some available capacity.

With a decade of experience in software engineering, Dzhuneyt specializes in programming, architecture, DevOps, and Cloud applications. His passion lies in simplifying complex technologies and sharing knowledge through writing. Follow Dzhuneyt A. for more real-life examples of connecting the theory with practical tech solutions.