Why Estimates Are Waste

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?

Comment button Reply

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.

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.

Estimates ARE valuable to management. I've yet to see "agile" points used correctly to make future estimates based on previous work. Basic statistics is beyond most manager's skills. If the team did 23 points on Sprint 1 then they expect AT LEAST 23 points in Sprint 2. . .which 50% of the time that WONT be true because it is an average with a high standard deviation.

Thread

Thread

Comment button Reply

Have been working on software for 30 years

Never seen an accurate estimator/estimation

Great 3 points algorithm

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!

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.

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.

Comment button Reply

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 😛

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.

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.

Comment button Reply

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?

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.

I think this is a false dichotomy. Not all work that you can estimate can be automated.

Case in point:

If I was given a new project to work on with requirements and mockups that have been fine-tuned through deliberation, then I would immediately break down the entire project in terms of stories.

Then, I would verify the project breakdown with co-workers and get story points estimated for every story, making any adjustments as needed through this collaborative process.

By the end, I'll have an entire project represented in story points. Using either a sensible average velocity of the team on a previous project or a gut estimate of a velocity, you can pretty accurrately predict the length of a project, providing some padding for a low and high estimate.

Now, a project to, let's say, integrate a UI based on some mockups with new APIs that are being built cannot be automated--otherwise, our jobs wouldn't exist.

Is the estimate going to be perfect? Not always, but I have found the process I have described to get you very close. If it's off, was it a waste of time? By no means! We would have an accurate roadmap of the work that needs to be done, and often, the generated stories will have included valuable implementation hints/pointers by having gone through the process. It also helps set an appropriate expectation for the team even if it can flex.

Comment button Reply

In the 16 years since I started in this industry, I've only worked in one place where estimation was even slightly accurate, and that was in 2006 at a place that did Extreme Programming and used a vague notion of story points (mostly inaccurate) and "ideal hours" for tasks which tended to be more meaningful but still not very useful.

Since then, I've worked in a few teams where management thought Fibonacci points estimation was a good idea. It never was, as far as I can tell. Planning poker invariably led to long debates that were unproductive and led to tension and frustration:

Lead: Ruttiger, everyone else said 5 points and you said 8. Want to explain why, or change your estimate to agree with the others?
Ruttiger: Well, I don't really know how to do this thing, and...
Lead: We don't factor that in the estimates.
Ruttiger: Why not? Isn't that a very important factor?

T-Shirt sizing sounds more promising but I've seen it used to map each size onto a time period (say 2 days for small, 5 for medium, 10 for large) which then feeds into a Gannt chart of predicted work sequencing and targets, which is dangerous, but if your management thinks in terms of "failure to meet targets" instead of "targets were incorrect", then you have problems either way.

On teams where we did detailed estimation and sprint planning, I've tried to gently point out that I've almost never seen any team actually finish a sprint because they always feel pressured to load it with more and more tasks, making bigger commitments to avoid being seen as bad team players. This isn't their fault, but rather a natural consequence of detailed estimation and sprint planning. However I've rarely made the argument successfully and at least once suffered for trying to make the case. Sometimes there is an almost religious commitment to a particular model of "Agile" which is definitely not agile.

Speaking of the pressure to commit and deliver based on uninformed predictions, I've also spoken to good devs who got bad performance reviews from their manager because it took them 4 days to do a task that had only been estimated 1 point by the team. Imagine how unfair that would feel, and the negative effects it would have on morale and trust.

There was only one benefit I've seen from estimation, and that's simply thinking and talking about tasks with the team. Someone would often raise a really important point that saves us wasted effort later.
If teams would just spend a few minutes discussing upcoming work, looking for gotchas or proposing an approach to difficult problems, then THROW AWAY any estimates, they might get more value and less pain from the whole thing. Also, throw away your sprint board and try Kanban for the same reason. Sprints don't really work and they just lead to a regular feeling that the team has failed to meet targets.

I have a lot of problems with this.

