Scrum in the books and Scrum in the real world? They can feel miles apart sometimes. On paper, the framework is clear about how we work: every sprint delivers something valuable, with each backlog item hitting the Definition of Done before it’s released. We aim to maintain quality and avoid pushing out anything half-baked.

But then, reality hits. There’s a big product demo in three days. Or a quarter-end financial deadline barrels down on you. Maybe a critical competitor feature just dropped, and suddenly stakeholders are scrambling for you to match it, even if that means cutting some corners. In these moments, the pressure to drop Scrum principles and get something—anything—out the door is very real.

So, how do you balance that ideal world of Scrum with the real-world pressures from the business? Is there ever a time to break those rules and release unfinished work? Let’s untangle the mess and figure out how to handle this tension.

First off, you have to acknowledge that stakeholder pressure is simply part of the mix; it’s not inherently bad. Stakeholders want the business to succeed, and their sense of urgency often reflects valid priorities. Where it can go sideways, though, is when stakeholders think they understand the product’s readiness, but don’t have the whole picture. This is where transparency plays a huge role.

If you’re getting pressured to release something before it’s truly done, the first and best thing you can do is pull the stakeholders closer. Open up that dialogue—talk through the current state of the work. What exactly will happen if you push this feature out now? Be explicit about the trade-offs: maybe performance is shaky, or testing has been light. By communicating exactly what the known risks are, you give stakeholders the tools to gain a more complete understanding. Scrum values transparency for a reason—it helps everyone make smarter decisions, especially in tricky business situations.

But let’s not pretend every situation is the same. Sometimes, it’s genuinely worth considering a release that’s less than perfect. Think about it: if the feature in question is mission-critical for a product launch, or releasing it now provides high value to users with minor additional fix-ups planned later, then allowing a limited or even “unfinished” release might make sense for the business. But this should be the exception, not the rule. Scrum never says you can’t release if something isn’t 100% perfect—taking small but functional chunks to production is, in fact, part of the Agile mindset. But when you’re thinking of releasing true “unfinished” work—meaning, items with high known risks or potentially disruptive impacts—you’ve got to really own the decision-making process.

Take for example a team that I once coached: they were gearing up to demo a new feature at a major industry conference. It wasn’t ready according to their Definition of Done—the final integrations and performance tests hadn’t been run yet—but pulling out of the demo wasn’t an option. After carefully assessing the risks and discussing openly with stakeholders, they released a scaled-back version of the feature, while being transparent about the limitations. Yes, there were some bumps, but in this case, the business’s need outweighed the risks. The key wasn’t in bending to pressure; it was the thorough communication that allowed everyone to move forward with eyes wide open.
Now, on the flip side, there are times when you should absolutely push back. If you know releasing unfinished work is going to create more headaches than it solves, you owe it to the product, the team, and the stakeholders to make that clear. And that’s where the Scrum values come back into play—especially courage. Having the guts to say, “This isn’t ready yet, and releasing it now will do more harm than good,” isn’t easy. But it’s what responsible teams do to protect the quality of their product and their own workflow.

Let’s talk about what happens when you don’t push back. I’ve seen teams agree to release sloppy work just to satisfy a deadline or to avoid a tough conversation. What usually follows is a mountain of support tickets, long nights fixing critical bugs, diminishing trust from customers, and a team that’s demoralized because they’re no longer building—they’re firefighting. And it’s not just short-term pain. The more rushed, low-quality work you push out, the more technical debt you accumulate, and that stuff has a nasty way of coming back to choke any real progress you want to make later.

This is why it’s so essential to set expectations early, especially with non-technical stakeholders who might not grasp the full ramifications of launching an unfinished product. You want them to understand that rushing something to release doesn’t make the problem go away. It just transfers it from today to tomorrow—and worsens it along the way.

Sometimes, you need to facilitate these tough conversations between the team and the stakeholders. You’re balancing business needs with product integrity, but it’s not about drawing a hard line every single time. It’s about being transparent: what’s at stake now, what’s to be gained (or lost) by waiting, and how much risk the business is willing to accept. The decisions don’t just come down to “scrum says no!”—they come from a place of educated trade-offs, where everyone’s eyes are open to the consequences.

Another tool that can help here: incremental releases. If there’s intense pressure to get something in front of users or stakeholders, but the team isn’t quite ready to release the full scope of the work, consider an MVP (Minimum Viable Product) or even a beta release. This allows you to deliver some value while still holding off on the rougher edges. The key, of course, is making sure those incremental releases still meet your quality standards—after all, no one wants technical debt disguised as progress.

One team I worked with faced a huge decision like this just before a major trade show. There was a strong push from leadership to get a new feature live in time for the event, but the developers were upfront about the state of it: the feature was still unstable and had several bugs. The compromise ended up being showing a demo version at the trade show, while continuing to refine the real product for a proper release afterward. Transparency during that conversation made all the difference. The stakeholders knew what they were getting, and the development team felt they had the space to fix the known issues before any real users touched the feature.

Handling these moments with integrity doesn’t just protect the product—it creates trust. When stakeholders see that you’re making decisions grounded in data and transparency, they’re more likely to trust your future recommendations. Nobody wants to be that team known for “just saying no” to everything, so finding that balance between business need and product readiness is crucial. It’s not about hiding behind Scrum or rigid definitions; it’s about being responsible stewards of both the product and the business relationships.

In the end, Agile—and especially Scrum—exists to help us navigate challenges like these. The world is always moving, business needs are always evolving, and your backlog will never be empty. But by sticking to the core principles, while also understanding real-world business demands, you give yourself the space to make thoughtful decisions.

Remember, the sprint isn’t just about what gets done in the moment—it’s about setting the team up for sustainable momentum. Sometimes, that means saying yes to an urgent release, but often, it means telling the stakeholders, “Let’s wait just a little longer.” And that’s not something to apologize for—that’s Scrum working exactly as it should.