[throwaway_Aef8]

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

[throwaway2016a]

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.