Show all posts
4 years ago

Why Agile Estimates Don’t Work – Part 1

As you read this headline, many things came to your mind, probably. You might have recalled those many hours of meetings as you tried to come up with a time estimate for a project or for a product release. Or, you might have remembered the planning poker sessions, which were intended as a spot-on pragmatic business activity, but in the long run proved to be nothing else than a child's game, because the estimates attained as a result of planning poker sessions differed 2 or 3 times from what the actual work really took. The sharp question that I want to ask is: how many times did you feel deep inside that when they make you do an estimate (them being managers, or clients, or anyone else in charge), you end up with nothing else but a waste of time, because later in the project you still face the need to explain why your initial estimate proved to be that different from how things actually turned out, and feeling guilty in the process, though probably nothing of it was actually your fault?

Don't get me wrong. My initial intent was pure and well-behaved. I humbly wanted to write an article to sum up techniques for estimation used in agile, describe their pros and cons, and provide people with a single-point reference for all those techniques. However, as I went deeper into the research,  I was astounded. It turned out that there are many more articles and write-ups out there in orthodox agile circles on "How to estimate?" as opposed to "Why estimate at all?" In those few cases, where I saw some attempts at explaining "why?", they stroke me as incongruent and built on some very loose logic. This very fact of the looseness of "why?" puts a big question mark on the validity of the "hows", because the "how" is a product of "why?" or "what?' I've cited this in one of my previous articles, and I'll repeat it one more time, because this axiom is universal, and works for all things life and project management alike: The hows will appear if the what becomes clear.

Let's take the scalpel of pragmatism and dissect the faulty logic behind all things agile estimates.

What is an estimate?

Is it a measure of commitment? Or is it a lazy talk? I tried to find some stats on the actual usefulness of the estimates in story points, and how they've proven themselves valid in the bottomline world of business. I found none. From my own experience, I know that estimates never work. I've seen this in project-by-project software development and in product development. A slightly modified quote from here:

It's impossible to estimate something that is being built for the first time.

We never build the same feature twice.

The only viable example of valid use of estimates that comes to my mind goes as far back as to the early 2000's, when people wanted simple e-commerce web-sites, or dating sites, or something of that kind. Having built a handful of such web-sites, software vendors were more likely to give their clients a realistic estimate of completion, because these web-sites didn't have a heavy baggage of residual debris, such as technical debt, bulky databases, or an octopus-like architecture, which just spreads, rendering futile any attempts to commit to the bottomline "get the sh..t done on time" stuff.

Next, if any attempts at estimating are futile, then why do most companies continue to play this game, which resembles courting, but unlike courting promises no pleasure ahead, only the ever increasing snowball of mess, feeling guilty, unproductive and unaligned with the only goal that matters: get the job done well and on time?


Stay tuned for the answers and even sharper disclosures in the upcoming part 2 of this article.

Related articles:

5 Reasons Why You Should Stop Estimating User Stories

Joy Spring and Estimated Deadlines

2 Meta-Principles for User Interface Writing

UX: Why User Vision Design Matters

