Who Is Responsible For Quality In A Scrum Team?

The Developers are accountable for quality in Scrum. It is one of their four stated accountabilities: instilling quality by adhering to the Definition of Done. There is no QA role, no tester accountability and no quality gate owned by anyone else. The Scrum Guide is also explicit that quality does not decrease during a Sprint, which makes it the one thing that cannot be traded when a Sprint gets tight.

Key Highlights

• Quality sits with the Developers, and the mechanism is the Definition of Done rather than a person or a phase.
• Scrum defines no QA or tester role. People with testing skills are Developers, and the accountability is collective.
• The Product Owner cannot lower the Definition of Done to fit more work in. Scope is negotiable; quality is not.
• The Scrum Master supports quality by protecting the Definition of Done and surfacing pressure, without owning the outcome.
• Testing at the end of a Sprint is the most common structural failure, and it recreates the handoff Scrum removes.
• If work does not meet the Definition of Done, it is not part of the Increment and does not go to the Sprint Review.

The Precise Answer

Scrum lists four accountabilities for the Developers. They create the Sprint Backlog, they instil quality by adhering to the Definition of Done, they adapt their plan each day toward the Sprint Goal, and they hold each other accountable as professionals.

Quality is the second of those, and the wording is worth noticing. It does not say the Developers test the work or that they check quality at the end. It says they instil it, and the mechanism given is adherence to an agreed standard.

Beyond that, the Scrum Team as a whole is accountable for all product related activities, which the Guide lists as including verification, maintenance, operation, experimentation and research. Verification is named explicitly. It is not a separate function that happens to someone else.

So the short answer is the Developers, and the fuller answer is that quality is built into how the work is done rather than inspected afterwards by anyone.

If you are working through the accountabilities and want to check your understanding, our free CSM practice test covers them in a few minutes.

What Each Accountability Does and Does Not Do

Clear boundaries prevent most of the arguments that arise here.

The Developers. Accountable for quality. They decide how the work is built, they apply the Definition of Done, and they collectively own whether an item is finished. This is not divisible. One person on the team is not the quality person.

The Product Owner. Accountable for value and for ordering the Product Backlog. They can renegotiate scope with the Developers as more is learned during a Sprint. They cannot reduce the quality standard to fit more in, and a Product Owner asking whether testing could be skipped this once has stepped outside their accountability.

The Scrum Master. Accountable for the effectiveness of the Scrum Team. They protect the Definition of Done, coach the team on why it matters, and make visible any pressure that is eroding it. They do not own quality and they do not sign off work.

The distinction that matters most is between scope and quality. Scope is a legitimate variable during a Sprint. Reducing it is a normal conversation between the Product Owner and the Developers. Quality is not on the table, and treating it as another lever is how teams accumulate technical debt without deciding to.

The Definition of Done Is the Mechanism

This is the part that makes the accountability workable rather than aspirational.

Without a shared standard, quality is an opinion. Two developers will hold different views on whether something is finished, and the disagreement surfaces at the worst moment. The Definition of Done turns that into a checkable agreement.

It is binary. An item either meets it or it does not. There is no mostly done, and an item that does not meet the standard is not part of the Increment, cannot be presented at the Sprint Review, and returns to the Product Backlog.

It applies to every item. Not just the important ones. Selective application is the same as not having one.

It is created by the team. Where an organisation imposes a minimum standard, the team can be stricter but not looser. Who sets it is covered in our guide to who creates the Definition of Done.

It should get stronger over time. A Retrospective that adds something to the Definition of Done is one of the most valuable outcomes available, because it raises the floor permanently rather than fixing one instance.

A team without a real Definition of Done does not have a quality accountability, it has a hope. That is the first thing to look at when quality problems recur.

Where Testers Fit

The question this article really gets asked about, particularly by people moving from a traditional structure.

Scrum defines no tester role. It defines Developers, and everyone building the product is a Developer regardless of specialism. Someone whose skill is testing is a Developer who tests.

That is a naming change, and it carries two real consequences.

Accountability is collective. The team is accountable for quality together. When a defect reaches production, the answer to who is responsible is the Developers, not the person who last touched it or the person who tests.

Testing is not a phase. If testing happens in the last two days of the Sprint, the team has recreated the handoff that Scrum removes, with a shorter runway. Anything found late either rushes through or carries over, and the Sprint reliably ends with a scramble.

None of this devalues testing expertise. A team without someone who thinks rigorously about how software fails will ship worse software, and that skill is scarce and valuable. What changes is that the person holding it is part of the team from planning onward rather than a downstream gate, and their most useful contribution often happens before code is written, in the conversation about what acceptance criteria should actually say.

Practical approaches to integrating this properly are covered in our guide to QA in agile processes, and the wider shift is discussed in agile testing versus traditional testing.

Quality Does Not Decrease

A short sentence in the Scrum Guide with substantial implications.

During a Sprint, quality does not decrease. Scope can be clarified and renegotiated. The Sprint Goal does not change. And quality holds.

What this constrains in practice.

It rules out the most common shortcut. When a Sprint is running late, the tempting move is to skip the tests, defer the code review, or mark something done that is not. That option is closed, which is precisely the point of writing it down.

It forces the honest conversation. If the work will not fit, the response is to reduce scope and say so, not to deliver everything at a lower standard and let the shortfall surface later.

It protects the Increment's meaning. An Increment is supposed to be usable. If quality flexes, the word stops meaning anything and nobody can trust that finished means finished.

The organisational pressure against this is real and constant, and it usually arrives as a request rather than an instruction. Could we just get it in and tidy it up next Sprint. Holding that boundary is where the Scrum Master role earns its place, and doing it without becoming an obstacle is genuinely difficult. It is one of the harder skills covered in CSM Certification Training.

