Agile Estimation is Dead – Stop Estimating Stories?

I’ve been reading a lot lately about “not estimating stories in Agile…” or “why you should stop estimating all together.” – To be frank, I’m not quite convinced, holistically. I believe that there is significant value in estimating at some level, just not spending too much time doing it.

Accuracy over Effort

There is some value in spending just enough time doing estimation, but not spending so much time that it doesn’t amount to anything.

In my depiction of accuracy over effort here I say that find a healthy balance between just enough time, and getting some estimation done. Now, some would say: “The trick is to consistently estimate over time…” Maybe it’s more like: “Consistently estimate wrong.”

Michael Dubakov tells us 5 Reasons why we should stop estimating:

  1. You don’t waste time on estimation – It is waste of time.
  2. You shouldn’t explain to higher managers why it took so long – Focusing more on explaining the problems than measuring against an estimate… and you don’t need to explain anything more than just how you can resolve the issues.
  3. You don’t give promises that are hard to keep – People don’t believe your estimates anyways. Better not be accountable lest you have to explain yourself.
  4. You don’t put additional pressure on development team – Estimates = A deadline. You wouldn’t want that would you?
  5. You focus on really important things – Epic or not, size or not. Doesn’t matter. By not estimating you can focus on… whatever is most important (according to the Product Owner).

Do I sound facetious? I’m simply distilling what I see as his argument for not estimating. 

Cory Foy tells us that story points are dead and that in reality…

Cycle time (Kanban metric) is far better with a filter of Classes of Service (David J. Anderson concept):

  1. Rather than add up the story points completed during the sprint, they measure the cycle time of the stories. The Cycle Time is the amount of time that it takes for a story to go from initially being worked on through shipped.
  2. Classes of service are a recognition that all work is not the same, and should likely not be treated the same.
  3. What does this all mean? – Rather than estimate points, follow story completion from beginning to end and give yourself some slack in regards to types of stories. This will, hopefully help you better track and forecast out release times.

Mike Cottmeyer tells us that we may be looking at estimating all wrong…

We really should be (maybe) using estimation as a way to cut out pieces of unnecessary work:

  1. I find myself using estimation to help teams figure out what we are NOT going to build. Rather than create an IN list… I like to think about creating an OUT list.
  2. Ever though about using estimation as a way of committing to what we AREN’T going to do?
  3. So what does this all mean? – Maybe we should look at estimation as a way to filter out that which provides little value. Focus on the 1’s and 2’s.

So what next? Is Agile estimation dead? Where do we go from here?

[HT: Target Process, CoryFoy, Leading Agile]

