Software estimation is your most costly activity. Why not reduce it?

If your first reaction to this article’s title was to think of other activities in software that are more expensive than estimation, that’s ok! There are probably plenty of expensive things you are doing like sending large bags of money to AWS each month.

However, the title says “most costly” and not “most expensive”. Estimation of potential future work is easily the most costly thing we do, because the effort of estimation creates almost nothing of value for the business.

Even a badly-architected application written in spaghetti code and running on overpowered machines will have some value to your users. But estimation? It’s almost entirely pure waste.

Estimation generates no value for users

Imagine someone asking an engineering team what they worked on for the last week, and getting the answer, “Well, we didn’t ship any features, but we sure made our story points more accurate!”.

As silly as that sounds, it plays out in engineering teams across the globe all the time. As you’re reading this, thousands of engineers are trying to figure out the days and weeks of effort to improve some software that you’re using right now, instead of simply making those improvements.

Estimations are frequently demanded by project managers so that they can tell if a team will meet a future deadline. However…

Estimates are wildly inaccurate

Countless articles and papers are available on the utter uselessness of estimations for the purposes of planning. The evidence is damning, and clear: software estimates are disconnected from reality.

The complexities of modern software development along with unpredictable external factors make it essentially impossible to estimate within a reasonable margin of error.

Estimation incurs huge opportunity cost

Any time spent on estimating is time a business could spend creating new features, experimenting, innovating, delighting users, researching, testing, gathering feedback, fixing bugs, documenting, automating repetitive tasks, training in new skills, running hackathons…you get the idea. 

Spending time estimating a project is an enormous cost because it eats into what the team could be doing. And in my experience, teams can always think of much more valuable things to do than refining that 37 day estimate to make it fit into a month.

Estimation-dependent cultures create damaging behaviours

Estimation-dependent cultures appear in teams that can only decide what to work on when they have detailed forecasts available for all potential future work. On the surface, it might seem diligent to plan in that way, but that approach causes significant negative side effects to emerge:

Planning Tetris

When a team is asked to continually provide detailed estimates (and are then expected to meet them), project managers will feel safe mapping out a Gantt chart of activities for months into the future, shaping the coming weeks with contiguous projects like a well-played game of Tetris.

That plan will then get set in stone, and diversions away from it will become very difficult. New opportunities won’t be sought, agility will be seen as an enemy to progress, innovation will stall, and the team will fall further into Feature Factory mode.

Decide-By-Effort

When a leader puts too much importance on estimates, they will quickly devolve their own decision making process into one where they can’t decide what their team should work on without knowing an “accurate” estimate for everything first.

Effort can be a helpful factor in decision making (especially if you’re using a framework like RICE scoring), but effort estimates generally don’t need to be very accurate to inform those decisions. A simple “finger wag” estimate for a project to know if it should take a few hours, days, or weeks is more than enough to make a decision on product priorities.

If your decision process needs “refinement” to the level of breaking a big thing down into lots of detail, that’s not estimation, that’s literally doing the work.

Analysis Paralysis

When detailed estimates are seen as a pre-requisite to any work being considered, a team runs the risk of repeatedly estimating potential work.

The team spends days scoping future work out, refining stories, spiking, and finally delivering their estimates to their product leaders. During that time, new events have occurred that now make the product leaders consider a different plan, and so they ask for detailed estimates on the new items. It is not uncommon to find teams that go into repeated cycles of “estimation work” because their product leaders have fallen into this trap.

Misery and Burnout

When an organisation puts too much emphasis on estimates, the engineering team is almost always “held to account” to meet them, despite the fundamental unreliabilities of estimates as predictors of the future.

Many times, this happens because commitments get made to customers by sales teams as if engineering estimates are contractual guarantees of future delivery.

The team will likely be forced to meet an estimate they gave weeks or months prior, no matter which critical staff member recently just left their team, no matter what technical surprises they encounter, and no matter what external vendor dependencies go unmet. Those factors will lead to the team having a terribly tough time trying to meet the original estimate, causing a drop in morale and quality.

Teams that follow the Sustainable Development model will prevent this situation by creating a culture where estimates are consistently treated as estimates, not as high-integrity commitments.

Sandbagging

Even a basic knowledge of Systems Thinking will allow anyone to predict the reactions of engineers who suffer through the negative situations described above.

When morale-crushing effects are experienced by the people who deliver estimates, a reinforcing loop of negativity – commonly known as a vicious cycle – emerges. The engineers, burned out by the last project’s crushing schedule, expand their next estimates with extra buffer time. This tactic (“sandbagging“) is detected by management, who demand more accurate estimates and lose confidence in the engineers. The engineers dig in their heels, and the situation worsens.

Tips for a healthy estimation culture

This article is not a call for software teams to abandon estimation completely. Quite the opposite! Estimation, when done rapidly, can be a useful input for guiding decisions around feasibility and viability of new product work.

Ironically, it is significantly less effort to prevent the dysfunctions associated with a strong reliance on estimates than it is to keep a heavy dependence on them:

• Don’t focus on making estimates more accurate. Instead, focus on minimising the time spent estimating. If you spend more than literally a few minutes estimating something, you’re just wasting time.
• Focus your organisation more on creating feedback loops with your users and responding to their needs as opposed to estimates being the primary factor in decisions on what to build.
• Work in small batches. Use a rubric like “every story must be do-able in 2 days or less” as opposed to trying to figure out the exact number of days everything will take. You’ll be surprised at how much easier everything gets, and how much more valuable user feedback your work will generate.
• Use a coarse scale that is easily understandable by all. I like to ask, “is it measured in hours, days, or weeks?”. The answer doesn’t need to say how many hours or days or weeks, but it’s helpful to know which bucket it’s in. And best of all, engineers are usually able to answer this question very quickly.
• Consider not estimating at all. You’ll have plenty of company.
• Build a shared understanding across your teams about how estimates should be interpreted. For example, make sure your sales team never makes contractual commitments based on them.
• Make sure your product vision and product strategy are clear. Those do more to help clarify priorities than any estimation process could ever hope to.

Estimates are educated guesses of outcomes in a dynamic and highly variable situation. Let’s start to treat them as such, and use them appropriately.

Photo by Mikael Kristenson on Unsplash