To guess or not to guess – my opinion on ‘No estimates’

Regardless of whether it is about the timely completion of a software project or about the costs, there are many situations in which estimates are given. However, my conclusion will remain the same: I believe we should not base the decisions we make in software projects on estimates. I'll explain what alternatives we have.

Will we deliver on time?

This is one of the key questions that a development team is always asked at the beginning and during a project. And it is the main reason why many people believe they have to estimate. What is questionable about this is that we aim to get a reliable prediction by making estimates based on guesswork. We all know, or at least we suspect, that these figures are usually freely made up. At best, they are based on experience with projects that are similar but never identical. Usually, the fact is that we do not yet know or understand the solution. We try to reassure ourselves by calling our estimates ‘educated guesses’ or ‘quick and dirty’ just to be able to justify making important decisions based on guesses.

By its very nature, software development is unpredictable and non-repetitive. When we develop software, we cannot just break the work down into the same repetitive units like when we assemble a chair. Unlike the chair, we do not know precisely what software product we will end up with until we have built it. One software production part is not identical to the next one. Software development is a creative, variable process and solutions often only reveal themselves during the development. This also makes it very difficult to determine the scope of a development project with precision. If we accept that the scope must be variable in order to accommodate ‘emergent design’ and changing requirements, then we must also accept that the delivery date is a variable that we try to achieve while delivering the known scope ‘on time’ and ‘on budget’.

If ‘on time’ and ‘on budget’ are usually based on estimates of how long it will take and what it will probably cost to implement a certain set of requirements and there are no hard time or cost constraints, then it must also be ok that it might take us longer to develop the software than we originally estimated. But we could also be faster. Or, we might be just as fast as we estimated.

Ultimately, however, we must ask ourselves whether the correctness of our estimate was really relevant. Does our estimate have any impact, positive or negative, on the quality of the development or its ROI?

Vision is crucial

To develop software, we need a clear vision and a common understanding of what success should look like. When we start a software project, we first need well thought-out high-level goals, not the details of how to achieve these goals. In a classic iterative approach, we can then make our ‘just-in-time’ decisions on how to improve our product in the next iteration (backlog grooming).

I now suggest that trying to predict, based on estimates, how long it will take to develop software to achieve these high-level goals is a questionable approach. We want our solutions and architecture to emerge during development. We want to be able to make changes to the requirements in order to offer customers an advantage as a product evolves. You cannot, by definition, fix this flexibility in advance. These are key elements of the Agile Manifesto, and I believe they are crucial for achieving a truly agile approach to software development.

Remove the unknowns

Instead of relying on the accuracy of estimates for our predictions, we can also try to eliminate the unknown ‘costs’ and ‘due date’ by making them explicit. For example, the product owner can set the due date based on a specific budgetary constraint or time limit (three days before Christmas for a Christmas app is a specific time limit as well as ‘We have $50,000. Let's use this to get the best possible result’).

The team can then define delivery times within these boundaries (for example, at the end of a sprint). This achieves the necessary focus on iterative product development and, at the same time, makes it possible to deliver earlier and/or cheaper. This approach is also useful when there are no specific budgetary constraints or time limits. Here, the need for explicitly specified intermediate releases decreases the more mature a team is in dealing with continuous delivery methods.

Estimating ‘sprint velocity’ is a waste

Predefining a solution at the beginning (that is necessary to give an estimate of the duration) or predicting for each sprint how many story points or stories will be completed seems to me to make little sense. Teams should simply commit to developing the best possible product within a given time and budget. When we estimate and use the ‘velocity’ for planning, we make an assumption about how much we can accomplish within a given period. For this information to be useful, we must already know what we want to create overall (that is, have a fully estimated product backlog). I do not think it is too far-fetched to suggest that all the time spent estimating backlog items that are not developed can be considered a ‘waste’ in terms of lean development.

But what about the time that is used to estimate backlog items that are actually being developed? To answer this question, I need to ask another question: Have you come across a product owner who has ever prioritised one story over another because of lower story points (estimated costs)? If your answer to this question is ‘no’, then I conclude that all estimating in this context was ‘waste’. This is because no decision was made based on the estimate (instead, the PO simply prioritised the story with the highest benefit).

However, if the answer is ‘yes’, then cost estimates have been used as the basis for decisions that should actually be made based on benefits. Estimating the backlog in advance and then planning the delivery time based on the ‘velocity’ is a cost-based approach.

Try – do not guess

I believe that iterative (agile) development is based on decisions regarding customer/business benefits that put empiricism above estimates. The costs in such a scenario should be fixed by keeping a team constant and making the time frame (frequent, predictable delivery points instead of ‘deadlines’) explicit. Knowing our costs and delivery times gives us certainty, which allows us to have room for an agile mindset during development. By the way, just because we have a fixed delivery time, this does not mean that we stop developing our product at this point. We may be finished at this point or we may decide to continue working. All that matters is that we continually make go/no-go decisions based on the realised or potential benefits of what we are building and not on the estimated costs of a specific solution.

The number of stories or points that is delivered per sprint becomes truly unimportant if the team is able to deliver product advancements and improvements to the user as quickly as possible. In my view, this is the reason why software projects and entire companies try to exhibit an agile mindset.

However, as long as we continue to feel compelled to estimate, we will probably always be held back a little in our quest to deliver truly outstanding software to the customer.