> Issues may not be added to the sprint
I don't see this happening, even if that's a good rule, because issues come up that take higher priority than existing issues.
I don't see this happening, even if that's a good rule, because issues come up that take higher priority than existing issues.
The engineer's response to unplanned work should be "Go talk to my manager", and the manager's response must be "Wait til next iteration". If the team can't defend its own boundaries, it's hosed, period.
I often use a bread-baking analogy here. Making software is like baking bread. This iteration, we get some flour, water, yeast, and salt, mix them together, knead, rise, and bake. And if someone comes in five minutes before baking is done and says "Can't you just add some raisins now? It's just a handful of raisins, it's not much work". No. It means starting over.
Say the event subsystem is shared or is under control of another group. They do maintenance, and the app doesn't restart and stays down because it had bad retry logic and won't retry after the connection is closed. Stupid bug, easy fix.
You're now hobbling that other group from doing their work, and depending on the discipline of the app team to fix it, and that bug may stay in the backlog a long time. Meanwhile, it's going to come up in a handful of meetings with a handful of people as it gets estimated, prioritized, assigned, touched again and again...
Coming to someone after diagnosing and helping them recover from a problem, only to be told "we're busy, come back three weeks from now" sucks.
Is it a production bug? If it is, can it wait? Just because it's a production bug doesn't mean it must be addressed outside the normal iteration cycle. Criticality should matter.
If it's not a production bug...
Is it a missed critical requirement? WHY??? How did the entire team miss something that must be done right now? That's a major process failure.
If it's not a missed critical requirement...
Is it someone with great power just disrupting your iterations for their pet project? Do you have multiple customers who are competing for your team as a resource, and not hashing priorities out together in iteration planning?
Following from that...
Are they directly in your chain of command? Is it your superior changing horses in midstream, or your customer? Because you can tell customers no. Even if they scream and shout and say they're gonna tell Mom. The customer is not always right. Learn to say no.
And if you still feel like you have no authority and no control over your work...
Quit.
Maybe it's a good general workflow but as a hard rule it seems rather silly... but I would love to work somewhere where there wasn't a flipflop on priorities every week or so :)
On the other hand, distinguishing between "the product doesn't do X properly" and "the product doesn't do X yet" isn't necessarily important or meaningful.