#NoEstimates - Alternative to Estimate-Driven Software Development

Henri Karhatsu, @karhatsu, http://blog.karhatsu.com

Our software development industry is estimate-driven. That can be seen in many levels. But are there really any alternatives? Is estimating necessary in software development? This article answers these questions by explaining what is #NoEstimates and by exploring some of the alternatives that we have to estimates.

Mainstream Agile

Agile has clearly become mainstream. It's difficult to find a company that does not either do or pretend to be doing Agile software development. But at the same time it seems to me that many of the companies still miss the essence of Agile. I can see this happening in at least two ways.

First, I too often see Agile teams that never have retrospectives or anything similar. The team members occasionally do talk about the problems they have in their work, but they do not actively try to track reasons for problems and to solve them. As a result, they keep having the same problems every week. Then, I hear comments like "we are having this demo because we follow Agile rules". People in Agile do things ritually because they have decided to do Agile, not necessarily understanding why that ritual might be valuable.

The lack of continuous improvement is the common factor for both issues. Stepping into the world of Agile might quickly bring some nice benefits, but the point of Agile is not just to take some Agile tools into use and to stop there. In my opinion, the most important thing in Agile software development is the idea that you are never ready, that there is always room for improvement. And this is where #NoEstimates greatly fits in.

#NoEstimates, not a method

To me #NoEstimates is an indication of continuous improvement. It is not a method or framework like Scrum, not a 10-steps program to success. Instead it is an invitation to discuss estimates-driven software development and look for alternatives to estimates. Woody Zuill, the most important #NoEstimates advocate, has defined the term like this:

"#NoEstimates is a hashtag for the topic of exploring alternatives to estimates for making decisions in software development. That is, ways to make decisions with 'No Estimates'."

The important thing in this definition is that people taking part of the #NoEstimates discussion are looking for alternatives to estimates. This can happen in many ways. People talk about the topic on Twitter, there are many blog posts written, many conference presentations have been held. There's even a #NoEstimates book written by Vasco Duarte [1].

There are many alternatives to estimates. A Scrum team could improve its process so that it can drop the estimation ceremony from the sprint planning meetings. A company might not be satisfied how its software development projects are started and run based on estimates. It might be an ad-hoc situation where a manager asks the developer to estimate a new feature for prioritization reasons but together they find a better way to decide about the priorities.

The common thing in all of these situations is the goal to do better software development. This can mean benefits like less waste in the process, faster feedback, improving the quality of the decisions made, getting faster to the market, etc. The purpose is not to refuse to estimate. #NoEstimates may be developer-driven but it is not a developers' conspiracy to avoid doing estimates just because doing estimates doesn't feel nice.

Maybe this misunderstanding has sometimes caused that #NoEstimates discussion has been quite turbulent, especially on Twitter. Personally I find that really sad because, like I stated above, the heart of #NoEstimates is continuous improvement. Nevertheless, it might be worth to point out also that #NoEstimates doesn't mean that everybody has to stop estimating in every possible context. If estimation brings value for you in your context, just keep doing it. However, don't expect that all the other people are in a similar situation.

Gateway drug

But if the goal is to do better software development, aren't there usually more important and acute problems than estimates? I absolutely think so, but for some reason estimating seems to be a very powerful tool for revealing these problems.

When someone tells me that estimates are needed in their company, I start to ask questions. Why do you have to rely on estimates? What is the reason that prevents you from stopping estimating? What would have to happen so that estimates wouldn't be so relevant information anymore?

These questions may not always be easy to answer but they usually reveal organizational issues. Typical examples are harmful project-thinking, missing trust between people or companies, lack of true collaboration, inefficient budgeting mechanisms, lack of visibility, slow communication systems, teams' inability to produce quality software in small pieces, lack of continuous deployment possibilities, harmful corporate policies, etc.

Solving these problems may be really hard but if you start working towards that, you may eventually be in a situation where you don't need estimates, at least not that much anymore. If you get there, getting rid of estimates has been just a nice-to-have level improvement compared to anything else you have achieved in your organization.

What is relevant here is that usually estimates, and especially their misuse, are just symptoms of some real issues that may not be so visible. #NoEstimates does not aim to solve the symptom because even though that would be easy - just stop estimating - it would probably be also dangerous. Instead, the purpose is to find and eliminate the root causes, to change the system conditions you are living in. So #NoEstimates can be, like my friend said some time ago, your gateway drug to systems thinking.

