Scrum Testing: Roles, Ceremonies and Definition of Done

A two-week sprint has ten working days. About one goes on ceremonies, six on development and, if you’re lucky, three on testing.1 That’s why testing keeps getting pushed to the end of the sprint. And you probably know how that ends: it’s Friday, the release is on Monday, a story isn’t finished, and it rolls into the next sprint.

Most Scrum teams think they have a testing problem. Usually, it’s really a timing problem. Testing starts after the code is done, the code is done at the end of the sprint, and so testing gets squeezed. It doesn’t matter how good your testers are.

Adding more testers won’t fix it. What fixes it is testing alongside development instead of after it, and writing that into your Definition of Done so it actually happens.

In this guide, we’ll cover how scrum testing works, who does what, where testing fits into each ceremony, what a good Definition of Done looks like, the mistakes teams keep making, and how AI-written code is changing things.

What is Scrum Testing?

Scrum testing is testing that happens throughout the sprint, alongside development. The whole team owns it, and it’s checked against a Definition of Done that everyone agrees on.

Scrum itself is a framework where a team builds and ships a working piece of the product every sprint, usually every two weeks. It has three accountabilities (often called roles), five events and three artefacts. That’s all it prescribes. How well it works depends on how your team uses it.

A few things follow from this:

• Testing isn’t a separate phase: If you leave it until after development, you’re not really doing Scrum.

• Quality belongs to the whole team: Testers might do most of the testing, but everyone is responsible for whether the work is really done.

• The Definition of Done matters most: In the Scrum Guide, it’s the commitment that comes with each increment. It’s what decides whether the sprint’s work actually counts as done.

Agile vs Scrum: Why the Difference Matters for Testing

People use these words as if they mean the same thing, but they don’t. Agile is a set of principles for building software in small steps. Scrum is one way of putting those principles into practice, with set roles, events and artefacts.

For testers, the big difference is timing. Agile says “test continuously” but doesn’t say when.

Scrum gives you the when: sprint planning, the Daily Scrum, the sprint review and the retrospective, plus backlog refinement, which happens on an ongoing basis. “Test continuously” only really happens once it’s tied to these.

Also read: our guide to agile testing covers the principles scrum testing is built on.

Scrum Testing Roles and Responsibilities

1. The Product Owner

The Product Owner manages the backlog and writes the acceptance criteria for each story. If the criteria are vague, the tests will be too, and nobody will be sure the release is ready.

Good Product Owners write criteria you can actually test, often in a Given-When-Then format, so each one can turn straight into a test case.

2. The Scrum Master

The Scrum Master clears blockers and protects the sprint from scope creep. They don’t own testing, but they make a big difference to it. If new work keeps getting added late in the sprint, testing will always get squeezed at the end.

3. The Developers

The current Scrum Guide calls this group “Developers” rather than “the Development Team”, and it includes everyone who builds the product, testers included.

Testers sit inside the team, not at the end of a hand-off. Programmers write unit and integration tests, testers join design reviews and help debug, and both do exploratory and acceptance testing.

Everyone still has their own role, but the work overlaps on purpose. That’s the big change from the old way, where QA was a separate team that got the work handed over at the end.

The QA Role in Scrum Testing

The QA role in Scrum teams has changed a lot over the last ten years, and AI is changing it again. It’s moving away from running tests by hand and towards designing and looking after how the team tests.

Today, a QA person in a Scrum team usually looks after:

• Acceptance criteria, written with the Product Owner so stories are testable from the start

• The automated regression suite, kept in good shape rather than left to break

• Exploratory testing on new stories, where human judgement helps most

• Checking the customer journeys that release decisions depend on

• The Definition of Done, kept up to date rather than written once and forgotten

• Root cause analysis when a bug reaches production, so the lesson goes back into the DoD

Scrum Testing in Each Ceremony

Each Scrum event, plus backlog refinement, has a part for testing to play. If testing gets skipped in any of them, it’s usually an early sign things are about to slip.

1. Sprint Planning

Testing work gets estimated alongside development work. Testers flag stories with unclear acceptance criteria and add testing tasks to every story. If a story has no testing task, it’ll either be tested late or not at all.

2. Daily Standup

In 15 minutes, testers share how testing is going, mention any flaky tests or environment issues, and flag if development is getting too far ahead.

The simplest check: is testing keeping up with development?

3. Sprint Review

Testers make sure everything in the demo has actually been tested, and point out anything that hasn’t. Good teams also use feedback from the review to add tests for cases nobody thought of.

4. Sprint Retrospective

Testers bring the numbers: flaky tests, bugs that slipped through and bugs found in production. This is where the Definition of Done gets better over time. Repeat problems become new DoD items, and checks that waste time get dropped.

