> And I’ve also seen wise use of estimation but that is rarer
I've got a question for you here, what is a wise use of estimation?
What problems are estimates the ideal solution for? In the context of software development?
I can think of only two: planning headcount and priorities (aka planning the order in which you do things).
When you focus on those problems, you realize there's no need for an accurate estimate. All you need is relative sizing between requests. This seems twice as much work as that but gives us half the benefit. Ok probably we shouldn't do this one first. And even then, often time impact is all you need for priorities. Like who cares what takes you longer, if you just focus on building the next most impactful thing you'll very often succeed.
The question of: "When are we going to be done this?" Is almost always irrelevant except for what I mentioned "asking for a quote". Like, who cares when it's done? What else you'd rather we do? I can tell you if your alternative will be any faster or not. And is this not the most impactful thing? If so, let's finish it and stop slowing us down with these irrelevant questions.
Now for headcount, it's the same thing. Look how much you did last year with what headcount. Ask yourself if what you're hoping to do this year is of the same relative size, twice as big, half as big, or smaller? And then plan headcount accordingly. If twice as big, double head count. Overtime you'll learn if twice as big requires doubling headcount or 1.5x or 1.2x or 2.3x etc.
Who cares when it's done? Often there are external deadlines like a start of production of a car for example which can not realistically be moved because too much planning would need to be redone and too much disruption would cause so much overhead that it could break a company.
Also when price and time are fixed, there is only one thing left for negotiation and it is the amount of features being delivered. Sometimes people have a hard time to cope with it but if you do it correctly it's a great thing for everyone. The most important features could be delivered early and the closer to the deadline the non critical features can be implemented which are nice to have but won't break the product if they're not in place. That's a great way to bring as much value as possible without breaking anyone.
Yes exactly! When you ask someone for their estimate, you're getting a quote from them.
When you actually want to predict the length of time something will take, you rely on historical data and create a projected forecast. It never involves asking somebody for their best guess. That's how every single "other thing" we predict is handled, so why is software done differently.
Actually, I've seen some of these ideas being talked about in KanBan circles, like tracking lead time and cycle time, and then using monte carlo simulations to forecast, but I've never actually seen them in practice.
Didn't Joel Spolsky implement it all the way back in the stone age... er, 2007[0]?
The idea is old. The problem is, in many software companies, none of the tasks look alike. So your past data is going to be somewhat dirty, particularly at team level. Perhaps as an individual, intimately familiar with the problems you encounter, being able to introspect your own thought process - perhaps you or me, we could learn to estimate better. Except the existing popular tooling absolutely sucks at facilitating that.
> The problem is, in many software companies, none of the tasks look alike. So your past data is going to be somewhat dirty, particularly at team level
Tasks don't really give you anything though. I think if it was measured in terms of features, that would work a lot better.
And with a Monte Carlo simulation, you get to know the time it would take you to complete any random feature on any random period. So maybe you can't perfectly predict that next feature, but in the year, on the average, your predictions should tend towards good accuracy.
And you could take it further, machine learn the feature request to the time it took. And then run the ML inference on any new feature request. Maybe let devs add some labels, it's not exactly estimating, but they could mention if say they think something is "complex", "ambiguous", "straightforward", etc.
Monte Carlo here is just a way of adding together estimate distributions without doing any of the fancy math. The variance of resulting compound estimate strongly depends on the variance on inputs.
Feature-based estimation seems to coarse to me. Not only none of the features is ever like the others once you dig into it, they're also interconnected.
While your examples I'm not sure are super relevant from a software development context. I think you're pointing out that the estimate would help you decide when you need to start so you are done before the "real life events that needs the thing".
Is that correct?
Like for example I'm not sure it's useful to learn that no, you will not be ready for the Christmas event. Or no the cruise ship will not be ready in time. But it might be useful to know: "If I want to be ready for the Christmas event when should I get started and how many developers do I need?"
That's a good example I guess, though I haven't seen this issue arise very often in software. I could imagine someone needing to know when to start feature freeze and prep work for scaling up leading up to a big sale event if you run an online store for example.
My take on this is that asking devs to guess that time would obviously not work. And if you did this type of forecasting for any other discipline, you'd instead gather historical data about how much time things took in the past and plot that to forecast how much you'd think it takes in the future. Which is a process that can be done without needing to ask a dev for their personal not data based guesstimate.
I have seen two software examples first hand. Usually it's because a feature can have much more value at a very specific date.
The first one was a feature for one of the minor verticals of the company product. Basically, something that would be nice to have and would be done eventually, but not a priority. However, the big annual trade show for that vertical was coming up, and the company could have a slot for a conference/demonstrate a feature. Marketing/sales were pretty convinced the aforementioned feature could be a big hit at the show, and provide lots of exposure. So we were asked whether it was possible to have it ready by then. If we could, then it would have a lot of value and would be priority 1, otherwise back to the backlog because it would be much harder to advertise it outside of the show.
Second example was caused by the reduction in VAT in Germany last year. Having internationalisation/German translation all of the sudden became pretty valuable because that would help push even more products in Germany.
I haven't seen this issue arise very often in software
No? Maybe not if you're a software-only company. But for pretty much every hardware (a gadget, a car, a rocket, whatever), the software is part of it and it aint working until the software is.
If you don't want your product to be held shipping because the software isn't ready, you better have some way of estimating when it's going to get done so you can either trade features, personell, or even just knowing that there's no point rushing the hardware because it'll be done way before the code anyway.
Inter-team dependencies. Marketing pushes. Customer commitments. New sales dependent on certain features. Building features to increase TAM. Partner commitments for interoperability / joint deployments. Even presentations of your roadmap to customers and prospects to get them bought into your vision of where the product is going.
There's tons of things that require broadly knowing when X is going to be done beyond capacity issues.
The above are reasons a business needs estimates / rough delivery timelines. I'm not sure how my discussion of the value of estimates is relevant to the quality of them.
To get a rough idea of what work can be done in the next X weeks, so that the business can forecast.
The wisdom comes in knowing things can change and it's just an estimate. The process of estimating is quite good as it requires finding out a lot more about how you will solve something, and planning things in advance.
Forecast to what purpose? What is the business actually trying to achieve for which they believe, maybe wrongly, they need accurate software estimates?
Often I see this haggling down of estimates and then microagression if estimates are not met but no need to work for free to make up for it.
And I’ve also seen wise use of estimation but that is rarer!