Teams that do not estimate

Even though I said that stopping estimating might be dangerous, this is not true for all teams. There are teams that estimate just because it is an organizational habit creating only waste and adding no value. I was telling my own #NoEstimates experiences to one of these teams a year ago without knowing much nothing about their situation. Later I heard that the day after my presentation, they had gathered together and decided to stop estimating. This triggered a lot of positive change in the team and around it. [2] This team is just one example. The last four teams that I have worked with have not been doing estimates. This means primarily task or user story estimates during the normal work process but also some bigger features that initially do not fit into the basic process as such. If and when these teams exist, it may be worth to understand how these teams work? What are their system conditions like?

Although every team is unique, it is certainly possible to find some patterns from each or most of them. One of them is transparency. The teams that I worked in try to be as transparent as possible for the stakeholders. Our whiteboards show the task status openly for anyone who is interested, and anyone can come and ask more what we are doing or about to do.

Another important thing is reasonable task sizes. If your task sizes vary for example between 1 and 30 days, it makes sense to estimate them. But if your tasks sizes vary between 1 and 3 days, you can focus much more on the value side of the task and just build the ones that are most valuable.

The key here is to have small enough tasks by splitting the big ones. There are several ways to do this. Neil Killick uses his slicing heuristics [3]. I tend to visualize the user story and find relevant pieces that become the building blocks. You can also consider asking questions like "can we make this task smaller" or "can we make this task simpler".

When you split your tasks into smaller ones, you create yourself a very valuable side effect: options. If you have one big task, you can either do it or not. If you divide instead this task into 5 smaller ones, you have options. One option is to postpone some of the tasks while you get benefits from doing the most important ones. Another option is to decide that you don't do some of the tasks at all. Companies do not always understand that the biggest and easiest savings in software development come from the features that are not developed because they are actually not needed.

One very important thing in teams that don't estimate is that they deliver instead. We talk here about mature teams that are able to produce working software in small pieces. This is probably the most valuable thing from the #NoEstimates point of view and gives the stakeholders really nice opportunities. When they prioritize tasks, they can focus on the value aspect much more than to the cost aspect.

There are better parameters

Teams that deliver working software often help their stakeholders to focus on the value over the cost (estimates). However, even when your team is not there yet, I recommend challenging the typical way of making the prioritization decisions.

Once in a while someone asks me an estimate so that she can make some kind of decision. I never give any estimate right away but instead ask more background information. I'm interested to understand better what decision will be made based on the estimate. Usually I find out that asking an estimate is just a habit and the decision is better made by using some other parameters.

Sometimes the best decision is not to implement the feature at all. Sometimes there are two options and one is much more valuable than the other. Sometimes we just don't understand the situation well enough and it's best to gather more information for example by building a prototype.

I would like to emphasize that I do not refuse to estimate. Instead I want to understand what kind of problem we are solving together and based on that I want to help finding the best tools to solve that problem. Estimating rarely is the best tool according to my experience.

Estimating and forecasting

It is possible to replace estimates with something better in many different situations but eventually you will face a case where none of the previously mentioned ways works. For example we may want to get an idea when a feature consisting ten tasks will be ready in order to plan other related activities like marketing. Luckily we do not have to rely on estimates in such a case either. Instead of estimating we rather forecast.

In his book Vasco Duarte goes nicely through the difference between estimating and forecasting [1]. Quoting The Merriam Webster dictionary he brings out that estimating is "giving a general idea about the value, size, or cost of something". Forecasting on the other hand means "calculating or predicting some future event usually as a result of analysis of available pertinent data". The important difference is that the latter one uses data when the first one does not.

