Quality gates are the criteria a release must meet before it can proceed, written before the work starts rather than negotiated at the end. Written early, a gate is a standard the team builds toward. Written late, it is a description of whatever the team managed to finish. Keep them few and binary, so that passing is a fact rather than a judgment made under deadline pressure.
Quality gates are set during Focus, when the release plan is built, and they are enforced in the Deliver practice, where gate results and the scope validation log are two of its outputs.
How do quality gates work?
A gate has four parts: the criterion, the evidence, the threshold, and the approver.
The criterion is what must be true, expressed so that two people reading it would reach the same verdict. "Performance is acceptable" is not a criterion. "The claim submission endpoint responds within the agreed limit at the agreed concurrency, measured in the staging environment" is.
The evidence is the artifact that settles it: a test report, a scan output, a signed accessibility audit, a migration dry-run log. If nobody can name the artifact in advance, the gate will be settled by opinion on the day.
The threshold is the line between pass and fail, agreed while nobody knows which way the result will go. Thresholds set after the result is known are ratifications.
The approver is one named person who can say pass or fail. Approval by committee produces a negotiation, and negotiations under release pressure have a predictable direction.
Gates are binary by design. A gate with a red, amber, green scale will sit at amber, and amber has always meant proceed. If a gate genuinely has degrees, split it into two gates with different thresholds, or state the one threshold that matters and accept that everything else is information rather than a gate.
Few matters as much as binary. Four to six gates for a release is workable, and a team can hold all of them in mind while building. Twenty gates become a checklist somebody completes the week before go-live, which is the behavior the practice exists to prevent.
What do good quality gates look like?
Good gates start from what would actually make you stop a release, not from a quality standards document. Each one would stop something if it failed, each one names the evidence that settles it, and the results are recorded, failures and overrides included, so the release readiness review and the Learn practice can see whether the thresholds were set in the right place.
Track how often each gate fails and what happens next. A gate that has never failed is set too low to be informative. A gate that fails and is overridden every time is training the organization to treat all the gates as advisory.
What does a set of quality gates look like in practice?
Picture a health insurer releasing a member portal that agrees five gates before the build starts, covering automated regression, security, accessibility, data migration, and operational handover. Each one names the artifact that will settle it and one person who can say pass or fail.
Two things about that set are worth noticing. The first is that every gate names an artifact, so nobody arrives at the review with a verbal assurance. The second is that the last gate is not about the software at all. The handover gate is often the one skipped, and its absence shows up weeks later as an unsupported system.
Now say the migration gate fails on the first dry run because control totals do not match on one policy type, and the release slips by four days. That is the gate working, and it is cheaper than the alternative, which is discovering the mismatch after cutover.
What goes wrong with quality gates?
- They get written during the last sprint. At that point the criteria are reverse-engineered from the current state of the build, and they cannot fail.
- Too many of them. A long list gets delegated to whoever is assembling the release pack, and the gates stop influencing how the work is done.
- No named approver. The gate is discussed in a meeting, the room reaches a mood rather than a verdict, and the release proceeds.
- Thresholds that move. Lowering a threshold to pass is a decision worth making sometimes. Making it without recording it means the next release starts from the lowered line.
- Gates that only cover code. Migration, operational handover, and regulatory obligations are where releases hurt after go-live.
- Gates used to block scope changes. A gate is about whether the thing is fit to ship, not about whether the scope was the right scope. That question belongs to MVP prioritization.
Quality gates vs definition of done: what is the difference?
The definition of done governs a story. The quality gate governs the release. A team's definition of done says what has to be true before a single item can be called complete, and it is owned by the team. A quality gate says what has to be true before a collection of completed items can go to production, and it is owned by the organization.
| Definition of done | Quality gate | |
|---|---|---|
| Governs | One story or item | One release |
| Owned by | The team | The release approver |
| Checked | Continuously, every item | At the release decision |
| Typical content | Tested, reviewed, documented | Regression, security, migration, handover |
They are complements, not alternatives. Every story can meet the definition of done while the release fails a migration gate, because nothing at story level was ever going to test the whole data set. A strong definition of done reduces how often gates fail. It does not replace them.
Quality gates vs stage gates in traditional PPM: what is the difference?
Stage gates in traditional portfolio management govern whether a project advances to the next phase and continues to receive funding. Quality gates govern whether a release is fit to go to production. The two answer different questions, and an organization can run both.
The practical difference is what the gate is evidence about. A stage gate asks whether the investment case still holds, which is a portfolio decision and belongs with the approval and value review practices in the agile portfolio management terms glossary. A quality gate asks whether this build can be operated safely, which is a delivery decision. Stage gates that drift into judging build quality, and quality gates that drift into re-arguing the business case, are both ways of making a decision in the wrong room.
Setting the gates before the build starts, with named approvers and real thresholds, can be part of a PPM4Agile implementation, done with your delivery and operations leads.