[yamtaddle]

The benefit is a social one of being able to tell "stakeholders" that their shit's getting bumped to the next sprint if they keep trying to toss extra junk on the pile this sprint. The time cut-off is helpful for keeping jackasses up the org chart at bay, when it's done correctly and you're actually allowed to say things like that, and follow through. The chunked time makes it easier to justify a larger time-cost to monkeying with the short-term schedule, which makes stakeholders be more considerate.

That's in the unicorn-rare case that you're in an org that can do "agile" right, but still has the problem of clueless stakeholders shitting everywhere and no discipline or expectation that PMs are empowered to tell them (politely) to fuck off without the support of this kind of framework. Otherwise, yeah, they're not that useful. You can track velocity and such without them, so that's not a good reason to have them.

[ptr]

I’ve been on the stakeholder side in similar situations. Rather than saying that they were very busy and that it can take a while to get my task done, they strung me along (“we’ll take it up in next sprint planning”, “oh we missed your task, but it might be added to next sprint”, etc). Granted, this is an anecdote, but if a team can only plan a couple of weeks ahead, how should stakeholders be able to plan?

[yamtaddle]

Sure, I hope I made it clear that in general I don't think sprints are especially useful. They can truly be useful in the specific, narrow case of organizations that have independent, well-run teams but also inept or inexperienced-with-software-development stakeholders who've got a dysfunctional relationship with those same teams, and when for some reason that problem can't be addressed directly rather than relying on sprints as a boundary-setting and communication tool. Probably this combination most often happens in-the-wild when the developers and the stakeholders aren't even in the same organization, in fact (think: development agencies).

The dysfunction can certainly go the other way (the stakeholders are competent and reasonable, but the teams are broken) in which case I'd not expect sprints to be helpful, and possibly abusable in the ways you suggest.

> if a team can only plan a couple of weeks ahead, how should stakeholders be able to plan?

When it's done right (ha, ha, ha) there absolutely is long-term planning, but adjustment of priorities sprint-to-sprint (which should be happening due to stakeholders and product managers and such making decisions, since they set those priorities) can affect that—the flux in long-term planning should be a reflection of the reality of choices made sprint to sprint that differ from the original plan, not due to a lack of planning, so that no-one's surprised when the mark that's hit in six months differs—for the good reason that the direction of the project was modified in-flight—from the one that was originally targeted. The entire point of sprints is to allow flexibility without day-to-day thrashing, while also capturing the effects of each sprint's work on that longer-term planning to avoid big surprises farther into the project.

Again, that's all if it's done correctly, and if the situation even warrants using sprints in the first place. Which, every now and then all that's true, but I'd not say it's the norm. I don't think most orgs even think very hard about what the point of having sprints is, before imposing them.