The top 3 complaints that I hear about from my students and have seen with teams I have supported:
Dependencies (we covered this in the first installment in the series)
Pressure from stakeholders to take on work regardless of capacity
Unclear requirements
Do these sound familiar to you? We are going to focus on Stakeholder Pressure
See if this sounds familiar. Your Product Owner shares the Vision again (because they should be sharing that continually) and then shares the Product Goal. The team is focused and ready to figure out how we can make some progress on getting closer to achieving the goal.
The Developers bring in the Product Backlog items they can get done during the Sprint… challenging themselves to really go for it! We have a Sprint Goal that we can rally behind and see the purpose behind the work we are taking on. Everything is perfect. We leave with an awesome plan.
The next day, our Product Owner walks in with a stakeholder who has an “urgent request”. The expectation? Bring in this urgent item AND still accomplish our Sprint Goal, completing all of the planned PBIs.
Just like last time, let’s go ahead and do a reality check. You are going to have urgent items pop up. We know the usual suspects: production support issues, cybersecurity, legal, and compliance. Sound familiar? However, this should be the exception, not the rule.
The other kinds of disruptions we see are new ideas, changes to ideas, and other non-urgent changes. If we absorb change on the whims of our stakeholders, we jeopardize our goal or work at an unsustainable pace. If we ignore insights and feedback from stakeholders, we lose that way too. So, what to do?
Make the trade-offs explicit and transparent.
When that urgent request hits, the first thing I do is step back and ask: is this change so massive that our current Sprint Goal is basically obsolete? We're talking the company gets acquired, the key customer pulls out entirely, or regulatory changes wipe out the entire product direction. This is rare. Ninety-nine times out of a hundred, the answer is no—the Sprint Goal still holds value.
Assuming the Goal survives (which it usually does), I take it straight to the team. The people doing the work get the first say in what could give. We huddle quickly for five to ten minutes and look at the plan we committed to. What could we remove, defer, or shrink while still delivering something meaningful toward the Goal?
We're not talking about working extra hours, pulling weekends, or "just push harder." Those aren't trade-offs; they're burnout recipes. We're talking about real impacts: dropping a lower-priority PBI, thinning scope on a feature, or postponing a nice-to-have so the core value lands.
Once the team surfaces the realistic options, the Product Owner brings that back to the stakeholder. We lay it out plain: "To fit this in, we drop X or reduce Y. Here's what that means for the Sprint Goal and the value we're delivering." The PO makes the final call—it's their accountability—but the conversation is transparent. Everyone sees the cost. No hidden assumptions.
Capture the change right in the Sprint Backlog so it's visible to everyone. Update the items, adjust the scope, and note what got dropped or deferred. Then capture why we made the trade and where the change came from. A quick comment does the trick: "Added urgent compliance item at stakeholder request from Legal; deferred PBI Z to maintain Goal." That way, over time, you can spot patterns.
Is this the same stakeholder who’s dropping requests during every Sprint? Are certain types of "urgent" items always winning out? Are we consistently deferring the same kinds of work? Those insights turn one-off decisions into data that feeds better conversations, stronger boundaries, and maybe even a policy tweak down the line.
This approach keeps the Sprint meaningful, respects the team's capacity, and builds trust with stakeholders. They start to see that saying "yes" to everything really means saying "no" to something else—better to choose it together.
So next time an "urgent" request lands, try this. Make the trade-offs visible with the team first, then transparent with the stakeholder. See what shifts. You might be surprised how much more stuff gets done... the stuff that actually matters.
In Part 3, we'll tackle unclear requirements—the third big blocker I hear about all the time. If you're ready to get unstuck on any of these, reach out to Improving. We've helped teams make these changes stick.
