top | item 19572250

(no title)

aboutruby | 7 years ago

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

discuss

order

SketchySeaBeast|7 years ago

I noticed that as well. That'll be pushed back against, and the leadership is going to decided that they must respond to SOME issues to appear responsive, and let's be honest, it's going to have to happen regardless of project ideology. There'll be some silly rule put in place that only priority "X" issues get looked at mid sprint, and suddenly every issue is going to be priority "X", and now someone gets to spend the time they would have spent fixing the issue going "Ok, is this really a priority 'X' issue?" and fighting with whoever raised it.

beat|7 years ago

Decent iterations cannot be done without immediate management playing defense, period. As long as anyone is allowed to interrupt the iteration, then iterations are just going through the motions and won't solve any actual problems - because the problem is a lack of control.

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.

beat|7 years ago

This is another time to ask uncomfortable questions. Why are issues coming up in the middle of the iteration that "take higher priority"? Why can't they wait?

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.

tudelo|7 years ago

I don't even think it's a good rule because if something critical/high priority comes up it could be because of planning or it could be because of multiple external forces and or a bug.

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 :)

HelloNurse|7 years ago

Many projects have often predictable periods of intense testing and bugfixing without new feature development.

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.