Together with my last team, we were known across the company to be a squad with decent estimation skills. That muscle didn’t grow by itself. From time to time we would miss ticket heavily - and I’m not talking about couple of hours here or there. I’m talking about missing by 500%, or 700%. You’re telling your customer, that you will deliver this piece in a single day, and a week later this is still in progress. We’ve added planning poker, started reading about MoSCoW, RICE, KANO, Walking Skeleton and started performing frequent post-sprint estimation analysis. With all of these techniques, after a couple of months, we’ve improved our average commitment vs completed metric from ~55% to around 78%. Suddenly we became more predictable to our customers, which resulted in new contracts.

So, when I encountered this video some time ago:

If you’re a product company, maybe you can tell your bosses that you’re uncertain how long will you work on a piece of software, and you’ll use the approximation technique in order to predict that. However, how do you plan to achieve that as a software house company? You’re going to tell your customer, that “Hey, sign this contract for 4 weeks, we have a team of professionals here, you’ll pay just 40 000$ and we’re going to build you something. If you like it, we can continue and I’ll tell you how long the rest of the development will take. If not, well, at least we tried, and you can use this working prototype as… something.” Good luck, I predict plenty of customers hitting on your door.

Business people are not dumb, they really understand that estimation is “just” estimation, it won’t be accurate by its definition. They also have no technical knowledge to predict, if building a Gatsby blog will take one, 24, or 240 hours. That’s why they’re asking professionals - so they can evaluate if they can afford that. It’s not a great investment to hire a software company that will build 10% of your idea (and let’s say, eat 50% of your budget) to find out, that project is huge.

I would love to say that most of the problems with estimating which I’ve encountered are related to inherited uncertainty in software development, but it’s simply not true. Most of the times, problems were related to these things:

• People wanted to start coding, instead of asking these boring questions. They created some assumptions about the task and didn’t validate their assumptions with the customer.
• People ignored gaps in their knowledge, despite the fact that for a short second they felt that “this is weird”. They decided to ignore it because “this will clarify itself later”. Usually, it does - when it’s quite late and a lot of work is lost already.
• People were afraid to raise their doubts about the task, so they won’t look stupid. Especially, when you are in a group of highly intelligent developers and they seem to be confident that the task is “super easy”.
• People agree to leave big estimates like 24 hours or more in a single “task”. Most of the time big estimation is a safety buffer which simply hides the fact that we don’t have a full idea of what needs to be done. If you fully understand what needs to be done, you should make sure that your backlog of incoming tasks has no tickets larger than 8 hours.

When our team has focused on these problems and tried to eliminate them as soon as possible, we started to ask good questions before the coding even started, which is the soonest feedback loop you can imagine. We were able to predict most of the possible roadblocks and act accordingly to mitigate the risk of failure, spending 1.5 hours collaboratively each week doing estimates. Is this really so much wasted time? I don’t think so. I think that some people got lazy!

Of course you won’t predict everything, but your customer is not expecting you to. You need to be right most of the time. If you’re attitude is, that estimation is a waste of time and it’s always a wild guess - it will be.

Here’s the kicker. I know that Allen Hollub and other agile preachers are smart people - I started to dig more about #noestimates. It clearly seems that this hashtag is controversial on purpose to spark a discussion. It seems there is an interesting book called “No Estimates” by Vasco Duarte with plenty of good ideas. “No Estimates” is a catchy sentence, but the idea is not to eliminate estimation entierly, but minimize it and do it differently. The one idea which I liked is that author recommends splitting tasks to be in a size of a single day or less… which is exactly the same idea that my team came to, working on improving our estimation skills. Maybe the name of the book and the entire hashtag should be #estimateSmart instead…

In every profession, you need to evaluate how long you will perform a task (or an order) to stay competitive. I understand, that it may be harder for a developer to do that than for the carpenter, or sometimes even a company that builds planes or tailored yachts. However, remember that we build software for other people, not just for the sake of building it. We cannot expect our customers to understand the complexity of crafting software. They will ask us for estimations. It is our responsibility in return to ask the right questions to minimize the development risk, establish effective requirement gathering and analysis process which works for our team. We should guide them and explain the possible options, instead of being arrogant, unique snowflake in the industry. I feel that this quality is lost quite a lot recently in the software development world.