5. Backlog Refinement

Testers join Three Amigos sessions, reviewing each story with a developer and the Product Owner before it goes into a sprint. It’s the cheapest point to find gaps.

The Definition of Done in Scrum Testing

The Definition of Done is the team’s agreement on what “done” really means. It’s the most important commitment in scrum testing, and also the one teams most often don’t put enough thought into.

A weak DoD lists activities, things you did. A strong DoD lists outcomes, things that are actually true about the product.

You can tick every activity and still ship something broken. You can’t do that with outcomes.

Good teams keep their DoD up to date. They look at it in every retrospective, clear it out every quarter, and keep it somewhere the whole team can see it, not buried in a wiki.

Adding “customer journey tested end to end” is one of the most useful changes you can make, because it brings journey testing into the sprint instead of leaving it until later.

The Three Amigos: Testing Before the Code Exists

The Three Amigos is when a developer, a tester and the Product Owner go through a story together before it goes into a sprint. It’s one of the most useful habits in scrum testing, because it does three things at once:

• It clears up vague requirements: “The customer should get a confirmation” could mean lots of things. Fixing that before the sprint is easy. Fixing it halfway through isn’t.

• It finds edge cases early: Testers ask things like “what if this field is empty?” or “what if someone clicks submit twice?”. A lot of bugs get prevented right there, before anyone writes code.

• It checks the story can be tested at all: If you can’t test it, you can’t really say whether it’s done.

It takes about 30 minutes per story, and most teams see the benefit within two sprints: fewer surprises at the end of the sprint, fewer bugs slipping through, and stories finished faster.

The Agile Testing Quadrants and Their Limits

Most treatments of Scrum testing lean on the Agile Testing Quadrants, so it is worth covering, along with an honest note on where it falls short. The quadrants sort tests along two axes, namely whether they support the team or critique the product, and whether they are technology-facing or business-facing.

• Quadrant one, technology-facing and team-supporting: Unit and component tests, automated, giving developers fast feedback on the code.
  ‍

• Quadrant two, business-facing and team-supporting: Functional tests, prototypes, and examples that check the software meets the business intent, run manually and automatically.
  ‍

• Quadrant three, business-facing and product-critiquing: Exploratory, usability, and acceptance testing, largely manual, judging the product as a user would.
  ‍

• Quadrant four, technology-facing and product-critiquing: Performance, load, security, and other non-functional testing, usually tool-driven.
  ‍

The model is a useful map, and its limit is that it is a taxonomy rather than a rhythm. It tells you what kinds of testing exist but not when they run inside a two-week sprint, and it predates both continuous delivery and AI-assisted development.

Treat it as a checklist of what not to forget, not as a schedule, and pair it with the cadence view below, which is the part that actually keeps a sprint from collapsing at the end.

Scrum Testing Types and When to Run Them

A sprint can hold several testing types if the team is disciplined about when each runs, and matching the type to the right cadence is what keeps verification parallel to development rather than piled up behind it.

Shift Left and Shift Right Across the Sprint

A working programme operates across the whole sprint, not at the end of it, and two patterns capture the discipline. Shift left moves verification earlier, often before code exists, and shift right extends it into and beyond release.

Shift left turns testing from a downstream checker into an upstream contributor, through acceptance criteria authored with the story, Three Amigos reviews before sprint inclusion, test cases written before or alongside the code, static analysis in the developer workflow, and verification at the pull-request level before merge. The defects caught this early are cheaper to fix and rarely escalate into customer-facing incidents.

Shift right closes the gap between what the team verified in staging and what customers actually experience, through continuous behaviour verification of critical journeys in production-like environments, canary releases and feature flags that validate behaviour on a slice of traffic, synthetic monitoring against production, and real user behaviour feeding back into test design.

The two together stretch testing from "during the sprint" to "across the lifecycle."

To know the differences in detail, check our article on Shift Left vs Shift Right Testing: Which Strategy Wins?

The Why Testing Falls Behind Development

The most common scrum testing problem is testing falling behind development during the sprint. It nearly always looks the same.

Development moves fast for the first six working days, finished stories pile up in a “ready for testing” column, testers start getting them on day seven, the queue is full by day eight, and by day ten the team has to choose between cutting corners on testing or pushing stories into the next sprint. Neither is good.

This isn’t about people working too slowly. AI is helping developers write code faster, and manual testing can’t speed up to match, so hiring more testers won’t solve it. Changing how you test will.

These three changes help most:

• Automate enough regression testing that people can focus on new features

• Put testing in the Definition of Done, so stories can’t sit in “ready for testing”

• Test at the pull-request level, so the backlog never builds up

Common Scrum Testing Mistakes