Why Agile Estimates Don't Work - Part 2

  • Ole Fritz

    This article feels to be black and white. There are situations where estimates work and make sense. E.g. IT agencies creating similar features for customer websites over and over again. The feature package
    might differ from project to project, but often the same features are implemented a couple of times.

    Furthermore I think you are writing about the less important point of view regarding User Story
    Estimation. Estimation is not about giving a commitment to any stakeholder. It is ment to foster discussion about how a feature can/will be implemented. Think of a bunch of developers estimating a User Story. You might end up with completly different estimates, because every developer might implement it differently. Maybe one of them knows a short cut, another one knows some pitfalls. Developers sitting around
    a roundtable to streamline their thoughts about the way to implement a User Story is a good idea and User Story Estimation is an excellent toolfor this.

    Last but not least I think it helps developers to keep on track. When they decide to estimate a User Story with 5 points, they already had a rough idea in mind how to implement it. If the developer who implements it then struggels during implementation, he should consider asking his colleagues to help him instead of fiddeling around and making it much more complex then it might be.

    So, from my point of view estimation is a good to tool share knowledge and create a rough plan about the implementation. It already gives you an idication where we have complex, maybe critical, features that we should have a look at. You can already think about doing spikes. I know it can work, when it’s done right.

  • indigo777

    Ole, Part 2 is coming soon 🙂 thanks for posting your thoughts 🙂

  • Oden Hughes

    Coming from an environment where estimates are almost always accurate (we average 90%), I’m struggling to understand how anyone could have an issue with this process. Could you give more specifics on the environment and the techniques used? We do relative estimation at the user story, use a standard velocity to release plan what will fit into iterations and then task plan during iteration planning to make sure we got the estimate right.
    Granted when we started using Agile two years ago it was a 50/50 shot if we delivered on time but now it’s rare that we don’t.

  • indigo777

    Oden, before I answer, could you share the specifics of your environment? How often to you release? Which projects/software you develop? Are there any legacy issues, or performance issues? Technical debt? Other factors that add un-predictability to estimates? If that’s a volatile environment, do you think you’d be able to keep your estimates 90% accurate?

  • Oden Hughes

    Our environment is fairly complicated; we build everything from web sites to data warehouses, we release anywhere from 1-3 (3 week) iterations on projects that run anywhere from 1-10 iterations in total project length, we also support every single product we release (and own products that are more than 10 years old) more than 100 in total each with varying degrees of technical debt. Any given iteration could contain work on up to 10 projects, we regularly are asked to shift resources to new projects mid iteration, have to work with resource groups (systems, testing, product owners) that aren’t always responsive and our planned iteration task count is always dwarfed by the unplanned one.

  • Gabriel Roncancio Reyes

    Oden, I believe there might be differences between the projects Olga and you are talking about. I have worked both in BI/DW projects as well as in product-development ones and I have found it easier to get estimates right on the earlier (However, I’m not sure the actual reason behind this). You might find interesting this other blog post that makes some hypothesis about the reasons why sw estimation (I believe it might be reduced to product-development or certain projects) could be an impossible task:

  • Ebenezer Ikonne

    Hi @Oden – what is your estimation method? sounds like your longest “project” would be about 8 months? is that correct? with the web sites, are these different types of websites for different domains.


  • Oden Hughes

    We use standard planning poker w/analogy for estimation, nothing fancy there. Our longest project is at 3 years now, but I’d say the average falls somewhere around 6 months. Our website development typically is stand alone sites with different customers/usage/infrastructure, we do have a few that are regularly updated but most of that is handled w/only a few stories and an iteration or less of work.

  • Oden Hughes

    I’d agree that BI/DW projects are different in that your acceptance criteria is typically very clear – the numbers tie or they don’t. However, in our environment our source systems are not what I’d consider clean so those project are more likely to be incorrectly estimated than others. In fact the only estimates we got wrong in our last six iterations were BI/DW related, data issues mostly. Our other projects (and fortunately the majority) tend to be easier to estimate accurately, especially when they involve our better product owners.
    Re the link you mentioned – I agree with that completely. When we started Agile we averaged about 30% accuracy mostly due to optimistic estimating. Most people do plan in ideal time, don’t take into consideration the unknown, and also don’t plan for issues. Over time we’ve looked at each incorrect estimate, talked through causes and brainstormed solutions to incorporate into the next iteration.
    I’ve found with the other teams I’ve helped transition to Agile that they follow a similar pattern. Perhaps because estimation is so subjective in nature, it just takes time to get the right mix of supporting processes and skills?

  • Daniel

    “In our team we had very long conversations about the complexity of user stories still final estimates seemed quite arbitrary. We tried different things to improve, Planning Poker worked us the best.

    In the end we built a tool, Scrum Poker for JIRA. Poker cards for estimation in iOS and Android apps, points saved to JIRA. Free to try. Would love to hear your feedback.


  • Daniel

    “In our team we had very long conversations about the complexity of user stories still final estimates seemed quite arbitrary. We tried different things to improve, Planning Poker worked us the best.

    In the end we built a tool, Scrum Poker for JIRA. Poker cards for estimation in iOS and Android apps, points saved to JIRA. Free to try. Would love to hear your feedback.