Key Takeaways

1. Disruption isn't a failure. It's a signal. Don't think of disruptors as a failure of Agile or your team's work. It just is. How you respond determines whether you maintain predictability and trust with stakeholders.
2. Disruption is consistent, not rare. Teams often treat disruption like bad weather that will pass. But the data tells a different story—if you let stakeholders disrupt once, they'll continue to disrupt more. This becomes your new normal.
3. Predictability erodes before delivery stops. Teams rarely go from fine to nothing delivered. Instead, commitments slip, forecasts feel shaky, and stakeholders stop believing plans—even while output continues. By the time delivery truly stops, trust is already gone.
4. Invisible decisions are still decisions. Every time a team absorbs a disruption without discussion, they're choosing not to do something else. Even "just 5 minutes" ten times a day adds up to 50 minutes of lost planned work.
5. Facilitate decisions, don't absorb impact. When disruption exceeds capacity, your job is to facilitate a decision with stakeholders, not to absorb the impact yourself. Don't say yes and burn out your team with 60-hour weeks.
6. Bring data, not opinions. The facts will set you free. Use say-do ratios instead of story points when talking to stakeholders—they understand "we committed to X and delivered Y" better than abstract point values.
7. Frame choices, don't say no. Instead of "we can't," try: "If we take on this new work, which current item should we pause?" This empowers stakeholders to make priority decisions themselves.
8. Firm doesn't mean harsh. Firm means clear, factual, and respectful. Kind doesn't mean deferential—it means inclusive, empathetic, and transparent. You can be both simultaneously.
9. Drop the minimizers. Words like "just," "kind of," "I think," and "I feel like" undermine your credibility. Instead of "I think the team is at capacity," say "The team is at capacity based on this sprint's commitments."
10. Replace apologies with gratitude. Instead of "Sorry, but we don't have capacity," try "I appreciate your understanding—we don't have remaining capacity this sprint." You didn't do anything wrong, so don't apologize for constraints.

Full Transcript

Introduction

This presentation came about because we had a client who was having a really hard time managing stakeholder expectations. They work in an Agile-ish environment—water-agile-fall, is what I like to call it—and they are trying to figure out how to set expectations with their stakeholders and hold lines with them. And make sure that it is a collaborative decision instead of just telling their stakeholders no. So that's really where this all came from, and what we discovered is lots of people are experiencing that out in the world.

Why This Matters

I don't want you to think of disruptors as a failure of Agile, or a failure of your work or your team's work. It just is. It's a signal from the system, from the environment around you, and how we respond determines whether or not we have predictability in our teams and trust with our stakeholders. So if we can get good at managing stakeholder expectations well, then we increase trust.

Defining Disruptors

We're going to define disruptors in two buckets. Planned doesn't necessarily mean small, it just means we expected it. It's not something that was new delivery—it was probably keep-the-lights-on work, some sort of maintenance. There's a group I work with that's in HR, and every month they have to do a payroll update. Those sorts of things are planned maintenance, keep-the-lights-on kind of work.

Unplanned is what breaks our predictability. That's where we get our unexpected requests, production outages, priority shifts mid-cycle, that dependent team that said they were going to be available and then wasn't.

Reading the Data

Let's look at what that data looks like over time. On top, we see the percentage of planned work, and this team built in a 20% buffer for their planned disruptions. Then there's their reality—they had this much percentage of unplanned work. Which means their total overrun gets higher and higher as we go along.

If we had stayed to the original planned scope and planned completion, we would be further ahead than where we are now on our actual completion. That's ultimately the impact of disruptors. You can see by the velocity chart, this team is delivering every sprint. It's not that they're not doing things—it's that their planned work is getting disrupted in a way that makes it impossible for them to deliver on the original plan.

The 80% Maintenance Trap

Once upon a time, I worked with a team that was supporting 27 internal products while trying to write a product that would sunset several of those. When we did the math, they were doing 80% maintenance work on those 27 products and just didn't have space for the new delivery that people were expecting.

The team was getting all kinds of bad press because they weren't delivering, when what was true is that they were delivering on stuff that needed to get done—production and maintenance and those sorts of things. But they just couldn't do the new delivery.

