L0Reference5 min read

Delivery models: agile, scrum, kanban, trunk-based

Where testing sits changes completely between a two-week sprint and twenty deploys a day. You do not need the certification; you need to recognise which model you are in, because it decides when your work happens and what it can block.

A delivery model is how a team turns finished work into something customers can use. The common ones are Scrum (fixed sprints), Kanban (continuous flow), trunk-based development (everyone merges to one branch) and continuous delivery (every green change is releasable).

Testing does not change between them. What changes is when your work happens, and what it is able to stop.

A tester I know moved between two teams in the same company.

On the first team, releases went out every second Thursday. She had two protected days at the end of each sprint, a regression pack, and a release meeting where she gave a recommendation.

On the second team, code went to production about twenty times a day. There was no release meeting, no protected days and no pack to run. Her first instinct was that nobody tested anything. She was wrong. Testing had moved rather than disappeared.

That is the only thing you need from this topic: the delivery model decides when your work happens and what it can stop.

The terms you will hear

Sprint. A fixed timebox, usually two weeks, with a planned set of work.
Work in progress limit. A cap on how many items can be in flight at once. The core Kanban control.
Trunk-based development. Short-lived branches merged to one main line, often several times a day.
Continuous integration. Every merge builds and runs the checks automatically.
Continuous delivery. Every passing build is releasable. Continuous deployment means it ships automatically.
Feature flag. A switch that hides unfinished work in production, so merging is not releasing.
Shift left. Doing testing earlier, closer to when the work is designed.

The four you will meet

Scrum sprints. Fixed two-week batches. Testing is a thread through the sprint with a protected end, described day by day in testing inside a sprint.
Kanban. No batches. Items flow, each tested when it is ready. Your queue replaces the calendar, and work in progress limits matter more than dates.
Trunk-based development. Everybody merges to one branch, often behind feature flags. Nothing waits, so quality gates live in the pipeline rather than in a meeting.
Continuous delivery. Every green change can ship. Testing before release gets automated, and human attention moves to design, exploration and watching production.

The trade in one paragraph

Batching gives you time to think and delays feedback. Flow gives you fast feedback and no natural pause.

Say a defect ships. In a two-week model you might have caught it in the regression window, and if you did not, it sits in production for a fortnight. In continuous delivery it reaches customers in minutes, and it can also be reverted in minutes. Neither model is safer in general. They fail differently, and knowing which failure your team has is the useful part.

How to work out where you are

Ask what stops a release. A failing pipeline, a person, a checklist, or nothing. The answer tells you where your influence sits.
Ask who decides to ship. A name, not a role. In continuous delivery it is often the engineer who merged.
Ask how a bad change gets undone. Rollback, a feature flag, or a hotfix and a prayer. This shapes how much you should fear each release.
Find your window. In sprints it is protected days. In flow it is the moment an item is ready. In continuous delivery it is before the merge, plus watching after.
Put your automated checks where they can block. A test that runs after deployment is monitoring, not a gate. That is fine, as long as everybody knows which one it is.
Watch production if releases are constant. When nothing pauses for you, real usage is the fastest signal. That is the ground online evals cover for AI features.

The delivery model does not decide whether testing happens. It decides whether you get a window or a gate, and you should know which one you have.

A worked comparison

For example, here is the same tester with the same skills on two teams, written as a first-week note.

where-testing-sits.txt

TEAM A  scrum, 2-week sprints, release Thursday
  what stops a release   me, plus the regression pack
  who decides            product owner, on my recommendation
  undo a bad change      hotfix, roughly 4 hours end to end
  my window              days 9 and 10, protected
  where my time goes     40% story testing, 30% regression,
                         20% exploring, 10% documents
  biggest risk           four stories landing on day 9
  my leverage            the release decision

TEAM B  trunk-based, ~20 deploys a day, flags everywhere
  what stops a release   the pipeline. nothing else.
  who decides            the engineer who merges
  undo a bad change      flag off in seconds, revert in minutes
  my window              before the merge, and after the deploy
  where my time goes     30% pairing before code exists,
                         30% exploring behind flags,
                         20% pipeline checks, 20% production signals
  biggest risk           a gap in the pipeline nobody notices
  my leverage            what the pipeline blocks, and how fast we
                         see a problem in production

SAME IN BOTH
  risk thinking, exploratory sessions, good bug reports, asking what
  problem the story solves, keeping a record of what was tested

The bottom block is the point. Four of the five things that make a tester valuable did not change at all. Only the timing and the lever did.

How to show you know it

The two questions, asked in an interview. "What stops a release, and who decides?" You learn more about a team from those than from any process description.
A note like the one above for your own team, written in your first week.
A pipeline gate you added. In flow-based teams this is the equivalent of holding a release.
A production signal you watch. Error rate, escalations, a specific dashboard. It shows you understand where feedback lives when nothing pauses.

Questions

Do I need the certifications?

No. You need to recognise which model you are in and what it means for your work. Nobody has ever prevented a defect by knowing the official definition of a sprint ceremony.

Which model is best for testing?

The one your team actually follows. A well-run kanban board beats a scrum process nobody respects, and both beat a model that exists only in a slide deck.

What if we say we are agile and behave like waterfall?

Common, and worth naming gently. Ask when testing is expected to start and what happens if it finds something late. The answers will tell you which model you are really in.

How does this change what I automate?

The faster the delivery, the more your checks must run unattended and quickly. Scoring by value and change frequency, as in what to automate first, matters more the less time you have.