How Quality Actually Erodes

Rarely a decision. Almost always an accumulation.

Sprint one. Something is nearly done. It works but has no automated test. The team agrees to add the test next Sprint and marks it done.

Sprint three. Two more items have gone through the same way. Next Sprint is now carrying three small debts nobody has scheduled.

Sprint six. A change in that area breaks something, because the tests that would have caught it were never written. A day is lost. The team is now behind, which makes the same shortcut more tempting.

Sprint ten. The area is known as fragile. Estimates for anything touching it have doubled. Nobody can point to the decision that caused it, because there was no decision, only a series of reasonable seeming exceptions.

The mechanism is that each individual compromise is defensible and the accumulation is not. This is exactly what the Definition of Done exists to prevent, and it only works if it is treated as binary. A standard that can be waived when convenient is not a standard.

The Retrospective is the natural place to catch this, since the pattern is visible across Sprints in a way it never is within one. A team that notices it has marked three items done without tests has caught the problem while it is still cheap, which is much of the value of the Sprint Retrospective.

What Belongs in a Definition of Done

Since the whole accountability rests on this artefact, it is worth being concrete about what a workable one contains. This is an example rather than a template, because a team's Definition of Done should reflect its own context.

Code is reviewed by someone who did not write it. Cheap, and it catches more than most automated checks.

Automated tests are written and passing. The specific coverage expectation varies by team and codebase. What matters is that it is stated rather than assumed.

Existing tests still pass. Obvious, and worth writing down because regression is where late defects concentrate.

Acceptance criteria are met and verified. Verified by someone other than the person who built it, which is where testing specialism contributes most.

It is deployed to an environment where it can actually be used. Working on a laptop is not an Increment.

Documentation is updated where it exists. Only where the team genuinely maintains it. Including this when nobody keeps documentation current makes the whole standard less credible.

No known defects of an agreed severity. Trivial cosmetic issues can be logged and ordered in the backlog. Anything above the agreed threshold means the item is not done.

Two things separate a working Definition of Done from a decorative one. Every entry is checkable, so nobody has to interpret whether it was met. And the list is short enough that the team can recall it without looking, because a fourteen point checklist gets skimmed rather than applied.

Teams often ask whether to add items they cannot yet meet. The better sequence is the opposite: define what you genuinely do today, then add one item at a time through the Retrospective as the capability arrives. A standard nobody meets is worse than a modest one everybody does.

The Sprint Review Is the Enforcement Point

Underrated, and it makes the Definition of Done real in a way discussion cannot.

Only work that meets the Definition of Done goes into the Increment, and only the Increment is presented at the Sprint Review. That gives the standard a consequence with an audience attached.

A team that quietly marks something done despite gaps will usually get away with it inside the Sprint. Showing incomplete work to stakeholders is considerably more uncomfortable, and that discomfort is doing useful work. It is the difference between a rule and a rule with teeth.

The related failure is presenting things at the Review that did not meet the standard, described as nearly finished. Once that becomes normal, the Increment stops being a meaningful concept and stakeholders lose the ability to judge progress. A Sprint Review where a team says plainly that an item was not finished, so it is not being shown, is a healthier signal than one where everything is demonstrated with caveats. How the events fit together is covered in our guide to the five events of Scrum.

When Quality Problems Persist

Some causes are structural rather than behavioural, and no amount of coaching addresses them.

No Definition of Done, or one nobody reads. The most common cause. Fix this first, since everything else depends on it.

Testing skills concentrated in one person. Creates a bottleneck and a de facto gate, which reproduces the handoff. Spreading the capability is slow and it is the only real fix.

No automated testing. Manual regression testing does not scale within a Sprint. Teams without automation eventually cannot maintain quality at Sprint cadence regardless of intent, and that is an investment decision above the team.

Sustained delivery pressure. A team told repeatedly that a date is immovable will find a way to hit it, and quality is the least visible thing to sacrifice. This is an organisational problem presenting as a team problem.

Unclear acceptance criteria. If nobody agreed what finished means for an item, quality against it cannot be assessed. This is a refinement failure showing up downstream.

Items too large to finish inside a Sprint. An item that cannot realistically be completed and verified within the timebox will get partially done and marked complete, because the alternative is admitting the Sprint failed. Splitting is a quality intervention as much as a planning one.

Diagnosing which of these is operating matters more than it sounds, because a team told to care more about quality when the real constraint is an absent automation suite will conclude, correctly, that nobody is listening. The Scrum Master's contribution here is identifying which constraint is actually binding and raising the ones that sit above the team, which is a substantial part of what CSM Certification Training prepares people for.

Diagnosing which one is operating matters, because the responses are entirely different. Coaching a team on craftsmanship when the real problem is that they have no automated tests and an immovable deadline will not help anyone.
Closing Thoughts

The answer to who owns quality in Scrum is unusually clear for a question people find confusing: the Developers, collectively, through the Definition of Done.

The confusion comes from arriving with a mental model in which quality is a stage and a role. Scrum removes both, and what replaces them is an agreed standard applied to every item, plus a rule that the standard does not move when things get tight.

The practical implication is that quality problems are rarely solved by adding a check at the end. They are solved upstream, in what the Definition of Done requires, in whether acceptance criteria are clear, and in whether the team has the automation to sustain it. A team that finds itself arguing about who should have caught a defect is usually asking the wrong question.

If you are the person holding that boundary when the pressure arrives, CSM Certification Training covers the accountabilities and the practical facilitation that keeps the Definition of Done from quietly eroding. Request the curriculum to see the agenda and upcoming dates, or start with the free CSM practice test to find your gaps first.