Most teams that haven’t sorted out their scrum testing run into the same problems. Spotting them is half the battle.

How AI-Generated Code is Reshaping Scrum Testing

AI coding tools are changing scrum testing in ways Scrum was never designed for. Here’s what’s happening:

More Code, Same Testing Time

AI helps developers write more code each sprint, but testers don’t get any more time. Unless you change how you test, the gap gets bigger.

More Refactoring

AI tools rewrite code during the sprint, sometimes without anyone noticing. Tests written against the old code can then break, or worse, pass when they shouldn’t. Fragile tests become a problem every sprint, not just at release time.

Behaviour Changing Quietly

An AI rewrite can keep the same inputs and outputs but change how something behaves. Acceptance criteria still pass, but the customer journey breaks. That’s a big reason to add journey testing to your DoD.

AI Writing Tests Too

The same AI that writes code can help write tests. So the job shifts from writing every test by hand to deciding what needs to be true and checking the AI got it right.

Put simply, scrum testing is moving from something that happens inside each sprint to something that runs all the time, across sprints, owned by the whole team and backed by tools that can keep up.

From Sprint-Scoped Testing to Continuous Verification

The sprint, the ceremonies and the Definition of Done all stay. What changes is when and how testing happens.

Tests run on every pull request instead of at the end of the sprint. Coverage is measured by journeys and behaviour, not just lines of code. And the whole team owns testing, with tools doing the repetitive work people can’t keep up with.

You can tell a team is working this way when:

• Their Definition of Done includes customer journey testing

• Their sprint review shows the key customer journeys working end to end

• Their retrospectives talk about what behaviour is covered, not how many tests they have

Best Practices for Scrum Testing

• Keep your Definition of Done up to date. Review it every retrospective and clear it out every quarter.

• Run a Three Amigos session for every story before it goes into a sprint.

• Add testing tasks to every story during planning.

• Run quick smoke tests on every merge and the full regression suite overnight.

• Save people’s time for exploratory and acceptance testing on new work, and automate the rest.

• Add customer journey testing to the DoD, and test continuously, not just at the end of the sprint.

• Track escaped bugs and flaky tests every sprint, and watch the trend rather than the exact number.

• Turn feedback from sprint reviews into new tests.

• Test at the pull-request level wherever you can, so testing never falls behind.

• Make sure every retrospective ends with something to change.

How Virtuoso QA Powers Modern Scrum Testing

The main problem in scrum testing is that people can’t test as fast as AI helps developers build. So the sprint keeps ending with a pile of untested work. Fixing that means changing how testing works, so it can keep up.

Here’s how Virtuoso QA helps Scrum teams:

• Tests in plain English: Tests are written in plain English, so acceptance criteria can become tests the whole team can read, not scripts only one engineer understands.

• Tests drafted from stories: Touchstone’s AI agents read your requirements, acceptance criteria and Jira stories and draft requirements and tests from them, showing the source for each one. A named person approves every requirement before anything gets built. That way, testing keeps up with new stories instead of falling a sprint behind.

• Existing tests brought across: GENerator converts your existing Selenium tests into plain English, so you keep the regression coverage you already have.

• Repairs you review: When code changes affect the UI, Virtuoso QA suggests fixes for your team to accept or reject. Tests keep working through refactors, and nothing changes without someone seeing it.

• Faster debugging: AI Root Cause Analysis shows you screenshots, logs and the affected area when something fails, so you can sort it out within the sprint.

• Reusable tests: Composable Testing lets you run the same tests across browsers, operating systems and customer types without copying them.

Every AI action is suggested for review, run by a deterministic engine and recorded, so you stay in control. Tests run in parallel across 2,000+ browser and OS combinations.

To see how Virtuoso QA keeps regression running on every merge, with fixes your team reviews, take a look at Virtuoso QA’s regression testing.

What’s Next for Scrum Testing

Here’s where things look like they’re heading:

• More teams will add customer journey testing to their Definition of Done, starting with the fastest-moving teams.

• Testing will run all the time, on every commit and pull request, instead of in a block at the end of the sprint.

• Testers will spend less time writing and running tests, and more time deciding what to test, looking after the DoD and handling the tricky cases tools can’t.

Teams that make these changes early will keep getting further ahead. Teams that wait will find it harder and harder to keep up with how fast their developers are shipping.

Related Reads

• ‍What is Agile Testing? Principles, Types & Practices‍
  
  

• 12 Advantages of Agile Testing for Modern QA Teams‍
  
  

• Top 20 Agile Testing Tools for QA Teams in 2026‍
  
  

• 24 Agile Test Metrics Every QA Team Should Know
  
  

• Agile Test Automation: Strategies for Sprint Success