Zenful Estimates: Ditching Task Estimates to Build a Faster Team

When your project manager demands an estimate send them this blog article

Mar 14, 2024

Raise your hand if you’ve ever been in a planning meeting, assigning estimates to tickets, and either found yourself multitasking, falling asleep, texting a friend, or otherwise being entirely unengaged in the activity. If so, you’re not alone. There’s this thing about engineering estimates that is sometimes overlooked: they’re not useful in the way that people often think they are. Instead, estimates are often misused; it’s time for R&D leaders to consider a new framework that makes it so there’s one fewer meeting (or at least a shorter meeting) for you to zone out of.

I call this new framework the Zenful Estimation method. It boils down to this: embrace your inner Zen, and don’t do task estimation.

Summary

Engineering task estimates aren’t free; in fact, they’re really expensive, often costing half a week or more of total person-time in a sprint. In addition to the time cost, there is also the mental burden, overhead, and anxiety associated with being held accountable for the results of a handwavy estimation process.
Engineering task estimates are rarely accurate, and it’s not because any given team is bad at estimation or because you're using the wrong t-shirt-size or Fibonacci pointing method. Estimates aren’t accurate because the underlying problem does not lend itself well to being estimated upfront.
I propose that most teams are better off using cheap to produce accurate but imprecise (i.e. wide-time range) project estimates for cases where the business actually needs to plan how long a project might take.

A short history on the origins of Software Engineering Process

In 1970 Winston W. Royce published a paper describing the development of large software systems (it’s only a few pages and worth a read!) Despite not using the term Waterfall explicitly (that likely comes later in the 70s, perhaps in Bell and Thayer’s paper in 1976), Royce outlined an approach many would recognize today as Waterfall. Perhaps surprisingly, this early paper, one that is often cited as the first real description of Waterfall, claims that software design is fundamentally an iterative process.

Figure 3 portrays the iterative relationship between successive development phases for this scheme. The ordering of steps is based on the following concept: that as each step progresses and the design is further detailed [...]. The virtue of all of this is that as the design proceeds, the change process is scoped down to manageable limits.

Even in 1970 Royce recognized that it is impossible to accurately design software systems in a vacuum upfront. A workable solution can be achieved only via collaboration with others and by iterating on various steps of the design process.

There’s an assumed axiom in this blog post that engineering estimates are unreliable, and in my experience and for nearly all other leaders I’ve talked to about this, they are. We see this in data, too - in LinearB's 2024 Engineering Metrics Benchmark data, just 30% of software organizations had a planning accuracy of over 60%.

If you do happen to run an engineering team with really accurate estimates and think you’ve found a magic formula please do get in touch with me. I’d love to reward such generosity, and while I’m not Jon Oliver and I can’t offer you a million dollars or a coach bus, if you’re ever in LA I’ll buy you dinner and gladly publish your formula in the next edition of my book. You can also share your approach in the comments 👇

Software Engineering Estimates today

So maybe the Waterfall model is not quite what you thought it was; why am I blogging about this over 50 years later? After all, we have Agile and Scrum and Kanban and Scrumban - Waterfall is pretty rare, right? The issue is that these modern methodologies are often applied in ways that misconstrue an idea that Mr. Royce recognized all those years ago - that you don’t know what you’re getting into with software engineering until you’re in it. There persists an assumption that we can upfront accurately size, estimate or predict how long a software project will take.

Scrum estimates with story points, or sometimes t-shirt sizes, not dated estimates. That’s a step in the right direction, recognizing that estimates are, at best, guides, not guarantees. However, it does beg the question, are estimates as guides even worth it? These guides, after all, still depend on the idea of estimating the size, in some roundabout way, of an engineering task upfront. How much value is offered by the estimations that teams do nowadays, and is it worth the cost?

Task vs. Project Estimation

I want to distinguish task estimation and project estimation. Task estimation is what is commonly done in engineering team planning meetings as part of some version of an agile ceremony. Project estimation is much higher level and is often done by some kind of manager when scoping significantly larger chunks of work, think months at a time. The pain most teams feel about estimation is generally a result of using task estimation in places where informed project estimation is a better fit

The Perils and Cost of Task Estimation

To answer the question of “Is it worth the cost” let’s break down some of the promises offered by task estimation and compare that to what often ends up being reality.

The Promises

Project Planning

The promise - Task estimates will help us communicate expectations to stakeholders.

The reality - Task estimates are often not reliable, and worse, despite best intentions, they are regularly interpreted as guarantees, and teams are held accountable to those estimates. This creates perverse incentives for teams to pad estimates when communicating to external stakeholders and can lead to politics/gaming of the system and unnecessary organizational tension. A project estimate, which can be done relatively cheaply by a well-informed manager, would be a better fit.

Prioritization

The promise - Task estimates will help managers figure out which work to do when

The reality - Sprint planning meetings are most valuable when it’s engineers working with technical constraints, ordering and triaging technical work to be done. That’s the real day-to-day prioritization. Prioritization at a higher level, project prioritization, should not be based on the sum of many small task estimates. Being 25% wrong about 20 tasks is worse than being 50% wrong at a single high-level estimate. Better yet, a single high level estimate won’t cost your team hours in meetings every sprint.

