Everything’s green. Final test cases? Passed. Launch date? Just days away. And then—an email drops in: “Can we quickly add this small change before go-live?” “Can we quickly add this small change before go-live?” Classic. Whether you’re a BA, Product Owner, or Scrum Master, you’ve likely seen this movie before. The team is ready to ship, and suddenly, a late-stage request throws a wrench in the works. The ask usually sounds simple. But small changes—especially late ones—rarely are. Now you’re stuck navigating the usual tension: Say yes, and you risk introducing bugs or pushing timelines.
Say no, and you risk disappointing stakeholders or leadership. Say yes, and you risk introducing bugs or pushing timelines. Say no, and you risk disappointing stakeholders or leadership. Welcome to the eleventh-hour curveball. 🎯 First: Pause and Clarify the Ask Not every last-minute request is unreasonable—but they do deserve scrutiny. Before jumping into reaction mode, get clear on the basics: What exactly is being requested?
Why is it surfacing now?
Is it a go-live blocker or just a nice-to-have? What exactly is being requested? Why is it surfacing now? Is it a go-live blocker or just a nice-to-have? Sometimes, the real ask is buried under the urgency. A request to “rework permissions” might turn out to be a minor copy update or a clarification in messaging. Understanding the intent behind the change can de-escalate stress—and help the team respond proportionately. 🛑 Treat It as Triage, Not Sprint Planning This isn’t the time to treat a change like a regular backlog item. Think like an ER nurse, not a delivery pipeline: Is it critical to user experience or compliance?
Can it be deferred safely?
What are the risks of accepting or rejecting it now? Is it critical to user experience or compliance? Can it be deferred safely? What are the risks of accepting or rejecting it now? Agile teams are built to be responsive, but that doesn’t mean absorbing chaos. It means making smart, time-sensitive calls with shared visibility. ⚖️ Make Trade-Offs Transparent When pressure mounts, teams sometimes default to “yes” to avoid conflict. But that can backfire. Instead, reframe the conversation around impact: “We can include this change, but it could delay go-live by a few days and reduce time for QA. Would you like to proceed with that trade-off?” “We can include this change, but it could delay go-live by a few days and reduce time for QA. Would you like to proceed with that trade-off?” Framing it this way: Keeps decision-making collaborative
Highlights the cost of change, not just effort
Encourages prioritization instead of escalation Keeps decision-making collaborative Highlights the cost of change, not just effort Encourages prioritization instead of escalation In many cases, just showing the implications is enough for stakeholders to reconsider or adjust scope. 📌 Offer a Post-Go-Live Plan Saying “not now” doesn’t have to feel like rejection. If the change isn’t feasible before launch, offer a specific plan to address it after go-live: Include it in the backlog with a clear label (e.g., “post-launch enhancement”)
Review it during the next refinement or planning session
Tie it to versioning: “Let’s consider this for v1.1.” Include it in the backlog with a clear label (e.g., “post-launch enhancement”) Review it during the next refinement or planning session Tie it to versioning: “Let’s consider this for v1.1.” This shows accountability without compromising stability. 🔁 Learn, Adjust, Repeat Retrospectives are the perfect time to unpack why last-minute requests happened in the first place: Were acceptance criteria clear?
Were key stakeholders involved early enough?
Was the sign-off process too open-ended? Were acceptance criteria clear? Were key stakeholders involved early enough? Was the sign-off process too open-ended? With each delivery, Agile teams can improve how they handle the unexpected—whether through stronger pre-go-live gates, clearer communication, or better backlog hygiene. Final Thought Last-minute changes aren’t a failure of planning—they’re a reality of delivery. What matters is how teams respond. The goal isn’t to eliminate curveballs—it’s to create systems that absorb them without derailing progress or burning out people. So when that urgent ping arrives just before launch, don’t panic. Don’t shut it down. And definitely don’t take it personally. Pause. Clarify. And say: “Let’s talk about the trade-offs.” “Let’s talk about the trade-offs.” Because that’s what agility really looks like when the pressure’s on.

This story contains new, firsthand information uncovered by the writer.

🧠 The Most Underrated Skill in Agile Teams? Critical Thinking

Surviving the Eleventh-Hour Curveball in Agile Delivery

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Agile is Chaos. But There’s a Way Through.

The Noonification: The Future of DeFi - Emerging Evolution (11/3/2022)

10 Ways PMs Can Earn The Respect and Trust of Their Team

10 Terms Every Engineer Must Know

10 Subtle Superpowers of DevOps

10 Product Development Traps

Agile is Chaos. But There’s a Way Through.

The Noonification: The Future of DeFi - Emerging Evolution (11/3/2022)

10 Ways PMs Can Earn The Respect and Trust of Their Team

10 Terms Every Engineer Must Know

10 Subtle Superpowers of DevOps

10 Product Development Traps

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps