In a Scrum environment, developers are often in the spotlight to deliver faster, ship sooner, and keep the wheels moving. But when you zoom in on quality, who really gets to decide if something is ready for release? It’s easy to assume that stakeholders—those investors or executives—hold the final say. After all, they’re the ones waiting on delivery. But let’s clear this up from the start: it’s the developers who carry the responsibility for maintaining quality. They’re the folks in the trenches, writing the code, testing the features, and ensuring that what leaves the team’s hands is something they can stand behind.

The tricky part? Developers can often feel pulled in multiple directions. On one side, there’s the ticking clock, stakeholder demands, and the pressure to deliver on ambitious timelines. On the other, there’s the voice of reason insisting that quality can’t be compromised, even if it means pushing back a release. This tug-of-war can lead to some uncomfortable moments—especially when team members feel pressured to let something go live before it’s fully ready.

Stakeholders obviously prioritize getting value sooner, which makes sense from their perspective. But it’s vital that this doesn’t result in unfinished or half-baked Product Backlog Items (PBIs) being pushed out the door. The Scrum framework is pretty clear on the idea that only done work gets released. Yet, in real-world scenarios, the pressure to bend that rule can sneak in. Maybe it’s a looming executive demo or a promised feature date. Whatever it is, those external pressures can sometimes leave developers in the tough position of pushing back for the sake of quality.

Here’s where the Scrum values of courage and respect come into play. Courage doesn’t just mean standing up in front of the team and saying, “Hey, this isn’t finished yet.” It’s the ability to defend the quality of the work, even in the face of uncomfortable conversations with stakeholders. Respect, on the other hand, is about recognizing that developers are the experts when it comes to assessing whether the product meets the standards—not just in functionality, but in security, performance, and usability. They’re not just being picky or dragging their feet; they’re protecting the long-term health of the product and, by extension, the reputation of the business.

Now, this doesn’t mean that developers shouldn’t engage with stakeholders about the progress. In fact, transparency is key. The team should never be operating in a vacuum, leaving stakeholders in the dark about what’s happening. But part of that transparency involves honest conversations about what is and isn’t done, and why certain PBIs aren’t ready yet. It’s about creating a dialogue that says, “We’re not just building fast; we’re building smart.” A mature Agile environment makes openness a habit—where the team regularly shares not only what’s going well but also what’s still a work in progress and might require more time.

That said, the responsibility for maintaining quality shouldn’t rest solely on the developers’ shoulders without the support of leadership. It’s one thing for a Scrum team to push back on a pressured release; it’s another when they’re backed by a culture that prioritizes quality. If leadership sets the tone that protecting the integrity of the product is more important than delivering on arbitrary deadlines, you’ll find teams are more empowered to speak up when something doesn’t meet the definition of done.
Building on the idea of quality ownership, we have to acknowledge a reality in Agile environments—there’s often an unspoken tension between what stakeholders want and what the reality of the product says. Stakeholders may have urgent needs, whether to stay competitive or meet a promised delivery date, but shipping work that isn’t up to standard ends up costing more in the long run.

I’ve seen this play out in too many scenarios where work is shipped early in an attempt to please stakeholders, only for it to backfire down the road. Bugs spring up everywhere, users complain, and suddenly the team is consumed with maintenance rather than working on new features. This pulls focus from true product development, which in turn frustrates stakeholders even more. At the end of the day, releasing half-baked work doesn’t save time—it steals it.

One of the toughest things for developers? Navigating these pressures while living up to both their technical expertise and the Scrum values—and it’s here that a solid Product Owner can make a world of difference. A skilled Product Owner acts as a buffer, managing stakeholder expectations while fully trusting the developers’ assessment of quality. These conversations between the Product Owner, stakeholders, and the development team should be based on mutual respect and a shared goal: delivering the best product possible in a viable, sustainable way.

It helps, too, when Scrum Masters champion the idea of quality and reinforce the team’s responsibility. While the development team is accountable for what’s going out, that doesn’t mean they’re on an island. Scrum Masters should be helping to create an environment where developers feel safe to push back on rushing work and where stakeholders fully understand the long-term benefits of prioritizing quality in every sprint.

Yet even with all the right support, developers have to own their expertise unapologetically. When faced with the decision of “do we release it, or do we hold?” they need the confidence to say, “we’re not done.” And that’s not always about perfectionism—it’s about meeting an agreed-upon level of quality that everyone trusts will ensure the product is stable and usable for customers. Remember, Scrum teams define a Definition of Done for a reason—to signal when a piece of work is genuinely complete, based on collective standards the team has committed to.

It’s worth saying, though, that accountability doesn’t mean the team hides behind the excuse of “it’s not perfect.” Agile favors progress over perfection, sure, but it also values transparency and honesty. If developers believe something is good enough for users but is lacking in a non-critical area, it’s their job to communicate that risk clearly and openly. This gives stakeholders the opportunity to factor that risk into the overall decision-making process but still allows developers to maintain their ownership of the product’s quality.

Ultimately, empowering developers to make decisions about quality isn’t just about technical skill—it’s about creating a culture that respects the craftsmanship. That’s why both courage and respect are so essential here. It takes courage for developers to stand by their decisions, especially when the pressure’s on. And it takes respect from all parties—developers, Product Owners, Scrum Masters, and stakeholders—to understand that not releasing something isn’t failure, but a choice made in the interest of the product’s integrity.

So, who decides quality? The developers do, on behalf of the entire Scrum team. They’re in the best position to judge when something meets the criteria of being done. By empowering them to take this point seriously, organizations shield themselves from the damaging effects of low-quality releases. Done right, everyone wins—stakeholders get a product that works, developers take pride in what they built, and end users benefit from fewer headaches.

Let developers do what they do best: deliver quality. They’ll ensure the product shines and that, in the long run, the team doesn’t drown in technical debt or maintenance quagmires. So, the next time the pressure starts building to release something prematurely, remember—let the people closest to the product make the call. They’re in the best position to decide what’s truly ready to ship.