When we were able to give that data to leadership, leadership went, "Oh. We're the problem, got it." So they hired a vendor team to handle maintenance of the existing products, which took a few months of training. Then they were handling the maintenance so that team could focus wholly on the new delivery of the replacement system. And then suddenly they were delivering.

This kind of data really sends the message: it's not that we're not delivering. It's that we're not delivering what you were expecting us to.

Three Key Insights

First, disruption is consistent, not rare. Often what you'll see is teams or leadership treating disruption like bad weather, something unusual that will pass if we just wait it out. But the data tells a different story, and my experience is that if you let your stakeholders disrupt once, they'll continue to disrupt more.

If you say, "Okay, we'll let it pass this time," well, next month they're gonna go, "You took it in last month, why won't you take it in this month?" Teams keep hoping next sprint will be "normal," but this becomes your new normal when you allow disruption in.

Second, predictability erodes before delivery stops. This is a really important pattern to recognize. Teams rarely go from fine to nothing delivered. Instead, the commitments slip, the forecasts start to feel shaky, the stakeholders stop believing plans—even though output is happening, it's not the output they wanted.

By the time delivery truly stops—when you're at 80% keep-the-lights-on—confidence and trust are already gone. As soon as you start seeing signals of eroding trust, you want to look more closely and figure out how to change the trajectory.

Third, decisions are happening, just not transparently. There's a disruptor that comes in, and the team decides to work on it. Maybe it's happening, but people aren't understanding the impact of that decision. Not making a decision is also a decision. Not choosing one action is choosing to do something else, even if it's nothing.

From Disruption to Decision

When disruption exceeds capacity, your job is to facilitate a decision, not to absorb the impact. Anybody who's had children knows what this is like. Eventually, you burn out. There's only so much you can do. The last thing we want is for the teams to crack. Don't absorb the impact. Instead, take a step back.

The Four-Step Framework

First, bring the data. I like to use say-do ratios instead of points when I bring data to stakeholders, just because points become muddy for them. They're like, "What do these points mean?" Unless your stakeholders are fully trained on Agile, they're going to get confused. A say-do ratio works better: we said we were going to do this much work, we did this much work, what's that percentage? Here's the percentage that was planned new delivery, planned disruption, and unexpected disruption.

Second, frame the choices. "If we take on this new work, which current item should we pause or move to the next sprint?" This lets them be empowered to make a decision about priority. They might look at the five or so things in your sprint and go, "Oh, I don't want this to come above any of those. Let's put this new thing in the next sprint instead."

Third, co-create priorities. "If we absorb this disruption, predictability drops by 20%. Are you comfortable with that trade-off?" Or, "Saying yes here means pushing out this feature to next month. Does that align with our priorities?"

Fourth, communicate the trade-offs. "It sounds like we agree this can wait until next sprint so we can finish current commitments. Would you prefer we adjust the buffer next cycle to allow more flexibility?"

Softening the Blow

These phrases can be scary the first time you say them, so here are some ways to ease into it: "I know this will be uncomfortable to hear." "I'd rather tell you the truth than disguise it and disappoint you later." "Help me understand what's most important to you, so I can help you make the best decision for our team and our delivery."

Another one I really love is, "I don't want to make this decision on your behalf. I want to make a decision we both are aligned to and can agree on." That way, when we've got to communicate this to other people, we can be in each other's corner.

The Do's and Don'ts

Definitely bring data, not opinions. I had a mentor in my early career say, "The facts will set you free." Make the trade-offs visible—if we do this, then this is the impact. And validate priorities together: "You told me this was the most important, and now you're telling me this is. What's true? If I could only do one, which one would you choose?"

Don't hide reality. Hiding reality is another form of lying, and we want to deal in truth. Remember, our fourth Agile value is responding to change over following a plan. You can't respond to change if you don't know what's changing.

Don't say "we can't" without context. Say things like, "We can't unless this other thing happens," or "We can't if we continue down this path."

And don't over-commit to keep the peace. Don't say yes and make your teams work 60-hour weeks. That will burn them out, and then you'll get even lower productivity in the future. We have an Agile principle on sustainable delivery—let's not let go of it.

Language That Builds Trust

I want to point out that firm does not mean harsh. It means clear, factual, and respectful. And kind does not equal deferential. We're not submissive, we're not weak in our appearance. Kind means inclusive, empathetic, and transparent.

