Three Options When the Boss Changes Priorities Mid-Sprint

So your boss comes to you mid-sprint and demands a new oscillating-email-ingest-engine. Right now. Nothing else is higher priority.

Scrum says “Say no”. I think the discussion is more nuanced.

This question is about Agile Change Management. Really there are three options if the Product Owner or some other manager tries to add a new item mid-Sprint:

  1. Just say “No”
  2. Terminate the Sprint
  3. Trade off Requirements to Make Room

What you must not do is just say “Yes”. The common element of all of this is that change during a Sprint will invariably cost the development team time and hence the customer money. Some work will have discarded; that might be the time spent planning something else or partially complete work. Something gets thrown out. The Product Owner has to be aware of this implication and accept the responsibility for the waste created by their decision.

1. Just Say No

The starting point for Scrum is just say “No” (Schwaber & Beddle, 2002). Nice and clean and prevents waste. But it might not work. It is kind of a nuclear war strategy. Scrum Master and boss go head to head and arguing with the boss can be career limiting.

2. Terminate the Sprint

If the Product Owner insists then the team are meant to terminate the Sprint and replan (Schwaber & Beddle, 2002). If the above is nuclear war then threatening to terminate the sprint is a nuclear deterrent. You can see it play out like this. Boss says “Just do it” and Scrum Master says, while shaking their head …

Well, okay, if you insist. That means I’ll cancel the rest of this sprint. We’ll forget about the release you were hoping for next week. We’ll probably have to throw away the code we’ve written as it is only partially complete and will interfere with the new stuff you’re looking for. I’ll book a sprint planning meeting for latter today; are you available?

It would take a hard Product Owner to continue doggedly demanding the new feature in the face of this.

3. Trade off Requirements to Make Room

Personally I prefer a more reasonable conversation. I start with “can it wait?” and usually it can. But if not I outline the impact of adding something – including wasted work – and the need for requirements trade-off to make room for the new thing. And that conversation often leads to a “Um, in that case I’ll wait” response. But if the new item remains top priority, and the product owner can bear with the cost of introducing it, then I’ll go ahead. That may or may not need significant replanning. It depends.

This post is part of my What do I do When … ? series. Please drop me a line or add a comment if you’ve got a question you’d like answered.


Schwaber, K., & Beddle, M. (2002). Agile Software Development with Scrum. NJ: Prentice Hall.