Resource Allocation & Dependency Management

The promise - Estimates can show what resources will be available when, allowing planners to allocate resources in a way to maximize throughput

The reality - One estimate in the chain is off, throwing off all the “dependent” plans, and the whole thing may need to be resequenced. Resources aren’t available when expected, and projects are delayed anyway. Acknowledging reality and having wide error bars on any project planning Gantt chart is better.

Continuous Improvement

The promise - Measuring velocity via estimates/points/t-shirt sizes lets us see where we’re at and whether we are improving

The reality - There’s not enough quality signal to see improvements or regressions in the noise. Instead teams feel demotivated by the lack of quantitative velocity progress and are often incorrectly punished as a result. If you’re not careful, using velocity as a crucial metric can be dangerous to teams.

The Costs

Time

In my book, The Startup CTO’s Handbook, I walk through a typical week for a software engineer:

Consider this hypothetical week for a software engineer:
One hour: 1:1 with manager
Two and a half hours: daily thirty-minute standup meetings
Two hours: average time spent in other agile ceremonies (sprint planning, retrospectives, etc.)
Four to eight hours: reviewing others code
Four hours: email/chat communication
In total, that's about thirteen to seventeen hours of the week used up for meetings and communication. If you add another few hours on top of that for time spent context switching and unplanned miscellaneous interruptions, quickly you're looking at at best half of a forty-hour work week available for actual focus time. If you're not careful about when meetings are scheduled, then not only will your engineers have only twenty hours left for their core tasks, but also they won't have them in contiguous blocks, further reducing productivity.

It’s very easy for an engineer to have 30-50% of their weekly hours taken up by non-engineering work - primarily meetings and communication. A planning meeting that spends thirty minutes, or I’ve sometimes seen two hours, simply adding estimates to tickets means two fewer hours available for actual work. Will those two hours, for the whole team, make the difference in your project? Maybe or maybe not, but by keeping the bar high for what you allow to take time from actual engineering, you get back these 2 hours and potentially several others, which can add up to a lot of recaptured velocity.

Morale

There’s nothing worse than putting in all this effort for a metric and then being punished and held accountable to something that wasn’t set up for success anyway, and worse, it is not a reflection of the team’s actual performance. Let’s also not forget Goodhart’s law:

“When a measure becomes a target, it ceases to be a good measure"

By removing estimates, you remove the mental burden and anxiety related to those estimates, the unintentional promises that estimates make, and the grief from management when inevitably, the estimates are inaccurate. In summary, removing estimates gets you meaningful wall-clock time back, and perhaps even more importantly, it removes a mental burden your team members are carrying that causes far more grief than benefit.

The “Zenful” Engineering Process

My solution to the inaccuracy of software task estimation is simple: don’t do it.

You may have external deadlines or a real need to coordinate with other groups or projects; I’m not downplaying those business realities. I’m saying that you can achieve those things without putting some arbitrarily quantified estimate on individual engineering tasks. A reasonably technical manager who works closely with the team to understand the nature of the work being done can generally provide imprecise but accurate enough estimates to meet those needs without measuring individual tasks.

So here’s the “Zenful” estimation process: Your team breaks down work and plans however works best for your team, without any pressure or stress from management to estimate individual tasks. The manager of the team should be a technical person who can communicate well with the engineers and understand the nature of the conversation as the work is being discussed. They should produce a project estimate that everybody can squint at and say is probably in the ballpark. This should be a very broad range, something like “1-2 sprints” or “6 to 10 weeks.” Especially when specified as a range, you actually have a real shot at hitting those numbers.

Has this article been thought-provoking? Please share it with your friends! 👇

Let’s make this concrete by example. For the sake of drawing the comparison, let’s say your team is working on a project and the task estimate approach says it’ll take two sprints (or four weeks) to complete the project. The manager-driven project estimation approach estimates four to eight weeks to complete. Using our benchmark data that task estimates are optimistically 50% accurate let’s follow the oft-cited “double the engineering estimate” rule and imagine the project actually takes closer to 8 weeks.

In more concise terms, here are your choices:

We spent a lot of time and effort thinking about it, and it’ll take 2 sprints, but we’re almost certainly wrong and it’ll take 3 to 5.

We spent almost no time thinking about it and it’ll take 1-2 months and chances are good it comes in that range.

This makes people uncomfortable; as engineers, we want to be able to establish causality and show clear links from X to Y, and I’m advocating that when it comes to project estimation, you give up on that. That’s why I call this the Zenful method. It requires that you embrace some degree of zen (inner peace), and give up on a clear link between granular work and high-level estimation -- the reality is that link was never there to begin with.

With estimates out of the picture, your team gets time back; nobody is playing politics or gaming a system, and teams aren’t being held accountable to low-signal velocity numbers. Instead, you can focus on the real work of software engineering and continuously improving. After all, wouldn’t you rather your teams spend their energy getting better at doing engineering than getting better at guessing story points?