On the firm side: use data and commitments, name the trade-offs, and pause after making a statement. Make a sentence, ask a question, and then in your head, do a slow count of 10. Maintain eye contact and wait to see what they say. It's amazing what people will put in space when you give it to them. It's a coaching technique—those of you who are coaches know it deeply.

On the kind side: lead with empathy. "I understand you seem really nervous about this potential conversation. How can I help us be successful?" Involve them in the decision. "Are you willing to have this conversation with me? Do you want to practice it first?" And acknowledge shared goals: "I also want to be successful with the client. The whole company succeeds when we succeed."

You want to make it us against the problem, instead of you versus them.

Words to Eliminate

Watch out for minimizers like "just" or "kind of." If you're a woman and you've been through any training on how to be heard in a meeting, these are words you've been trained to stop saying. But it's not just for women—everybody can drop them and just state the facts plainly. Move from "I just wanted to check if we could" to "I want to check whether we should."

Move away from false uncertainty like "I think" or "I feel like." When we frame observable data as opinion, we invite debate and remove our credibility. Instead of "I think the team is at capacity," say "The team is at capacity based on this sprint's commitments."

Watch out for escape hatches like "We'll try" or "We'll see what we can do." Instead of "We'll try to fit it in," say "If we take this on, something else will move."

And break the apology habit. "Sorry, but we don't have capacity"—you didn't do anything wrong. Don't apologize if you've not done wrong. Instead, remove the apology and lead with clarity: "We don't have remaining capacity this sprint." It's just a fact.

Breaking the Apology Habit

There's a trick to untraining the apology habit—when you're about to say sorry, start to say thank you instead. So "Sorry, but we don't have capacity" becomes "I really appreciate your understanding of our limitations. We don't have capacity."

Dealing with Being Called "Negative"

Once upon a time, in most of my career, I've been accused of being "negative." Negative is not true. Negative would be "the sky is falling, chicken little, we always fail, blah blah blah." The data saves you.

Say, "Look at our empirical evidence. This is how much we can complete in a sprint. This is all we can do. What you're asking me to do is more than we can accomplish, and I don't think that's fair to our team, or to you, or to our clients. So what I want to do instead is to choose which item is less important than this item you're asking for, because I want us to be successful."

That "because I want us to be successful" is how you shift from being perceived as Negative Nelly to showing you're really on their side. "I want us to be successful, but we have some realities we need to face."

On Risk Management

There is a risk if you commit to more than you can accomplish regularly. In Agile, we tend to address risk as we go along instead of making it a big extra special thing like traditional project management does. Project managers are really good at identifying risks, and you can use data from past projects to identify risks to timeline and build that into your plans. It's called a risk-adjusted backlog—you would actually build stuff into your backlog that deals with risk, like planned disruption buffers.

On Difficult Cultures

It's really hard when the culture is not set up well for honest communication and discussion. My niche area is shifting those cultures, and it starts with leadership. The place I like to do coaching and consulting the most is in the leadership groups to fix what's broken in the culture—so that people feel safer to say the things that are hard to say, and know that they're going to be met with collaboration instead of retribution.

But it can be really hard if you don't have control over those humans. The thing you have the most control over is getting to good data. Even if your leadership isn't comfortable with you talking about those kinds of things with clients, you can say, "This is the thing I'd like to say to the client, here's the reason why. How can you help me with the client so we can collaborate with them instead of disappointing them?"

Now you've got a leader in your corner, helping you fight the battle of reality.

Final Thoughts

As a customer of people, I would rather have the truth and know it's gonna be late. Having a contractor come to me 2 weeks before the house is done and telling me it's going to be 3 more months is not where I want to be. I want to know 6 months before the house is supposed to be done that we're probably not going to hit target.

The only thing we do is undermine trust with our clients when we lie to them about what's possible.

If You Enjoyed Learning with Jessica...

She teaches several of our most popular courses:

Agile Project Management — Master the fundamentals of leading Agile projects, from sprint planning to stakeholder communication. Earn PMI PDUs.

AI for Project Management — Learn how to leverage AI tools to enhance your project management practice and boost team productivity.

Product Ownership — Build the skills to prioritize effectively, manage backlogs, and facilitate the kind of stakeholder trade-off decisions discussed in this webinar.