Apr 04

The myth of estimation

product-in-a-boxOne of the trickiest parts in Scrum is estimating the entire Product Backlog. Often I’m asked to do this or to help Product Owners to do so. In almost every case management, the CEO or the customer demands it. Why would they want this? They want to know when everything is finished. And by estimating the entire backlog you can make a simple calculation. Divide the number of work items, or points or whatever by the velocity of the team or by what is already delivered and you end up knowing how many sprints it takes. Seems very simple. This is also why there is something like a Release burn down. Right?

Wrong! If you read about Scrum you will find out that is has to do with continues integration. Building increments of software per sprint. And most important, develop what is needed most and deliver this as fast as you can to get optimum value. So Scrum is not designed to deliver the software projects where a sales person agreed upon the total amount of cost and the deadline. What happens is that these projects are chopped up in little parts and every part is done within a sprint with a delivery at the end of the project. So you get, waterfall or water-scrum. No wonder that stakeholders want to know when it is done en demand the product backlog to be estimated so they can feel save and happy again.

The fundamental problem with wanting to know when it is finished is that if you have that “when is it done” question, software is still seen as a product. As something you can ship in a little box. As something you can save on a floppy. But software is not a product. Software is a service, something you provide to a customer, and if you have a great customer you may do this for a long time. It is a complex system that keeps improving and growing over times. It keeps developing. You never really finish it. And if you can accept this, then what’s the point in looking for the end. There is none. And if there is no end, there is no way you ever going to be able to estimate the whole.

Nowadays DevOps is very popular. It is used very often to sell a product. Sales and account managers use the word quit often and out of context. Yes we are going to deliver you product with DevOps and it will be delivered at you demanded date within the agreed budget. You just can’t. Not even with DevOps.

So lets return to estimating the entire product Backlog. It is a myth. It is a story told to people who did not do their homework. You can do some estimating but it will stay be nothing more then a gut feeling. You will never get the exact estimated and when you think you do you miss the entire point about Scrum, continues integration, bringing value and quality. You are still doing projects in a sequential design process (waterfall). You still hold-on to the thinking within the (software in) a box.

Once you start with focusing on what is needed at the now point in time, you might take the fist step in really understanding what Scrum is all about. It is simply about delivering the most important stuff first and with the highest value and quality. And it’s not about getting to the finish line and already knows what your end time will be. Or playing a game and knowing what the score will be. Hell, if it would be that simple, I would be rich by now.

Permanente koppeling naar dit artikel: http://agilethings.nl/the-myth-estimation/

  • Pingback: The myth of estimation - Agile things | Be Agil...()

  • ComputerGeezer

    But what if I am a customer who actually wants some software with some capability? What if I am not actually willing to sign up for an infinite delivery cost?
    Does this mean that agile methods are useless to me? That seems to be your point here.

    • No. It just a simple question of what is the minimum that you need. Stop thinking that software is a product you buy and start thinking that it is a service that you get. Small and fast delivery of the thing you need so you can start using it as fast as possible and build upon that. It’s not about budget but about value.