Show all posts
7 years ago

5 Reasons Why You Should Stop Estimating User Stories

1. You don't waste time on estimation

Estimation takes time. Even if you do planning poker and use story points, it still takes time. What do you do to improve estimation accuracy? You gather some data, analyze the data and discuss the results. You are spending time on all that. But are you sure that estimates really provide any value? Most likely not. It is a waste. You'd better spend this time doing something important for the product.

2. You shouldn't explain to higher managers why it took soooo loooooooong

If you don't have estimates, you can speak without fear and explain things clearly. You can enumerate problems and explain how they were resolved. You can show that you work really hard and take all the necessary actions to release this story as soon as possible with great quality.

If you have estimates, be ready to hear something like "you screwed up, maaan! You had to deliver this feature till the end of the month! What the f%$k is going on?" as an argument. The team put themselves on a weak side immediately and have to care about deadlines more, not about quality or a better solution. Is it something you really need?

3. You don't give promises that are hard to keep

You are not relying on people's optimism (which is built in). People are optimists (almost all of them) and inevitably give optimistic estimates. You can use  complex formulas or very simple rules to have better estimates, but is it really worth it? You can spend many hours defining correct formula for exactly this development team. People will not trust you, since you (rightfully) don't believe in their estimates. Numbers will look "made up" and still you will have incorrect estimates in the end.

4. You don't put additional pressure on development team

In some teams Estimate is equal to Deadline. That's bad. What do you do to meet the estimate? Compromise quality? Tolerate average architectural solution? Abandon polishing? All that leads to poor solutions that end users will not like. It is better (almost always) to spend more time, than planned, and release something really usable and useful.

5. You focus on really important things

Imagine, you have a planning poker session and estimate all stories inside an epic. You sum up all the stories and define it as a 1000 pts epic. You just stick a "fear" label on the epic. People do fear large problems. A 1000pt problem is huge and psychologically it is harder to decide "let's start it right now". Product Owner will have a temptation to implement 100 smaller user stories instead of this huge epic. However, it may be a bad decision. This epic may be really important, the morst important thing for the product.

