DEV Community

Cover image for Why Estimates Are Waste
Ben Brazier
Ben Brazier

Posted on • Originally published at torvo.com.au

Why Estimates Are Waste

Software development is unpredictable but people waste hours every week trying to guess how long tasks will take.

No Estimates

Estimation can provide confidence in future changes, but this doesn’t apply to software development because:

  • If you can predict work then you should automate it instead of repeating it.
  • If you can’t predict work then attempting to do so is a waste of time.

Automation Instead of Accurate Estimation

Repetition increases predictability. It isn’t possible to accurately estimate how long a task will take if you have never done it. In other words, the more you repeat a task the more predictable it becomes.

Predictability ≈ Repetitions

Repeated work should be automated. In software development the ability to re-use libraries, frameworks, and APIs means that repeatable work can be automated. The more you repeat it the more effort would be saved with code re-use and automation.

Value of Automation ≈ Repetitions

Accurate Estimates Correlate with Wasted Effort. As repetitions increase the value of automating and the predictability both go up. Therefore …

V ≈ R ≈ P

Inaccurate Estimation is Harmful

If the purpose of estimation is to plan around the future then inaccurate estimates can only lead to problems. This is compounded by the cost of estimating work in time and effort.

Instead of spending time and effort on estimating work that can’t be predicted or should be automated we should find alternatives. One of the most agile approaches is to work without estimates.

Working Without Estimates

Working without estimates is critical to good software development and goes hand in hand with continuous delivery. The simplest process to work without estimates is:

  1. Identify the most valuable task.
  2. Work on that task.
  3. Repeat.

It is important to consider the time spent on estimating work and the value it provides. This minimal process may be too strict for you but next time you are estimating your work consider the value it provides.

If you would like to discuss this further please contact me on Twitter @BenTorvo or Email ben@torvo.com.au

Top comments (43)

Collapse
 
javibarbaran profile image
Javier Barbaran • Edited

Hi Ben,

That is an interesting point of view regarding software estimation, thanks for that.

Actually, this topic becomes very controversial when you mixed software developers with managers, as it all depends on the point of view. From business perspective, software estimation are basic, from software development a estimation it's just that .. an estimation. So, I would recommend (if you haven't read it yet) "Software Estimation: Demystifying the Black Art" amzn.to/39SiAYW

Because... What is an estimation? What's the difference between an estimation, a commitment or target? Actually, that's the first chapter of the book, and the author provides with an example that most of software engineers have faced at some point: A manager asks for an estimate, when they are really looking for a commitment or a target.

So from my software engineer point of view I agree with your focus, but from companies point of view probably an estimate (or commitment or targtet) is mandatory. Therefore, I think a balance between both trends is mandatory.

What do you think? Do you agree?

Collapse
 
bentorvo profile image
Ben Brazier

Thanks for the feedback.

I think companies that try to plan too far ahead can't respond quickly and effectively to changing technology and markets. This might or might not impact them.

I think we should focus on prioritisation and delivery over estimation and planning. We don't need to worry about planning if we are sure we are working effectively on the most important thing.

Collapse
 
sirseanofloxley profile image
Sean Allin Newell • Edited

Now you're talking more the language of LEAN agile practices of which I'm engaging with more nowadays. Throw out waste, work on the most important thing, be confident in the next week and less so in following weeks, and go through predictable cycles of planning for things a month out and for this quarter.

Planning anything beyond this quarter will change a ton. Beyond 2 quarters is just business prioritisation/roadmap planning of what to engage in after resources finish up current projects.

Collapse
 
bowiechang profile image
bowiechang

Very thought provoking! It seems to be that the managers have to be agile trained in order for this to be facilitated smoothly throughout?

// not speaking from experience, never been in a full agile team

Collapse
 
jonrandy profile image
Jon Randy 🎖️ • Edited

Totally agree. I try to push for no estimates wherever I am, and refuse to do them if asked. I've never seen any benefit in them at all... they usually just lead to: broken promises, rushed work, massive over-estimates to avoid missed deadlines, and generally a bad atmosphere.

Collapse
 
lexlohr profile image
Alex Lohr

Estimations have no value for development; they are a necessity of management in order to be able to plan. However, neither an estimation nor a plan ever survived the battle with reality.

