4 fallacious reasons why we estimate

‘Estimate’ as defined in this article is: A guess about the future regarding the time or effort that a task(s) will take to be completed. In other words, anything that can be used to foresee when tasks will be done.

I have to confess, I’m not very good at estimating. Because of that, for the past 3 or 4 years, I’ve been trying to use different approaches other than estimates. Although I lost my faith in estimation long ago, as a software engineer, I still receive requests for my opinion. Regardless if I end up giving an estimate or not, I always ask the person why they want one.

In this post, I’ll share some of the given reasons the team decided weren’t worth spending the energy to create estimates. However, keep in mind this is merely my own point of view and my own particular circumstances; this may not apply to your scenario.

1. I need an estimate because… I need to measure productivity

Although I understand measuring productivity could work well for repeatable activities, it’s hard to believe it works well for abstract and, ultimately, non-repeatable tasks like software development. For non-repeatable activities — meaning it’s never been done before — no one really knows how much time a task should take. Thus, the common approach to “measure productivity” is to compare the estimates against what, in fact, happened. This can cause a number of problems, including the fact that once developers realize they are being judged by their own estimates, they start to be very careful about the process of creating those same estimates, usually spending a lot of precious time completing an activity which doesn’t accrue additional value to the product that they are building.

From my experience, seeking to measure productivity is usually more intense when the side requiring the estimate doesn’t have a profound trust that the other side will work very hard. That’s why I strive to create an environment with mutual trust between the engineers and the different stakeholders. One of the most powerful techniques in this sense is to have a genuine interest in understanding the reasons behind the requirements for estimates. We engineers should always keep in mind that software development is usually one part of many others inside the company. After having worked for outsourcing, consultancy and product companies I believe that creating a place where people really trust each other is easier when software engineers and stakeholders are both part of the same organization. That’s one of the reasons why more and more companies are now considering software development as a core business — thus creating really strong software engineer teams.

2. I need an estimate because… someone else is asking me to provide one

It’s incredibly common to hear this reason in environment with traditional hierarchy where decisions are made top-down. I strongly believe that “ agile transformations are not about transforming IT, they are about transforming organizations”.

I remember once working for a product where our project manager asked us for an upfront estimate regarding a large feature that would be a game changer in the product. We tried to make it clear it was just a guess, and then provided a 3-month estimate.

Without us realizing it, the marketing team then created a beautiful campaign and started giving hints for the customer that the feature would be launched soon. Unfortunately, due to a variety of reasons, the feature was released with a huge delay. At this point, the marketing team came and asked: “Why did you tell us it would take 3 months? If you didn’t know upfront, why didn’t you just say you didn’t know?”

Cases like this helped me learn not to provide estimates unless someone specifically tells you the reason. In this case, had we realized that marketing would take our estimate as something solid to use to begin promoting to customers, we would have acted quite differently.

The interesting thing is we are so ingrained to the culture of giving estimates that we end up giving them even when no one is asking us! Having in mind how dangerous a reckless estimate can be, I would not provide an estimate unless someone is explicitly asking you one. You can still have a general time frame in your mind, but it may be better to keep it to yourself, thus avoiding problems like the anchoring effect.

3. I need an estimate because… having one motivates us to work harder

This is a dangerous statement. Although it may encourage the team to stay in the office for longer hours, it’s not a healthy long-term approach. I’ve seen many teams working very hard to finish tasks before the estimated date. Many have ended up forgetting about other important things in the process, like code quality and a focus on simplicity. The cost of this cannot be underestimated. It will really come to the surface later when the team realizes that, as a result, they have accrued significant technical debts.

4. I need an estimate because… I need one to prioritize my backlog

One of the most important and complex questions in software development is, “What should we work on next?” Although I believe that in order to prioritize we should take into consideration the size and effort of the tasks, I’m not convinced we really need estimates to do that. This statement may seem contradictory, but I’ll show you how I’ve been prioritizing without using estimates.

First — backlog prioritization is essentially a sorting process. As software developers, we know the only requirement to order a list of items is to be able to compare elements. In other words, we don’t need to know the absolute value of an item, but we need to know how to compare them. The trick as it relates to estimates is that although we aren’t very good at determining absolute numbers, we are better comparing things of the same nature.

To illustrate this principle, let’s consider these three images:

Would you be able to tell me how many people we have in each picture? More than that, would you bet your money on your estimates? On the other hand, if I asked you to sort the pictures according to the number of people in each one, I’m sure you’d be able to do it. I’ve been using the same principle to prioritize my backlog.

How are estimates used in TransferWise?

Before answering this question, it’s important to understand how teams are organized in TransferWise. As Nilan, our VP of growth, explained, “We hire smart people and trust them”. Teams are autonomous — no one can tell them what to do.

For example, we have a currencies team. It decides each quarter which currencies it’s going to launch. No one tells the team what currencies to launch. Anyone can challenge the team on what it’s doing and the team should have a rationale for explaining why it’s focussing where it is.

As a result, it’s completely up to team members to decide whether they want to use estimates as a tool to help them or not. In my current team, there’s no planning poker session or any other form of estimates for individual tasks. The closest process we have to the traditional way of creating estimates is that we have a quarterly planning where we prioritize our backlog. After that, we decide the topics we’ll detail a bit more so that other people in the company would be able to understand where we’re headed and why we came to that conclusion.

After all, is there a good reason why I should use estimates?

To be honest, I don’t know the answer to this question. The first thing I try to keep in mind is, “estimations are valuable when it helps you make a significant decision”. Thus, the question I usually ask myself is, “What is the decision we need to make? Can we possibly make this decision without an estimate?”

Even more important than answering these questions is to open our minds to new ideas. In this way, I’d like to ask you, “What are the scenarios where you’re using estimates and they aren’t actually required?”

I’d love to hear from you.

P.S. Interested to join us? We’re hiring. Check out our open Engineering roles.

Originally published at https://tech.transferwise.com on August 17, 2017.