You're supposed to use your velocity to figure out how many story points you can reasonably complete in a Sprint. But if the velocity is padded (by adding invisible capacity... extra hours unaccounted for in the velocity calculation) then you end up with unrealistic expectations.

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.

Does it make sense to expect 100% completion? Maybe for something new our estimates are off by X% and future ones get more accurate. But then there's unplanned tasks/work from infrastructure issues or a high priority issue from upper management, or some other group.

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

If you're a good Scrum Master, the goal is to get as close to 100% plus or minus BUT never as a punitive thing. If you miss the target that shouldn't mean your team failed, that should mean that the velocity was wrong and will be reflected in the velocity for the next Sprint.

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.

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

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.

I use story points per Sprint on a 3 Sprint moving average weighted by capacity to account for things like vacation. Works pretty well.

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.