Estimating things, can't live with it, can't live without it.
I waded into an interesting LinkedIn discussion (in Finnish) about story points and estimating things and that got me thinking about estimates again. I have so much sympathy for the #NoEstimates movement but it just seems way too radical to stop estimating things completely. As one person in the LinkedIn thread put it: "Would anyone start a renovation if they didn't have any sort of estimate of the costs?".
The counterargument is that "any sort" is the only kind of estimation you can have. Imagine that while doing the straightforward renovation you find out that some pipe has a leak and now you have to replace a bunch of waterworks and start drying up some structures. All previous budgets and timetables go right out the window.
Would that be a horrible surprise? Yes!
Should you still be thankful that you found out about the pipe and got a chance to fix it? Also yes?
Consider next a software project where the possibility of finding leaking pipes or black swans hidden below the floorboards is much higher. There might be some technical debt that trips up everything. Someone just made some wrong assumptions about how complex things would be. Hofstadter's law was ignored (or wasn't, doesn't really matter).
If estimates have been presented or taken as promises, they will do much more harm than good. First, you spend time crafting estimates, then you anger the customer because the estimates were wrong.
But are there any alternatives? In most situations going full #NoEstimates is a pipe dream. People are afraid that if they don't have estimates, the cost of the project can be anything at all. Million euros! Two million! No-one knows.
The thing many people might not realise is that software projects can have much stricter and more tightly controlled budgets than any renovation. If you are flexible about scope, you can lock down the cost corner of the iron triangle extremely tightly. If your budget for a customer support ticketing system is 150 euros, you can do it. You probably get a Google Form that sends responses to your email address, but still. If instead, your budget is 150 000 euros you can have quite a lot of more features.
The point is that if budget really is the most important thing for you, you can decide the budget.
But as there are a lot of ticketing services already available on the market, how do you know if building a new one would make sense? If you can't estimate the cost of building a set of features, how can you calculate the ROI? If you can't use a single euro to experiment and try to build something for real and see if continuing makes sense, can you just... estimate if your idea makes sense or not?
The answer is obviously yes.
You can estimate things for example in Excel and honestly, you will usually be sort of correct most of the time. Often the estimates given by professionals are pretty close to the mark and the things you have meticulously planned and designed are pretty clever.
And no.
You can't estimate anything in any meaningful way. Coding can spin hugely over budget fast. The resulting features can be crap that no customer will want to touch. You fundamentally can't know for certain before you have something that works and can be used by someone for real.
And yet, estimating things might still have value. Doing estimates is part of thinking about how the thing should be built. So you could argue that work spent on estimation is not wasted, it's just invested into building the thing already. Estimation is also a great way to have conversations and find out if everyone understood the feature to be built the same way. Once you have estimated a thing, you can use the estimates to track the velocity of the team and have one more way to notice if there's something wrong.
For example, if the team's velocity suddenly drops, maybe it's because the new product owner is pushing really hard for low estimates but the features still take as long to code as they did before. You don't necessarily need estimates to notice that kind of situation, but at least they would give you one more way to approach the following discussion.
The cost of estimation might still be too damn high.
The dysfunctions and twisted incentives and opportunities for disappointments they create are many. Also, my soul dies a bit every time I'm asked for an estimate for a thing that would take maybe two hours to do and when during the next two weeks maybe three hours of work are spent by experts and managers in multiple different organisations on estimating the thing, communicating the estimation and deciding if the estimate is low enough so that the two hours of work can be done.
The more I write about estimates, the less I'm excited about them. Sadly, going full #NoEstimates would just require such huge transparency and trust in the process and the people involved that it's not a realistic suggestion in many cases. Especially as the places that suffer most from the negative side effects of estimation are probably the ones that have the least amount of trust to begin with. Would the gains be enough to justify changing everything and fighting through the inertia and resistance from your team, customers, management, and your own habits?
The mere idea sort of feels exhausting. And still...
There have to be better ways to do things. The problem is getting to use them in the real world. I'll start by watching this video of a talk by Vasco Duarte and maybe that will give me some ideas. See you at the next one.
Scrum the day