The main reason is that estimations are one-dimensional, while reality knows the dimensions known effort, unknown effort (risk) and external dependencies. Only the first dimension can be estimated to near precision with enough experience, everything else is guesswork.

Collapse
 
phlash profile image
Phil Ashby

Completely agree with the points that only repeatable things become predictable, and thus should be automated - this is the 'lean' production engineering mantra 😁

Trying to avoid predictions for creative work such as writing new software, or designing new artwork for a game, or architecting a new town.. requires a cultural shift for most organisations to accept that customer feedback matters, not meeting arbitrary deadlines.

Ron Jeffries (of agile fame) has written on this topic in the past (as have many others!): ronjeffries.com/xprog/articles/the...

I think the #noestimates mantra goes hand-in-hand with 'products not projects', and 'first make it effective, then make it efficient' - noting that creative work is always at the effective stage, since there is typically no follow on production process to optimise!

Collapse
 
bentorvo profile image
Ben Brazier

Accurate estimates are valuable to management. I don't think accurate estimates are feasible in good software engineering and a managers job is prioritization over planning.

Collapse
 
gtanyware profile image
Graham Trott

Over a long career I came to the cynical conclusion that in many large organisations the primary job of a manager is to pass good news upwards.

Collapse
 
nombrekeff profile image
Keff

I agree with this one. One thing to consider though, is that, for consulting companies, like the one I work at, we need to create bugets/cost estimations for certain developments. So estimating is kinda required, otherwise we don't know how much to charge them. But it's really difficult to calculate, so we usually double or even tripple our initial estimations, and even then we sometimes take longer to build.

Collapse
 
mcsee profile image
Maxi Contieri

Have been working on software for 30 years

Never seen an accurate estimator/estimation

Great 3 points algorithm

Collapse
 
gtanyware profile image
Graham Trott

After 30 years, the best estimates come from a gut feeling. Intuition gets more accurate with experience but it's often hard to explain why you 'feel' it should be 3 months rather than 3 weeks.

Collapse
 
ryanpwalker profile image
Ryan Walker

The word automation is used a lot in this article but is never actually elaborated on. The only detail I could find is reusing code as a form of automation. What other forms of automation are you referring to?

Collapse
 
bentorvo profile image
Ben Brazier

Automation through code-reuse with packages and automation of processes through code and APIs. There should be a strong focus in reducing manual work to maximise the speed to deliver software.

Collapse
 
bowiechang profile image
bowiechang

Hello Ben,

Thank you for the read, was interesting and our team had similar thoughts on estimation as well! But one thing I currently am suffering from is a bad estimate could go wrong as an agency, clients that are not well versed with agile and old-fashioned would return any further discussion on planned timelines with only negativity.

Other than culling out such clients, what are some of the ways we can prevent this from happening? It is indeed unpleasant on both sides, let me know if anyone have a fair share of this!

Thanks :)

Collapse
 
bentorvo profile image
Ben Brazier

I don't think it there is an easy solution to change culture.

A good start would be to engage with clients in smaller pieces of work more frequently. So instead of a large contract, try delivering a smaller set of deliverables sooner with renewal to continue the work. That should reduce risk while still allowing for the same or better long term results.

This is the same way we implement continuous delivery but at the end of the day it relies on building trust and responsibility to make sure that we are providing value to customers.

Collapse
 
brense profile image
Rense Bakker

Agreed, the past few companies I worked for wasted a considerable amount of time on story refinement and estimates. Their velocity was always really low compared to other projects I worked on. Personally I don't give a rats ass if the story I'm working on is 2 points or 5 points, I still have to do the work. From a management point of view it has no value either... What they really ask for is a global estimate: When can we go into production with this product.

Somehow people have convinced themselves that they can give a more accurate global estimate if they take the total amount points estimated for stories ( which get added onto constantly) and divide it by the teams velocity (that is never the same, due to people getting sick, holidays, devs having a bad day, massive stories that carried over from previous sprints...) Its utter madness really 😛

Collapse
 
0xdonut profile image
Mr F.

We estimate on perceived size and complexity using tshirt sizes (S...XL) or Fibonacci if the PM needs to do some analytics. Time estimates never work and put undue stress and anxiety on all involved.