If you don't estimate it and are not completely sure about its size, you have a better chance to actually start doing it.

  • Michael Dubakov

    @c880a7c44b6304fe5c17d063f7fc707f:disqus We work this way last 2 years.

  • Graham Ashton

    “But are you sure that estimates really provide any value? Most likely not.”

    How you approach your estimates will have an impact on the potential benefits. When I estimate stories I go to town. I think carefully about how I’ll implement them in the context of the code that has already been written. That usually requires me to open my editor and think through a possible design. I then write a few bullet points to capture the implementation I came up with, and use those bullet points to estimate the story.

    I don’t think of it as “estimating” so much as “research”. At the end of the research I just tot up the time required for each bulleted task and stick an estimate on the story. The estimating itself is quick; the real value is in the research.

    There are three clear benefits to this level of research.

    1. The entire development team is involved in the research. All developers can see which areas of the codebase people are working on; communication increases amongst the team members, initially non-verbally. They soon start chatting when they see they’re working in a similar area to another pair, or see an opportunity to help each other out.
    2. Surprises (e.g. refactorings that need doing) are discovered before the planning meeting. The team/product owner is therefore prioritising based on a more accurate representation of the time required.
    3. I agree that an estimate you have little confidence in isn’t that useful. Having put the time in to work out how complex a story is, I can be very confident in my estimates. Estimates that everybody believes in are *very* useful. As non-technical team members see developers repeatedly delivering on their estimates, the trust they have in your predictions allows the team as a whole to tackle more adventurous projects.

  • Steven

    1. Value and waste: I learned a company that tries to “eliminate time wasted” by making their toilet disgusting so that their staff won’t spend too much time inside. Your suggestion of “waste” in estimation belongs to such category of “waste”. I do recommend you reading the 7 (or 10) wastes from lean classic books.

    what I really like about planning poker session is the collaborative effort discussing what is included and what is not included in each item when we try to estimate… it is the knowledge and consensus within the team that is valuable. While you can argue that there are other ways teams can learn and make consensus, you can’t ignore the fact that estimation does generate knowledge as collaborative effort.

    2. So you think you can stop managers asking by not giving estimates? don’t you ever try to spend a minute thinking why he wants to know when certain feature is done?

    3. That’s why shorter iteration is much preferred. Making promises for 9 months is certainly hard. What about 1 week?

    4. That’s a lame excuse for delivering crappy products. Dropping scope rather dropping quality. Short iterations, in particular, challenge every teams’ technical capability. It is exactly where improvements come in. By not having a fixed time box (or deadline or whatever you like to call), you just missed an opportunity to improve

    5. a) In every proper product backlog I know of, in addition to “cost”, there is a column called “value”. It is just stupid to only look at the cost without looking into value. Good teams and PO also know that they can splitting product backlog items. The benefit of smaller items is the exponential reduce of effort required. Effort required and complexity don’t go linear. If the product owner think the Epic is really so important, she could have split the Epic into smaller items.

    Now I have better clue why electronic agile tools suck…

  • Michael Dubakov


    >what I really like about planning poker session is the collaborative effort discussing what is included and what is not included i

    Do you REALLY need to do estimate to have this discussion? We discuss EVERY user story. It is very easy to generate knowledge without estimates. 

    > So you think you can stop managers asking by not giving estimates?

    Yes, I think so. I am a manager. I stopped asking. So? 

    >That’s a lame excuse for delivering crappy products. Dropping scope rather dropping quality. 

    So you think that you CAN’T create good software without time boxes? Short iterations gives you fast feedback. That is the key. You can easily get fast feedback without iterations at all. 

    Do you think Apple estimate effort to create new product?

  • Dale King

    The agile term for this is “story grooming” and it is generally a process that is done prior to estimating. Most user stories are vague and need this kind of fleshing out to make sure the implications are understood.

  • Christian Koch

    But what about the situation: I know, that I can’t spend as much money as I want, because maybe I have an external developper working for me. I only have app. 2 million € available. How will I know if I can get a proper product within this budget, without doing a rough estimation before?

  • Janaka Abeywardhana

    I generally agree that this approach just doesn’t work for the majority. Although I completely agree that trying to estimate realistically is hard to impossible, specially with bigger projects. It’s guessing really. However without some structure and some timelines we’ll never get anything complete and we’ll be more susceptible to scope creep. I see the estimation as a process that allows/forces us to focus on what’s important.

    Whether we box ourselves in and force to deliver any old rubbish on the day is another matter, a matter of our measure of quality etc. If we don’t think it’s good enough we should be able to spend more time.

    It’s also a case of how we set expectations. We shouldn’t say we are developing a release version if we know there are many unknowns and this is a prototype.

    Ultimately what we do is hard, from developing to project management and ownership. People in the business and customers want to know when they are getting stuff, want it on time, and want it to be all shiny and perfect. We are no different when on the otherwise, just may be a little more understanding. For example: I want to know when TP3 will be out, I want to know when the list views will be available in beta.

    Time estimation is part of any process that helps us get stuff out and make it the right stuff but we shouldn’t be complete slaves to it. You need to find a balance.

  • Alejandro

    Fantastic discussion. I like the idea of No-Estimations a lot but it looks like a extreme thing from a customer point of view. I like “T-shirt” estimation style when starting a new project with a lot of unknown hard-to-estimate stuff. At the end of the first sprint we can try to find some kind of equivalence between T-Shirt sizes and hours.

  • Haya Runa


  • Haya Runa


  • Pablo Ezequiel Leone Signetti

    I don’t agree at all! The problem is when your client or product owner gets the deadline as an unchangeable truth and it’s because you committed or talked to him in those terms. Predicting means exactly that A PREDICTION… no one sees the future, we can estimate it, we can plan for it, but we will never be 100% accurate. Understanding this fact is key to this type of process! If the client committed to a deadline of a 6-week project and your team worked 8 weeks, it’s not your problem, it’s your clients’ problem!
    Putting pressure on the team is a bad thing, having some pressure is not bad, but risking the job, salary or health is not fair!
    The truth is that no client will pay you for your words, no one will trust you blindly, they need dates, commitments, and don’t forget that you are also a client and when you want a new kitchen, you ask WHEN WILL IT BE READY?? you become a client!
    I think we need to redefine the wording or change its meaning when referring to estimations, scrum, etc…. these are tools to improve our job and give a nice experience to our clients, but it cannot be taken as a truth or completely outside of real life… we are people, we do mistakes, things happen and death is the only thing that cannot be solved!! 🙂