This conversation perfectly captures estimation dystopia.
Money, money, money
Estimates are a common habit in the IT industry. Estimates are usually needed for financial reasons:
Will the project get the proper funding ?
Business accountants need to plan ahead and run the company's budget. They are in charge of allocating funds to different projects so as to reach the goals defined by the corporate strategy.
Budget in IT
Accounting works like this for all departments, regardless of how accurate their estimated budget is. It turns out that IT really stands out when it comes to estimates. I've never met an IT project that was on time and on budget ... never. That's nothing new, IT has always been this way. Common are the meetings meant to explain why the budget drifted and why the project was not fulfilled as expected. But IT, due to its very nature is very unexpected. Nothing really behaves like it is supposed to. The product is a mix between technology which is in most part predictable, with blurry and non-deterministic human requirements, all this crafted by humans. No wonder budgets drifts.
errare humanum est (to err is human)
How to predict the unpredictable ?
It can get really disappointing to analyze how the budget came to drift, but that's undermining the real nature of IT : unpredictability.
As a response to such practices, Agile came along. Its second principle states that there can be no concession on quality.
Being agile mean that the scope is reduced to a reasonable amount. Not only is a reduction of scope easier to apprehend and estimate, but it also allows for changing the scope. Yes that actually means that what was presented during budget planning is not what will get delivered. That is why budget planning is a lie when it comes to scope.
As for how fast the project will be going, it really depends on many aspects. The Mythical Man-Month explains that adding resources to a project which is already suffering from a high cadence is counter-productive. Each added resource has to be mentored, meaning that someone on the project will be taking time off for mentoring, thus reducing velocity. Extra care has to be taken when considering adding resources to a project. If a project is suffering from poor velocity, additional resources will only slow it down.
The only thing that is predictable is that the team will do its best given the right environment. In a best-effort strategy, what is predictable is the next features to be added. This should be seen as a good thing because, rigidity and budget nitpicking has been traded for adaptability and constant delivery.
Producing constantly is a great way to battle-test feature in the wild. So instead of having a fixed budget and an unpredictable outcome, we now have a fixed monthly budget and a product which we can steer in the right direction. Think of it as having a plane compared to a rocket; it's possible to steer a plane, whereas a rocket has to be oriented before launching it.
Why then estimate ?
Coming back to the tweet at the beginning, if the budget is fixed why then estimate ? An estimate can help to get a rough idea of the size of a project. This, in order to get a team up and running and some idea of how fast core features will be delivered, especially in a competitive market.
As well, estimates aid product owners split up stories which are too big. There are many techniques to split up stories. Indeed as some parts of stories are more important than others they should be prioritized. Splitting stories can actually get more user value delivered faster. User value has to be measured after each delivery.
Estimates are not meant to be precise, nor will they ever be. Story points or t-shirt sizes are commonly used for estimates, precisely because they do not focus on time spent but on comparative complexity. An estimate will not indicate how much time will be spent on each story nor will they tell how much time is left on an active story. It is therefore foolish to consider estimating remaining sprint time by estimating remaining tasks in story points. If that were the case, burndowns would all be linear, but they never are. Even worse, estimates should never be given on a time-basis because that would give a fixed commitment and would lead back to the nitpicking meetings about why the team drifted.
Estimates have counter-intuitive value. They are not meant to find out when a specific feature will be delivered, but rather how much value can be delivered in a time-scope. They also help maximizing value throughput.