Collapse
 
bentorvo profile image
Ben Brazier

What analytics would they be doing? I imagine it would be something to do with estimating how much work can get done in a sprint.

Collapse
 
miketalbot profile image
Mike Talbot ⭐ • Edited

We'd do this for Weighted Shortest Job First - so asking a dev: "is this a much bigger job than that? Because if it is I'll rank the one you think is easier first", and of course, possibly never do the really really hard job as it might not be valuable enough. We don't really do this for sprints - just for epics/features etc.

We also insist that those putting a value on a thing also make T shirt sizes for the value.

Collapse
 
maddy profile image
Maddy • Edited

I agree with many of the points you made.

To add on this:

  • Estimates are meant to give a prediction on the complexity of a task. Not how long it's going to take to complete the task. This is where, many times, my frustration has come from as a software engineer.

  • Just because a ticket is a 3-pointer, it still doesn't mean you'll complete it "faster".

  • Software engineering has often a level of unpredicatibility and unknown. And indeed, it's part of the job and your responsibility to Google/read/ask about what you don't know.

  • My interpretation of "I had done X before" means that I know 80% of the task. The remaining 20% needs to be figured out, and that 20% may or may not be easy to navigate.

  • Estimates are useful for management, because they want to know when they'll be able to release a money-making feature to customers. I find them pointless from the developer's point of view.

But, since software engineering is a lot about business, we have no other choice than caring about estimates and trying to give the best guess.

Collapse
 
quooston profile image
Quooston

If you can't estimate with some degree of certainty, that you can often achieve within 10% of that estimate, you're not in a great environment. All my teams in the last 12 years have been able to do this. I've been in the industry for 22 years, and in the last 12 years, I'm referring to 10 teams in 3 different environments.

The reason you can't estimate is because your environment has not been set up for you to be able to do so. You need technical and architectural standards, an excellent team and support structure, a rock solid process that empowers you to decompose complex domains methodically and systematically, methods of implementing and addressing true domain complexity, and last and not least, the right people.

I work in digital health, we have crazy regulatory requirements and deal with super complex domains, and we consistently estimate to within 10% of our initial guestimate. These are multi-million dollar projects that run for 9-18 months to reach v1.0. They often continue well beyond this.

It's much, easier than you think. It's just that creating the environment that makes it possible is the hard part. This is about leadership and responsibility. I don't blame you for thinking it's a load of crap if you've not been empowered this way. What is sad is that it's the case more often than not, and that is not good. Not for you or your project sponsor or customer. What a shit-show.

Collapse
 
raslanove profile image
raslanove

A great leadership and an empowering environment won't make the task any less unpredictable. If it's the first time you do something, you can't put an estimate on it. Being able to make good estimates means your work isn't really creative. You can live your entire life selling the same thing, though. Which is ok by the way.

Collapse
 
quooston__be35d28bae9b9b7 profile image
Quooston

We certainly don’t do the same thing project to project, but we don’t introduce new tech or change our architectural preferences unnecessarily either. That then just leaves the domain, which is far more predictable if you can decompose it responsibly. The idea is to create an environment that eliminates most technical risk, leaving people to solve for the domain with a great process and support structure in place.

This leaves every project in an 80/20 state from really early on, where 80% is what we’re pretty certain we’ll be able to figure out without any real heavy risk. Risk is then buried in that 20%, which is what we’ll focus on very early on to identify and address. Honestly, it’s just a recipe that works and I know can be replicated anywhere. Unfortunately as I said, it’s just really rare to find environments like this. Which is nuts.

Collapse
 
curiousdev profile image
CuriousDev

I think you make it too simple. You are forgetting some reasons for doing estimations. I understand, that it can be used wrongly, but usually you want at least to get an idea of how long something will take approximately and if you are doing it good with experience it actually can be precise.
It looks like you are describing it from the perspective from a developer and even for developers estimations can be a good thing. You maybe want to know, how long a project can take or would you not care about it taking 1 month or 1 year?

Collapse
 
subhash1e profile image
Subhash Kumar

Estimation of work which you are doing for the first time leads to frustration and finally waste of time.