Development Process: Estimation is futile


How much time do you invest in estimating your backlog? Do you really get any value from it? When was the last time you thought about the value it provides you? I can see as a source of problems in many ways.

Management T-shirt

Management T-shirt

Estimation as a punishment tool

In many companies, estimation is only useful for management to make them believe they have their subordinates under control. “You told me it was going to be done by Friday, why it’s not ready yet?”. The estimation becomes a tool to punish developers when they do not meet it. This is a powerful tool used by management is a double-edged sword. They give you freedom to estimate, but they punish you if you don’t make it. When an estimation is given, it’s like signing a contract with the devil and there is no escape. The first number thrown at the air will become a hard deadline, were there is no other choice than making it. The development team starts over-estimating tasks, to cover themselves. When they know they have spare time, they relax and waste it. Then, they realize it’s too late, and they have to run against any odds to make it. The dev team over-estimates because they do not trust management to adapt when there are problems. Management doesn’t trust developers, because they always over-estimate and waste precious time. This creates an environment where there is no trust, and both management and the dev team get the worst of each.



Useless estimations

Management asks the dev team to estimate tasks before starting with a project. Once everything is estimated in 6 months 25 days and 8 hours and 29 minutes, management comes back and let everybody know the due date for the project is in two months. Suddenly the whole estimation is useless and it was just a waste of time. Not only that, now the dev team knows it’s impossible, and everybody just dedicates all efforts to cut corners. In particular, testing, documentation and all those useless task dev teams put in their estimations, will be the first thing that will not get done. Not only the estimation was just a waste of time, but it also makes clear how important it was for management. Another type of useless estimations is when nobody has a clue about how long it would take to accomplish the task. Then a really high or low number is thrown just to comply with the process. It disrupt metrics and do not provide value.

Planning Poker

Planning Poker


In Scrum or XP, estimations plays a different role than more traditional approaches. They are used to manage how much work is put in an iteration. It’s a way not only to control the Work in Progress for a period, but also plays a role in terms of release planning. Unless you are working in a really stable environment, estimating task to hours or days doesn’t provide any value. Usually agile teams take a more pragmatic approach for estimations. The use of story points, effort points, complexity points, etc. is very common. The points are used mostly to compare sizes of tasks with other tasks they already did. A common practice it to use planning poker which is a fun way to seek agreement within the team.  That way the estimation provides a way to find out how much a team is able to deliver in a particular time frame. Of course this is not always exact, but  in agile approaches there are mechanisms where the team can discuss with the customer and come to an agreement. In some pseudo-agile places, they follow the whole agile mechanism, but whenever there is a problem, management expects to have everything done by the end of the iteration. They either get everything or the commitment of the team is in jeopardy. Agile estimations work great in agile cultures. Whenever you work with fixed length iterations, you are forced to estimate in some form.



Is no estimation possible?

Kanban introduces so few restrictions which makes task estimation optional. Working with unpredictable tasks, sometimes it’s better just not wasting time on estimating them upfront. Working with the latest technologies or on unknown fields, innovation will likely make things unpredictable. To solve this problem, you can take a more pragmatic approach than the agile way. Kanban doesn’t use estimations to limit WIP, that’s why for Kanban estimations are optional, while in an iteration based process it’s a must. The basic idea is to measure the lead time. An average lead time is used as the initial estimation. This gives a sense of how long it will take to solve it. It’s not a contract, still if there are hard deadlines for tasks, they should be properly noted and prioritized accordingly. Everybody feels comfortable considering the lead time as the initial estimation. The team knows whenever they work on a task, if they realize it will impact a delivery or hard date, they should raise the problem as soon as possible so it gets addressed. This has many implications in the way things are organized, in particular, complete trustfulness is implicit for this to work. So no estimation is possible, in particular when estimation doesn’t provide you any value. Revisit how much value estimations provide you in your environment, and if they are worth the investment. We found that in most cases they didn’t provide enough value to us.

We'd love to hear your opinion on this post