31 Replies to “Agile Estimation is Dead – Stop Estimating Stories?”

  1. Interesting. I dont think estimation will completely go away as long as there are planning, resource management and budgeting that happens. After all these are estimations. The gap really comes in where we do nothing with the estimation and actuals. We need to be able to learn and use that knowledge in planning for future projects or releases.

  2. A fourth opinion;

    Estimates for stories are normalised over time, so if you keep teams together you can estimate releases (on average) simply through counting the number of requirements you want fulfilled.

    Stories have an average size and once established you use the average for all estimations and wear the occasional variance.

    1. I believe the best benefit (since estimates are relative to the teams) is that they can provide some sort of consistency to output, or as you said, normalized over time. Now… what you do with those estimates… that’s another question

  3. I agree that minimal estimation helps figure out what to do or what won’t be done. That is another way to say: clarify the stories we are about to start. Whatever is required to let the team understand the needs is good for the project.

    Although, I’m against the idea of a strict commitment toward estimate. Although I think we need to have the team to commit do do his best and that is more easy when a goal is settle.

    Some pressure is good, but stress and accountability on unfair metrics aren’t.

  4. Nice write up. I have been doing this business both for Govt and Commercial Clients for a long time and I have seen an accurate estimate. Like most of us here, no matter what tool we use, its never correct. Especially if you have clients that want to lock in planning and estimates up from without giving you the opportunity to adjust as you learn more. I like the idea of estimating for complexity and then deciding what can be done based on complexity or ambiguity vs give me a estimate of costs, schedule and oh yea, put this all in a RFP. Then having to live by it. Naw, estimates are overrated in SWE. Its not like getting an estimate on a car repair or building a bridge.


  5. One problem with estimate is the psychological part of it. If you come up with an estimate for a week, that’s what all will remember. If you say that we estimate this set of features will be ready about wk37, everyone will remember wk37. Maybe it would be better to say, we estimate it to be ready somewhere between wk36-40 for example.

    Sure there’s always going to be timelines to follow. There’s market windows for products or some other deadlines SW needs to follow. There just needs to be enough flexibility on content and timeline in order to estimates to make sense.

    1. That’s what we’ve been doing lately and it is much better. Budget forecasts have been in ranges for a long time here so it made sense. The business accepts ranges and our accuracy has increased significantly. 🙂

  6. Good post. I have also been reading a lot lately about not estimating….we must have same RSS feeds 🙂

    I coach teams not to spend too much time estimating, just enough to get a reasonable sizing. But what I find beneficial is that when teams try to estimate something it brings out a lot of hidden assumptions and conversations about what the story is. The team may have discussed the story several times before, but when you get them to estimate, I have found people ask different questions which illuminate the story more. It is this conversation that is more important to the team than the number (estimate) itself.

    1. Great response Chris…I think we share RSS feeds too 😉

      I always see such conversations focusing in on the “process and tools” side of whether story point estimation is good or not, when -as you point out- it’s about the “individuals or interactions” side of it.

  7. As a product owner, I definitely have a problem with the statement that not estimating allows you to focus on what is really important. Everything is only important to a certain point. For example, lets say you really need a car. You aren’t just going to go buy the first car you find are you? You probably have some point at which the cost isn’t worth it. You’ll decide to take the bus instead. If I need a car to get to work and I make $500/month but the car is going to cost $700/month, it doesn’t make sense. The same holds true for features. Features have a value to them (albeit very difficult to actually calculate to a real dollar number) so if the cost (estimate) is much greater than the value, I, as a product owner, can save us all a lot of time and say never mind. Without estimates I can’t do that.

      1. I understand as an product owner, one needs some sort of cost and time/schedule estimates. But how accurate can these estimates really be. I have never seen an accurate estimate from any SWE team. Unless you take an approach like Steve McConnell suggested in his wonderful book “Software Estimation” that there cannot be one estimate but several as the team gets closer and closer to done vs tell me all the cost upfront. I don’t think that can be done at any level of accuracy. This is why IMHO Sprints and points within sprints are the best approach.

        1. I don’t know how you get estimating stories equating to having a time / schedule estimate. A Product Owners needs to understand a) what stories are the riskiest and their associated estimate to complete b) what stories are big and unimportant. Those things alone allow the Product Owner to determine what happens in which sprints, to ensure the most important features are always being completed first. Estimations I agree don’t need to be elaborate, but they are a pivot for determining the priority of features. They inform any decision a product owner would use to order the backlog & release plan.

          @Gary – I want to vomit when you say you’ve never seen a SWE team accurately estimate. You must not be working with mature SWE teams, because this is the stuff the teams I work with take pride in. They want to be accurate, they want to built elegant solutions, and see their task breakdown in actual dev line up with their initial estimates months before hand.

  8. Pingback: New PM Articles for the Week of June 20 –26 « The Practicing IT Project Manager
  9. What I implemented at my last place was that we really estimate stories very quickly, literally in 5 mins and that estimate was in days so a developer and tester together might say, yeah thats about a day so we give it 1 point.
    Next we recorded how long we spent on it, it turned out 1 pointers took about 1.4 days, we recorded the time for all stories over time so we had a very good average of how long a story sized out a certain point size actually took.
    We were then able to say at a very high level how many points we could take in depending on days, personally I was moving us to a more Kanban style anyway but we had to report things to the business as well (only dev & qa were Agile) but we could then pull out some metrics giving an estimate of points per week, per developer etc which gave us a nice idea of if we employed a couple more people that over time we would get x amount of points extra, obviously this only works to a certain point, you cant add 500 developers and expect it to keep adding the time but as I said we were able to use it to give a business case to add 1-2 developers or QA.

      1. to be honest it was a bit of a hack version of Kanban and far from what I would have decided on using if it was totally up to me, I was only in charge of QA and had to push the dev manager a bit to not just be there to please the Sales Managers.

        I cant think of more now without a huge amount of writing but I will say it started to work really well in the fact that the sales team were happy with an estimate that was high level if they could then see what the average was, ok they probably took the average as a given but as we were still doing sprints it worked out pretty well as some things in that sprint took longer and some not so long, so again it actually worked, there were things I would have looked into more over time but left before then.
        I will say I am now a huge advocate of:
        * Estimate at a high level
        * Record how long it took you
        * use that average record to estimate how much work you can take in in the future

        I also think estimating as a man day works really well as I have found developers often find it a lot easier to make a guess at how long they thing it will take rather than how well it matches to a previous Point, using the system of 1 point is 1 day but on average thats actually 1.5 days worked really well.

  10. Pingback: Agile Estimation is Dead – Stop Estimating... | Agile | Syngu
  11. As soon as we answer the question: why do we need to estimate? It gives a different perspective all-together. Estimating helps to plan, size, calculate ROI/IRR etc etc, to determine which piece of work can be done earlier or later, or do we really have to initiate project at all.

    At later stage, estimate helps in tracking the progress. Once team know its velocity, they able to commit to work and plan it accordingly.
    Cycle time or story point does not really matter as it is team own choice and team can adjust/adopt according to their maturity level.

    In conclusion, we can’t get rid of estimation but adjust our efforts to hit the sweet spot.

  12. not to forget, Agile is empirical process where you should explore and refine through retrospectives what best fits your organization.

Leave a Reply