How to Handle Production Emergencies Within Ongoing Sprint?
Coaching Conversation: A step by step walkthrough of a particular problem
Hello 👋, It’s Vibhor. Welcome to the 🔥 paid member only🔥 edition of Winning Strategy: A newsletter focused on enhancing product, process, team, and career performance. Many subscribers expense this newsletter to their Learning & Development budget. Here’s an expense template to send to your manager.
Q: I could use your guidance on something that keeps tripping up my team. We regularly have stories that spill over into the next Sprint. The Product Owner insists on keeping Sprint goals intact, but halfway through the Sprint new high-priority items pop up which PO supports and the team feels pressured to take them in. This is causing missed commitments, and frustration. How can I help the Product Owner and stakeholders respect the Sprint boundary without damaging relationships?
This post is a walkthrough of a coaching conversation I had with a mentee who asked the above question and how we arrived at a solution.
If your team faces similar challenges, this post will help you:
Understand why these situations occur
Set boundaries that work for both the team and stakeholders
Handle emergencies without affecting the Sprint
Also…
It will help you learn how to hold a coaching conversation (though that’s not the focus of this post).
Let's get started.
If you’re new, here’s what you missed in the last few weeks
How do I usually structure coaching conversations?
I keep things simple and focused.
First, I ask a few clarifying questions to truly understand what’s happening, not at the surface, but underneath. I listen and write down the answers. This helps both of us see the situation clearly.
After I have the details, I pause and try to make sense of the whole picture.
Then I suggest a way forward. I never prescribe a solution right away. My goal (always) is to co-create next steps.
For the given problem, I asked the following clarifying questions.
Clarifying Question #1
What is the typical length of your Sprint, and how often do high-priority items get pushed in during that time-box?
Knowing the Sprint length (1 week vs. 4 weeks) and the frequency of interruptions (once per Sprint vs. every other day) will help me determine whether the problem is an occasional emergency or if it is an issue with prioritization.
Answer I got:
“Sprints are two weeks. We get surprised by new work almost every Sprint, usually around day 5–6.”
Hmm…
Clarifying Question #2
What kinds of “high-priority” items get inserted?
a) True production emergencies (like system outage, security patch)
b) Last-minute business opportunities (like “Marketing needs this small tweak for tomorrow’s launch”)
c) Regular backlog items that someone suddenly wants sooner
Different types of interruptions require different types of handling. Production outages may justify a special “expedite” lane, whereas sudden reprioritizations typically indicate backlog or stakeholder alignment issues.
Answer I got:
“Almost all are genuine outages. Our app goes down, and we must fix it.”
Interesting…
Clarifying Question #3
How does the team currently handle a production outage when it happens?
a) Is there an on-call or support rotation that jumps on the fix while the rest of the team keeps working?
b) Or does the whole team stop Sprint work and swarm on the incident?
c) Do you log the fix as a separate ticket and count it inside the Sprint, or track it elsewhere?
Understanding the existing incident response setup will tell me whether the real issue is a lack of dedicated support, missing capacity buffers, or simply how the work is being documented.
Answer I got:
“We have no rotation. Everyone stops what they’re doing, and we create a ‘critical bug’ story in the Sprint.”
Ok…
Clarifying Question #4
Roughly how much effort do these production outages consume during a typical 2-week Sprint?
Example scale: “1–2 hours,” “a full day,” “3–4 days,” etc.
And how many separate outages occur in that period?
If outages regularly eat, say, 20% of the team’s time, we can plan for that capacity instead of pretending it doesn’t exist.