Comment by genghisjahn | Hacker News Reader

Comment by genghisjahn | Hacker News Reader

Parent Full thread

What helped me was to track Sprint Volatility in addition to Sprint Velocity. We had our over all capacity, let's say 40 points and that would go up or down some based on people leaving the team, joining the team, etc. It's just an average of how much a team can get done in a given sprint. Velocity was gauged as points per person per day.

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.

I would snapshot the sprint each day, so each day I could see how many tickets got removed/added. The end result being I could show my manager, look, when volatility is low, we almost always finish the sprint. When the volatility is high, we don't, it doesn't matter if we are over/under velocity because we don't have the time to properly plan and get clarity on asks. Have our product team think more than two weeks out and we'll deliver. That worked to a degree.

> 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.

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

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.

...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.

> What helped me was to track Sprint Volatility in addition to Sprint Velocity.

I dread to imagine the number of bike shedding meetings and planning poker it takes to change a 5 to a 3 or 7.

Jitter in agile; I love it.

Reply on news.ycombinator.com