The Problem With “No Estimates”

A significant portion of the software industry has developed techniques and processes to avoid estimation.

Agile methodologies, for example, commonly replace time-scale estimation units with alternate vocabulary like “T-shirt sizes” and “story points”; poker planning is another example which removes individuals providing estimates in favor of collective, team-based task and story sizing.

Of course, these methodologies have their motivations: they’re a response to repeated failed attempts at estimating and predicting software projects. Software businesses that want to remain competitive must have at least some strategy for deducing software costs and delivery times. To many, these “No Estimates” processes seem to be the best options at the table.

But there’s a root problem with these methods. They’re compensatory: they ultimately exist to cover for a lack of skill set among members of the team and the organization. Software developers are notoriously bad at estimating, and many are simply loath to give estimates at all.

This lack of the estimation skill set among developers is completely understandable:

  • A vast majority of software developers are not taught estimation skills, neither in industry nor academia.
  • Estimates are almost ubiquitously misunderstood by business managers, who misuse estimates to make unreasonable commitments—sometimes coercively, but often with well-meaning intentions. In turn, estimates (and estimators) are frequently scapegoated when such commitments are inevitably failed to be met.

These two conditions alone create a destructive feedback loop in which estimating becomes a taboo, almost dangerous, endeavor. No wonder the industry trend is to shy away from estimates.

But we have a paradox: businesses—from nascent startups to established enterprises—require predictability, and yet predictions (estimation) from individuals are politicized and ultimately shunned.

“No Estimates” methodologies are an attempt to reconcile this paradox by treating the predictability problem with kid gloves—absolve individuals from giving estimates while contorting ways to extrapolate estimates “at the top”.

The Biggest Loser in the “No Estimates” Game

The software industry has devised many variations of the “No Estimates”1 process, some more sophisticated than others, but all effectively the same: all an attempt to “approximate” and “pad” over a team’s inability to produce and manage estimates explicitly.

One might say, so what? Isn’t this approach sufficient? Why not embrace the “No Estimates” processes, and carry on?

For businesses and management, these processes are notoriously inconsistent: they (sometimes) work when they work, but often fail from iteration to iteration. Furthermore, they are sensitive to project instability such as personnel changes, etc. And because these processes purposefully obfuscate or hide the terms of the problem (i.e., time), they cloud visibility, leaving teams and their managers wondering why this week’s or month’s sprint was such a disaster when the last one was delivered precisely on time2.

The ultimate reason for a team’s failure or success on any point of skill, of course, should be obvious:

  • A team is as good as its constituent individuals—e.g., a team’s programming ability is as good as the programming skills of any one of its team members; the same is true for a team’s estimation ability.
  • Any methodology or process that explicitly removes the estimation responsibility from each team member is guaranteed to not develop that skill set in its team members.

So while “No Estimates” processes may assist a specific team in hobbling through occasional predictability, the software developer is the biggest loser in these methodologies—by design, these processes leave a crucial individual skill set entirely undeveloped in each individual team member.

Not only does this deficit in skill set place a limit on one’s overall expertise, it is increasingly a career limiter especially in the context of other developers that do cultivate the skill set.3

“Yes Estimates” and the Software Developer

Should software developers estimate? That is, is the estimation skill set worth learning, practicing and cultivating?

The truth is—at least for time being—it is a seller’s market for software developers. A modicum of technical skill set can make you reasonably competitive in today’s general hiring market.

Still, this isn’t enough to become complacent. As the software industry matures and as technology advances remain apace, predictability in software delivery—and the skill set that can produce it—is becoming increasingly significant for market participants across the board.

Ultimately, nothing beats an intrinsic motivation to master one’s craft beyond just optimizing your paycheck. More often than not, the estimation skill set is simply in the blind spot of software developers that otherwise want to master their craft.

In a healthy businesses, managerial stakeholders (product, project, and people managers, e.g.) quickly zero in on programmers that can technically deliver with predictability.

Pure technical ability is increasingly becoming table stakes. Highly capable and technical programmers are “managed off” mission critical projects precisely because they can’t predictably deliver. Conversely, developers who are willing and, crucially, able to give reliable estimates can expect to rise above others to have the attention of business leaders.4

One major “secret” to advancing in a technical career is learning how to give accurate estimates.5

Observations like this one have been made by experienced practitioners for a long while, but are increasingly entering the zeitgeist. The estimation skill set grows increasingly relevant as more software developers acquire and leverage it.

The good news is that—in spite of whatever upstream process one’s team uses to manage their “sprints” and deliveries—software developers can learn, practice, and master the estimation skill set on their own, in private, independent of and adjacent to their team’s process.

This is worth doing. Estimation is a transferable skill set. The skill set can be practiced and cultivated even by software developers that aren’t in business contexts yet able to leverage predictability. By not practicing the skill set, naturally it won’t be there in contexts where it can be leveraged.

Given that estimations are often exploited and politicized, practicing estimation in private, as a local activity is an ideal way to improve. Even for experienced estimators, a large part of the process will always be personal. It is very easy to practice, observe results, and iterate alone to perfect the skill.

Specifically how to estimate and how to grow the estimation skill set is crucial to the argument posited here. A future post will soon elaborate on how to estimate in detail.


Footnotes

1 You will see even the “Yes Estimates” camp fall into the trap when giving estimates but effectively negating them with arbitrary padding factors and number fuzzing.

2 And why they didn’t notice the approaching failure until the last minute.

3 The good news is that the skill set can be learned. More on how to learn estimation and grow the skill set will come in a future post.

4 Able is the key word here. Estimation is a skill set. You’ll know when you’ve developed the skill set enough to give confident estimates at the right time. A future blog post will break down the path to developing this skill set.

5 From https://jacobian.org/2021/may/20/estimation/.