Who owns quality on a Scrum team

Ask who is responsible for quality in a traditional project and you will usually be given the name of a department. Ask in a Scrum Team and the honest answer is "all of us", which sounds like a way of avoiding the question. It is a precise answer, and the Guide builds it into the structure.

What the Guide says

Four statements carry the model.

The Developers are always accountable for instilling quality by adhering to a Definition of Done. They are also required to conform to it. If the Definition of Done is part of an organisation's standards, all Scrum Teams must follow it as a minimum, and otherwise the Scrum Team must create one appropriate to the product.

During the Sprint, quality does not decrease. It is one of the four rules the Guide gives for what happens in a Sprint, next to not endangering the Sprint Goal.

The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint. That includes the Product Owner, who is accountable for the value of the product, and the Scrum Master, who helps the team focus on high-value Increments that meet the Definition of Done.

An item that does not meet the Definition of Done cannot be released or even presented at the Sprint Review. It returns to the Product Backlog.

The Scrum Team, the Guide also notes, is responsible for all product-related activities, which include verification, maintenance and operation. There is no stage after the team in which someone else will check the work.

The SBOK® Guide comes to a similar structure with different vocabulary. The Product Owner defines acceptance criteria for every story and is responsible for ensuring they are met, the Scrum Team creates the deliverables and agrees Done Criteria, and an optional Scrum Guidance Body can set organisational objectives for quality, regulation and security that guide all teams.

Who owns which piece

Quality, in other words, has several faces. One is correctness: does it do what was asked. Others are performance, security, usability and maintainability. The ISO/IEC 25010 product quality model lists nine characteristics, including functional suitability, performance efficiency, compatibility, reliability, security and maintainability. A Definition of Done that covers only "tests pass" is quietly leaving out most of that list.

What a tester does in this model

The Guide has no tester role, because it has no specialist roles below the Developers. The word Developers includes anyone who creates any aspect of a usable Increment, and testing is such an aspect. In practice this means:

• A person with testing expertise is a Developer on the team, with a strong specialism, and takes part in all of the Sprint's events and planning.
• They help the whole team test better: designing examples with the Product Owner, setting up automated checks, exploring the product in ways others would not.
• They do not become a gate. The rest of the team does not hand them finished code and wait for approval. Testing happens as the work is done, and anyone can do some of it.

This is the relevant side of being cross-functional. If testing is something that happens after the Sprint, or in another group, the Definition of Done is being weakened without anyone saying so.

A worked example: a defect found after release

This is an illustrative case. A team ships a payment reminder feature at the end of a Sprint. Three days later a support agent reports that some customers receive two reminders.

In an organisation with a quality department, the argument starts at once: the Developers say it passed their tests, the testers say the case was not in the specification, and the Product Owner says the specification was agreed. The ticket is passed back and forth.

In a Scrum Team that owns quality, the question is different. The team looks at the Definition of Done and asks what would have caught this. The answer is a check for duplicate sends under concurrent runs, which was not in the Definition of Done or the acceptance criteria. The team does three things. It fixes the defect now. It adds an automated test for the case. And it adds a line to the Definition of Done: any scheduled job is tested for repeated execution.

Nobody was at fault in the sense of the old argument. The team learned that the Definition of Done was thinner than the product's risk, and changed it. That is what the Guide means by the Definition of Done being a commitment of the Increment.

Quality and AI-assisted work

Teams that use AI tools to generate code or tests can produce more output with the same effort, which raises the stakes on the Definition of Done. The Developers remain accountable for what goes into the Increment whether they typed it or reviewed it. A useful addition is a line that every generated change is read and understood by a Developer who could explain it, and that generated tests are checked for whether they would fail if the code were wrong. The accountability does not move.

Common mistakes

• A "QA Sprint" at the end. Quality is built in, and testing after the fact is the old model.
• Weakening the Definition of Done under pressure. The Guide says quality does not decrease in the Sprint. Drop scope instead.
• Treating the Product Owner's acceptance as the only test. Acceptance checks value and fit, and does not replace engineering verification.
• Making one person the gate. If all work flows through one tester, quality becomes a bottleneck and the rest of the team stops caring.
• Blaming the team member who wrote the bug. The team owns it, and the useful question is what in the process allowed it.

How to practise it

Review your Definition of Done against the ISO characteristics: which ones does it cover, and which does the product's risk call for? In the simulator the Definition of Done is a choice you make and defend, and you see how a thin one catches up with the team.