[Izkata]

> Volatility is how much the sprint changes. Sure you can pull one 5 pt ticket out and add in a 3 point and 2 point, but if you do that 12 times in a two week sprint, we will not finish the sprint even if total capacity stays under 40 points.

Isn't the entire point of a sprint that, once planning at the start of the sprint is over, you can't change what's in it by reprioritizing? All of product's reprioritizing should be in the backlog, not the sprint, and only affect what the next sprint is going to be, not the current one.

[wolpoli]

In official scrum, the development team could choose to accept substitution. It looks like the GP's case, they are obligated to accept substitution.

[genghisjahn]

After I presented the volatility findings, that changed. Sprints largely had to stay as they were and the team decided what we’d take on after the sprint started. It got better. But the whole sprint/scrum/agile thing is still weird. It can be helpful but in a large org it’s never easy. I hope for further improvement in the area of scheduling/estimation in software development.

[skeeter2020]

...which is one of my major (of many) complaints about all "scaled agile" frameworks: the promise is that you put all this planning effort in we won't blow up your plan for the next 4/6/n sprints; you get stability and predictability, and can actually shave a yak or boil the ocean, things that are hard to progress with just a 2 week window. Who has ever seen an org with the discipline to NOT do this? Executives are rewarded for the "action imperative" and quick course corrections. They want big, bankable delivery dates AND agile responsiveness to fundamental goal changes. Good luck.