We can use data also in software development and replace estimates with forecasts. Metrics I have used are lead times, weekly throughput, and takt time. Below you can see example data of a real project. The data is calculated in the Agile Data tool (http://agiledata.herokuapp.com) based on the start and end dates of the tasks that my team has finished.

Real project statistics including three different metrics (source http://agiledata.herokuapp.com)

Weekly throughput means the amount of tasks finished during a week. Takt time is the difference between end dates of tasks. For example if the team has finished tasks in March 2nd, 3rd, 3rd, and 6th, the takt times for those are 1, 0, and 3 days. Lead time for one task is the end date minus the start date.

Based on the data above it is really simple to calculate some forecasts. For example since the average takt time during the last three weeks has been 2.1 work days, the forecast for the next 10 tasks is 21 work days, or 4 work weeks. Picture 2 shows forecasts for the next ten tasks for the each three metrics. We could enhance these even more by taking the deviation into account and showing confidence intervals but let's skip that for the moment.

Forecasts for the next 10 tasks using the statistics in Picture 1 (source http://agiledata.herokuapp.com)

If you have been doing Scrum, you probably have used story point estimates and calculated the team velocity. It might look similar to this, but notice that there is a big difference in collecting story points data and collecting the metrics mentioned above. Story points are estimates meaning that when you measure story points velocity, you effectively measure estimates. But when you measure for instance weekly throughput, you measure actual progress.

Challenge of new projects

The forecasting methods shown above are examples of reference class forecasting [4]. Its purpose is to avoid some issues that are related to traditional estimating. We can use reference class forecasting here because we have a valid reference class. The data has been collected by the team X who use technologies T in the customer domain D. The forecasts are applicable because the team X continues working in the same customer domain D using the same technologies T.

But what if we are about to start a new project? There will be a team that has never worked together. There are some well-known technologies but also some new ones. And these people have never worked for this customer before. We could surely take some numbers from previous projects but applying them would be quite questionable.

Things are getting more difficult here, but at the same time also more interesting. We are phasing the famous project dilemma. Why are we asked to make estimates when we know the least of the project? Certainly customers want to know how long their project will take and how much will it cost but there is just one problem. They cannot know. Vendors and customers can only create an illusion that they know these things beforehand.

But what if we could change the system conditions also here? Maybe we should rethink how projects are started and run?

Project thinking

For some reasons, companies have a tendency to do things big. They say they are doing Agile software development, but at the same time they can need up to one year to start a new project. The budgeting process is usually really heavy and managers do their best to get the money for their projects. When the money has been granted, it is perfectly OK to use all of it or even go a bit over the budget. The process obviously includes vendor selection that can take even months. The vendor candidates naturally have to guess (estimate) the project size and duration when they know the least of the project. While all of this takes place, the company's CEO emphasizes in his presentation how short time to market is important factor for the company.

What if the companies would aim to true agility, also outside their Scrum teams? If the project should last 6 months, the company could first hire the vendor for a one-month project. The purpose of that would be to invest in knowledge. As a side product, the team would build working software that could be used to evaluate the concept and that could be used as a basis for the future development. After one month the company would have options. First of all, is this worth to continue or should we just accept that it was a bad idea and try something else? If it still seems to be a good idea, the team and stakeholders have probably learned a lot compared to what they knew month earlier. They may have even collected some statistics that can be used for forecasting the future progress.

Selecting a good vendor is obviously important here. If you let your sourcing department do it, it will probably sub-optimize by reaching their own goals: as much with as low price as possible. But if you do smart software development, you consider the vendor quality as a primary factor instead. If you are not familiar with the vendors, ask them how they develop software and how they would start solving your problem. Collaborate already before the project starts. Also prefer vendors who are fine with short-term notice. Of course the price matters as well, but only after the other attributes. Having price as you main criteria could be really expensive for you.

I'm aware that for some companies it is really difficult to work so that anything would happen in one month. But then on the other hand, this just means that we are seeing some organizational issues that might be worth solving.

We are uncovering better ways

The main goal of #NoEstimates is not to get rid of estimating. The main goal is to challenge the current estimate-driven software development and find better alternatives to estimates. The heart of #NoEstimates can be described with one sentence. It's the first sentence of Agile Manifesto:

"We are uncovering better ways of developing software by doing it and helping others do it."

During my #NoEstimates journey I have found many better ways and I believe that I will find many more. I welcome you to come along.

References

1. https://oikosofyseries.com/no-estimates-book-order
2. https://visible-quality.blogspot.fi/2014/11/power-of-stories-and-how-one-hour.html
3. https://en.wikipedia.org/wiki/Reference_class_forecasting

---

Related Agile and Scrum articles

Project Deadlines are Elastic by Value

Estimating With Use Case Points

Fingers in the Air: a Gentle Introduction to Software Estimation

Agile and Scrum Resources

Scrum Expert

Agile Videos and Tutorials

---

Click here to view the complete list of archived articles

This article was originally published in the Spring 2015 issue of Methods & Tools