13 Responses to “Development Process: Estimation is futile”

  1. Hi Ramiro,

    I completely agree with you about the frustrations of a developer who do estimations only to find out later the same going against them. Most often than not, the estimations are done based on a certain amount of information, which would likely change by the time the actual work starts.

    When we need to do estimations, I always ask my team to define the assumptions first, based on which the estimations are going to be done. One assumption, which is obvious but should be stated upfront is that if any of these assumptions change it will affect the estimations.

    So there you go, use the assumptions as an insurance against the changing environment, the limited information and the other unknown parameters while estimating.


    Varun Narula

  2. Trying to imagine myself, 5 years ago when I was working as a consultant, explaining the customer but mainly the sales guy of my own company, that I was not able to provide an ETA. Unfortunately estimates have different meanings for managers, customers and the dev team:
    For the dev team is the time they will be able to finish the project and leave on vacations, for managers the moment they will be able to cash the project and keep the cashflow sane (and also be able to pay the dev team before they leave on vacations) and the customer uses the project duration to compare suppliers (knowing the cost per unit of time), to apply fines and many other reasons.

    At the end, estimating or not, things get done when they get done. Pressure nor due dates never helped me to avoid unexpected bugs, lack of response of the customers or making me a better and faster coder.

  3. I’m glad to see it casues people questioning themselves.
    No estimation, doesn’t mean you are not able to calculate an ETA. It means you trust your team, provider and management will do what it needs to be done. It means you trust they will do the right thing. It also means you are ok with having the lead time as the initial estimation for your tasks.

    If there are things you know will take longer, or you need to have a better estimate, Kanban doesn’t prevent you from doing it. Actually it encourage you, as there are 2 main goal. Reduce the lead time, and reduce the sources of invariability. Long term tasks are a source of invariability, therefore, it’s better to estimate and try to break them if possible.

    Using estimates to compare suppliers is proven that it will cause more problems to solutions. All your suppliers will try to reduce the cost at maximum to be competitive. Imagine what somebody who doesn’t know your business will cut? right, the things you probably care the most.

    As you mention in your comment, pressure and hard due dates are bad, they do not help you to improve. Only through improvement you will avoid unexpected bugs and make better and faster code. Also it should help you to mitigate that lack of response from your clients.

  4. Hi Varun,
    Thanks for the comment. I think it’s great to use the assumptions, as they are a way to cover yourself when estimating. Still, I see that as there is no full trust in the team. How often do the assumptions change? are the estimates accurate? I know it’s hard to generate a place where people can be trusted. Knowing people made estimates based on assumptions has to be implicit. I understand in many environments, where politics and power make people trying to eat you if you make any mistake. So in those environments, wasting a lot of time and effort covering your back is a good investment.

  5. Good to see you writing again Ramiro!

    I kind of agree with you, but not quite.
    I do think estimations are useless if you use them to negotiate deadlines with your customers, or worse, when the negotiation takes place between management and developers (if you get to that point all is lost!). I liked what you said about trust, I too think it’s essential to make a team work. Estimations shouldn’t be used as a weapon to control developers work, as assumptions should not be used by developers as a weapon to cover their asses.

    But I believe estimations add lots of value to team (whole team, not sales vs management vs developers); just breaking up the work in tasks small enough so you can estimate them goes a long way, even if you don’t actually estimate them! During the estimation a lot of questions are going to come up, and questions are good, they help you understand better the problem at hand.

    Also, I, as a developer, have learnt a lot from estimations. If you feel you missed an estimation by much (under or over it) you just need to ask yourself why you think that happened. Maybe you didn’t realize there were other sub tasks you should have taken into account, maybe you didn’t asked enough questions to fully understand the task, or maybe you just couldn’t really estimate the task as there were too many invariants. The point is to learn from your mistakes.

    As long as you don’t feel slave to your estimations, you’re gonna be just fine 😉

  6. Great to hear from you Mariano.

    It’s good to see how the title conditions the reading of the post. I’m not saying all estimations are useless. I know in some cases estimations actually give a lot of value. They help on settling things down, defining them better, and help to spread the knowledge among the team. Those are just some of the benefits they provide. I’m trying to push people to think if something as mechanic or granted as estimations is something that actually gives you any value. Do not estimate because the methodology you are using commonly has estimation involved or the tool you use only allow you to put hours as estimates. Sometimes people just do things because the one that was before used to do them. Questioning why you do things helps you to get better insights on why you do those things.

  7. Strangely I find myself agreeing with you again, hehe 🙂

  8. Hi Ramiro,

    On your question on the how often would assumptions and hence estimates change, it would depend on the amount of available information at the time of estimating. Sometimes the requirements are at a high level, closer to a wish list. In such cases, assumptions play an important role as they define a boundary in which the estimations would be viable.

    If however, sufficient details are available to do estimations, then assumptions will add little value. I nonetheless, always would include assumptions like, a resource with a certain skill set is available, the project starts on time, force majeure, etc. etc.


  9. Hi Ramiro, nice article. I like the planning poker part. I really want to try that out.


  10. HI Varun,
    Thanks for commenting again, I think all comments provide more value and more insights to a single idea. I think the assumptions in your case, help you to define better the project, when there is a lot of uncertainty, I think it’s a great thing to do. It could be good to organize a meeting, where you can talk about the future requirements with the team. You have the chance to gather assumptions on how the team can make things work, and also allow them to see upfront what’s coming. That way you get the same value from your current estimation process, but without setting deadlines. Look at how much value the actual estimation in hours or story points give you, and if you could live without those numbers without sacrificing things that are important to you.

  11. Hi Ross, great to know you like it.
    Planning Poker is a really good tool. In particular because it searches for consensus in the team. As I’m used to say, when estimating relative tasks (story points, effort points, etc), consensus is what gives the estimations value. Without consensus, the estimation is useless. This doesn’t mean the estimation process does not provide value.

    Good luck with it!, and contact me if you have doubts about it.

  12. […] See also: Estimations are futile by Ramiro […]

  13. Hi Romiro,
    I completely agree that usually estimations are treated like commitments. This should not happen the way, so blame it on the managers who use them like a decisions. Every estimation supposes a probability. You can work over a project 1 year and are going to complete it tomorrow, but it is always just your expectation, not a reality. So there is a chance that you will complete it tomorrow, may be 99%, may be 99.99%, but never 100%.

    To avoid this need to get an agreement first, that estimations are provided like an arguments for taking or not taking a decision. Good manager should understand it.