One thing I learned a long time ago is that a "bad" process that is followed universally by everyone (dev, pjm, pm) will always out perform a "great" process with only token buy-in and constant exceptions.

If you've ever seen someone operating a terrible piece of old data entry software they've been using for decades it's amazing how fast someone can be even at jumping through pointless hoops to get the job done - often a problem when introducing a newer process that might seem more efficient from the outside!

A key cause of that being a problem is stacking the entire team with a full sprint of vital work. Leave some time for issues. If no issues come up, pick up some nice-to-have tickets in the now spare time at the end of the sprint, or get started on work for next sprint.

If you absolutely must give everyone a full sprint of work every time, make sure some of it is from the nice-to-have pile so it can be put off when the surprise P0s come in (and in the absence of surprises, you get to clear off some of what are now nice-to-have bits of work but later might otherwise get surrounded by code/infrastructure that assumes they'll never happen so morph into nasty technical debt and/or their very own surprise P0). But if you try this, good luck explaining upwards why nice-to-have tickets are on the board while there are more important ones in the pile…

But then you have another issue, the sprint gets oversubscribed or behind and instead of stuff moving to next Sprint the team works overtime. Now all the sudden the velocity calculations look like you have one velocity but really it's because you added extra capacity that sprint.

Won't take long until "extra capacity" because "the normal way."

If your velocity is correct you should end up with 100% completion and your employees having a work life balance. But I rarely see that.

If a developer finishes all their tickets they should help out other developers. And if by some stretch you overestimate... which I think may be a worlds first for software ;)... you're supposed to grab the next highest priority ticket from the backlog.

But I've also seen an approach where the sprint purposely has more than the velocity in it as kind of a "stretch goal" but everyone on the team knows anything bellow the velocity line is unlikely to get done.

I've also seem places where the stretch goal becomes the goal the client is told will be completed... those places are toxic, if you find yourself working at one, run.

Edit: If you are 100% complete on your first Sprint then yes, you probably incorrectly planned capacity. It takes 3 sprints to get a velocity. But once you have a velocity, it should be pretty stable.

Edit 2: This is why you prioritize your whole backlog, not just the current sprint. For the chance you end up with 100% completion. No use scheduling > 100%. IMO that just lends to the problem I mentioned of the stretch goal becoming the real goal.

So then the idea is - well, "fix" the other unplanned work by adding more process to those other groups...

BUT then overall the business changes anyway.

conclusion - the point of all this is:

1 - we create an illusory sense of control so the business can feel good about it 2 - so at least we don't have to be overwhelmed by an infinite todo list and can end each day with some sense of work/life balance

I personally think forcing the team to 100% or punishing them for not hitting 100% is extremely toxic.

For me, bugs are 0 story points, and misestimated tickets are never re-estimated. If you re-estimate or adjust a ticket you are messing up velocity. Velocity when done right has a built in allowance for bugs and misestimates. It takes discipline.

Eventually, since story points per Sprint is based on a measured velocity, I've found you end up in a natural flow where you hit 100% without trying.

The one part where it gets tricky is the burn down/up chart when used as a way to tell the team to speed up vs just an estimation tool.

Also, that gets to one of the issues with agile, is that what the velocity says can be done may be less than what the stake holder wants and it takes a very strong account manager to be able to explain that rather than agreeing to the unrealistic.

It would be awesome if this were the exact, widely agreed upon definition of velocity.

Of course then the other issue would be whether it's followed.

Of course, importantly, points cannot be directly tied to time or people will start biasing their estimates. I use "complexity" on a Fibonacci scale.

Edit: works pretty well until someone does something to effect capacity mid Sprint like making everyone work extra hours.

If it is following a structure specified outside the working organization, it is not Agile, but instead the exact thing that Agile was explicitly a reaction against.

> Mostly because every single sprint becomes so derailed by "urgent" outside requirements that any sort of cohesion and planning goes out the window.

An approach that puts following a plan over responding to change is...not Agile.

> Then you have clients who won't pay for the planning and retrospective time.

Why does your contract not define what is a billable hour and charge an appropriate rate for the time?

> I think my record is 4 consecutive Sprints before things went completely off process.

If you aren't adapting your process continuously (or, rather evaluating it continuously and adapting as needed), you are giving process a priority over the concrete team (in the broad sense, including the customer) and set of challenges faced that is exactly what the first value statement in the Agile Manifesto is about not doing.