Decoupling estimation from scheduling is not something that was invented after the Agile Manifesto.
The rule for serious estimators has always been to estimate size first and schedule second. I'm talking wisdom that's been around for decades. Pretty sure Boehm was talking about this as far back as the first COCOMO. It's literally older than I am.
I've only ever seen agile use time as a unit of size (the "ideal day") and it leads to the sort of trouble you're thinking of: conflation of size estimate with schedule estimate.
Non-time estimations might have been expressed in SLOCs, representative ojects, function points and so on. Inputs to estimation could include expert opinion (PERT, Wideband Delphi), historical records and judgement (COCOMO) or early process artefacts such as the number of paragraphs in a requirements document (PROBE).
I'm only 31. It shouldn't be the case that I am the "old fart" here. Sometimes I feel like I'm the only one talking about work, damn good work, that was done before agile came along and apparently hit the memory-flush button on an entire industry.
Agile is best practices around iterative and incremental development. That's it. It's a marketing term. Of course most of this stuff has been around forever. Most folks who "get" Agile say something like "This rocks! It's like we used to do things when we had a lot of fun and kicked out a shitload of code."
From observing teams the interesting thing is how many people used these techniques back in the day, stopped using them over time, and then don't want to go back because it's something "new". People are strange.
You should attend one of my classes. I ask what Agile is and then tell everybody it has no meaning at all. It's just a big blanket term we use to re-wrap a lot of that older stuff (and some new stuff too).
In my opinion the biggest problem Agile has comes from the people who like it. Skeptics are fine. I can show you this stuff works. But people who did "Agile" one time and become cheerleaders and set in their ways can be insufferable.
The rule for serious estimators has always been to estimate size first and schedule second. I'm talking wisdom that's been around for decades. Pretty sure Boehm was talking about this as far back as the first COCOMO. It's literally older than I am.
I've only ever seen agile use time as a unit of size (the "ideal day") and it leads to the sort of trouble you're thinking of: conflation of size estimate with schedule estimate.
Non-time estimations might have been expressed in SLOCs, representative ojects, function points and so on. Inputs to estimation could include expert opinion (PERT, Wideband Delphi), historical records and judgement (COCOMO) or early process artefacts such as the number of paragraphs in a requirements document (PROBE).
I'm only 31. It shouldn't be the case that I am the "old fart" here. Sometimes I feel like I'm the only one talking about work, damn good work, that was done before agile came along and apparently hit the memory-flush button on an entire industry.