I never said that two-week units (or any length of sprint) is treated as a complete deadline. Only that it’s treated as the cadence of work.

For some types of work, it’s inappropriate to spend time on e.g. planning overhead every two weeks, regardless of how much work you partially completed. Sometimes you just need a month before you can say anything meaningful.

For example, you say:

> “The worst case scenario is that some kind of interim demonstrable milestone has to be found in a chunk that is projected to take longer than a sprint, but in practice that's almost never very hard to do for an experienced developer. We routinely divvy up functionality, it's part of the professional skillset.”

But that is exactly the problem that happens all the time when you are e.g. working on a new statistical model.

You may not even learn what the required demo functionality even is within two weeks. Often all you can say is, “we looked into this with a ton of effort, and it’s really hard, and we need to look into it more.”

This happens very rarely with straight software engineering, and you can timebox it and then move on, or come back later.

But it happens all the time with fundamental research. So when you’re on a team that is assigned nothing but fundamental research, the arbitrary two-week meeting overhead cadence is a huge time wasting nuisance, and trying to conform the work to some cookie cutter expectations about breaking up by points, or rolling a ticket over, really gets in the way, especially when people want the “velocity” of research output to produce the same graphs as the velocity of other types of teams.

On the opposite end of the spectrum there can be alerting & monitoring teams, or helpdesk teams with very tight timelines, and for whom two week intervals are too long.

The point is that all the glib simplifications you mention don’t apply to every team, and it hurts productivity to try to wedge every conceptual way of working into some one-size-fits-all box that prescribes exactly when to spend time on planning overhead and exactly what overhead everyone must use.

> “Most managers really just want to know the team's velocity, so they can project the likelihood of making future (very real) deadlines”

If you have discovered a way of recording velocity that has even a weak predictive efficacy for forecasting completion, please let me know. Across all software teams I’ve heard of, worked on, or collaborated with, the velocity numbers carry no forecasting efficacy whatsoever. Not even for ballpark estimates.

I’ve literally had a manager come up to me and ask why Team A’s velocity looks “more linear” than Team B’s, or try to tell me they computed “t-stats” on one team’s velocity being bigger than another (they did not in fact know what NHST even was, only that some number popped out of a statistical test formula for population mean differences, and not even accounting for standard error).

I’ve had managers ask me if I can “simulate” how many story points one of my engineers would have completed had he not been on vacation for a sprint, because with the reduced story points, the curve they plotted for their meeting had a dip in it that they didn’t want to have to explain.

To me it just seems you’ve been exceptionally lucky with the types of middle managers who handle Agile data where you work. And I guess also out-of-this-world lucky with a team whose Agile story point based velocity has any informative predictive efficacy for deadlines.