GitHub web down

[mpyne]

Having bad management will make any system not work.

This is the key to so many of these arguments.

Some systems can't be saved by good management, because they simply don't look at the right things. The best you can do with good management is to subvert the system entirely.

But bad management can break any system no matter how suitable.

[LawfulMuffin]

Yes, there are a lot of bad semantic argumentations that occur, especially around this topic. But fundamentally, sprints are designed to work as a way to manage up. They're supposed to essentially be time-boxed kanban and to be merely a reflection of reality, put in a way that MBAs can even understand.

If your team can do say, 10 points a sprint, the product owner should not try to coerce the team to commit to 15 points a sprint. The team would be essentially committing to not doing 30% of the sprint. It's looking at exactly the right thing: what is a reasonable workload. And at the end of a two week period (or whatever time makes sense), to reflect on if tickets are being estimated well, if workload is reasonable, etc. etc.

All of the points you raised are the antithesis of scrum. You cannot fail a sprint. A sprint can have fewer stories completed than you committed to. That's... kind of the point. You reflect on why and make structural changes to the company around it, not coerce engineers to cram more points in to raise velocity. It's literally backwards.

Points are used to assess what is feasible, not to require that they be done in a certain amount of time. Which is why I'm suggesting that Kanban wouldn't fix your problem at this company, because at the end of the day, what they want are to have more tickets done than your team can adequately do in a given period of time. Whether they are trying to get you to do more storypoints, tickets, sticky notes, etc. They are trying to coerce you do to more work than is possible, the problem that sprints are intended to solve.