Some not automatable work is estimatable. For example an investigation into a software behaviour. If you do it enough you can estimate it. But you can't automate it.

Another example is the research for choosing a third party library , you can estimate that but you can't automate it. Also for some work, for example adding a new report or endpoint there are many aspect of that work that are the same each time you do it, like making a test plan, writing the documentation, security testing, performance testing. There are parts of the work that have higher confidence values and can set a "minimum time" for a peice of word.

Also there is some work that's automatable but 1. It doesn't happen often enough to warrant the work. 2. It's is critical enough or risky enough that code error handling is requisite but makes the work large.

In the case of number 2. You should probably get an SOP, standard operating process , for the manual work and then consider automation.

I also think there is some valuable organizational self discovery that can happen when you make estimates. Often organizations want the value good estimates can bring but don't want to the work of managment that process. The result is just bad morale.

Olympics runners don't just run many times and record how fast they finished the race. They collect all sorts of data, they reflect, they ask questions, they experiment. Most leadership gives me "ain't no body got time for that shit" . And then try to foist blame on me about the estimate inaccuracies.

We use agile and story points in Jira but it's still not easy to have a 100% estimate on how long something will take. There could be blockers, environmental issues, colleagues who are on leave etc...

So many variables to take into account.

I can provide 100% accurate estimates, as long as I can provide them in arrears of after having done the work.

I can meet any deadline my boss sets for me, as long as the software doesn't have to work properly.

Jesting aside...

For the actual work, I look at things as "small, medium, or big". And then for the small bucket, I divvy them up as "smallest (1), smaller (2), small (3)". The medium bucket as "smaller medium (5), average medium (8), larger medium (13)". The big bucket as "big (20), bigger (40), biggest (100)".

The pseudo-fibonacci numbers in parens are what I enter for the story points in Jira. It's just used by the PM to order things when factoring in the "effort" guesstimate. The PM doesn't calculate or use velocity, but that would be another possible use case.

Can't agree more! This is what so many developers, including myself, unfortunately have to learn the hard way after years and years of practical experience when we are forced by so many dumb people flocked into this industry and forcing us to estimate the unpredictable. This is what is hardly stated in any literature but it is quite the opposite. The words of this article should be carved in stones and should be the first thing for so called "expert" to learn before they even get close to managing any software project. These words should be in the first page of all books about software technology. Actually I think there should more book written just about this topic with practical examples to make sure all of the dumb people clearly understand the concept of impossibility and wastefulness of these kind of bad practices in the industry. I have the same opinion about using so called "design patterns" as a similar dumb practice.

Agree, spending too much time in upfront estimation is waste of time, but then runtime estimation is required to be in sync with other stack holders.

Apart from some repeatable identical work, we developer have tendency to experiment with different way of implementation, trying small things to optimize better, that’s where tasks take much longer time than estimation;

In addition, technology changing every day, identical task, which used to work earlier may not work the same way in newer version for next release, that also increase the delivery time line.

As a delivery manager, we must think hard, how much time we should spend on estimation (knowing that this time will be waste at the end)

Identify the most valuable task

Ultimate value is a function of gross returns minus total costs. (Net = gross - cost)

If we have no concept of cost, how do we know what the most valuable thing is? Actually, you are estimating, you're just doing it silently; which guarantees you'll have worse estimates than an explicit estimate (which I agree with you are often terrible)

We all like to work without a rush. But every project has a budget.
If a developer is not asked about the estimation:

• the budget goes to infinity, no one didn't think about it yet, you are lucky;
• or your manager does trust the developer and knows his pace of the development;
• or your manager protects the development team from the pressure outside.

As practice shows that time&material approach is better anyway, because customers always do not know what they want. But anyway some planning is necessary (hello to Sprints).

Most of the time managers do not need the precise estimation. They are working with bigger horizon. Often rough estimations like "2 months", "this quarter" would be enough.

It is incorrect with outsourcing project