Agile Quality Gates: DoR, DoD and Risk-Based Milestones

A quality gate is a predefined checkpoint within a process or way of working (WoW) that ensures relevant quality criteria have been met. Agile quality gates are predefined checkpoints in an agile team’s WoW that ensure relevant quality criteria are met in a streamlined, often automated manner.

This article explores several topics:

Why agile quality gates?
DoRs and DoDs
Risk-based milestones
Isn’t “quality gate” an agile swear word?

Why Agile Quality Gates?

Quality gates are often seen as part of a traditional software WoW. The fact is that quality gates are a general concept that isn’t software-specific, nor paradigm-specific.

There are several benefits to using the term “agile quality gate”:

Terminology consistency. Quality gate is a common and accepted term. One of the criticisms of agile is the creation of new terminology for existing concepts, with the expectation that others will adopt that terminology to go along with the “cool kids.” The agilists need to choose to do better, and part of that choice is to stop reinventing the wheel.
Explicit recognition of common agile practice. Quality gates are commonly adopted by agile teams, as I show below.
Explicit integration with governance and oversight. You are being governed, like it or not. I believe you deserve to be well governed (which is where governance tends to fall short). The adoption of streamlined, agile quality gates supports effective governance.
Streamlining your workflow. One of the reasons why agile purists don’t like terms like quality gate and governance is because they’ve had bad experiences, or have heard about bad experiences, with traditional strategies that tend to be onerous. It is possible to improve the implementation of quality gates through automation and reducing documentation with greater collaboration.

Agile Quality Gates: DoR and DoD

As you see in Figure 1, Agile/Scrum teams typically have two explicit quality gates:

The Definition of Ready (DoR). Your DoR defines quality criteria that a work item must meet before your team is willing to work on it. Your DoR protects you from poor-quality requests, typically poorly described requirements. In short, your DoR is a quality gate that work requests must pass through to get to your team. Figure 2 depicts a DoR for an agile data warehousing team.
The Definition of Done (DoD). Your DoD defines quality criteria that your team’s work products must meet. Your DoD protects your customers from poor-quality work produced by your team. In short, DoD is a quality gate that your team’s work must pass through before being sent to downstream recipients. Figure 3 depicts a DoD for an agile data warehousing team.

Figure 1. Quality gates around a single sprint.

Figure 2. A DoR for an agile data warehousing team.

A question story must meet the following criteria:

Required data elements identified
Official system of record, if it exists, for each data element identified
Additional sources for a data element, if any, are identified
Acceptance criteria for the question story are defined
Indication of implementation preference (report, dashboard, …), if any
UI sketch provided when requested

A defect report must meet the following criteria:

Internal release identifier provided
Severity of defect indicated
Description of setup, including screenshots where applicable
Description of what happened and what should have happened
Link to original requirement, if known, provided

Figure 3. A DoD for an agile data warehousing team.

DoD for Internal Release to Independent Testing:

All acceptance criteria have been implemented via executable tests
All tests run successfully
Detection and reporting of potential data errors implemented
Answers to each question story are available within Tableau
The change list describes what changed from the previous internal release
Supporting technical documentation is up to date

DoD for Potential Release to End Users:

All severity 2+ defects identified by independent or integration testing have been addressed
Compliant with applicable data regulations (SOX, GDPR, CPRA)
Meets accessibility requirements
Enterprise metadata captured, validated, and accepted
Demonstrated to stakeholders and accepted by them
Release notes updated

Agile Quality Gates: Risk-Based Milestones

A milestone review is an agile quality gate that applies specific oversight to a team. Traditional milestones often focused on delivering specific, standardized artifacts that were manually reviewed by external reviewers, with the goal of reducing risk. Risk-based milestones start with the risks to be addressed, then teams address those risks in the most appropriate and streamlined manner possible. An important nuance.

The risk-based milestones I recommend are based on proven software engineering concepts from PMI’s Disciplined Agile (DA) toolkit. Figure 4 maps these milestones to the phases of the agile system development lifecycle (SDLC), and Table 1 provides an overview.

Figure 4. Quality gates throughout the lifecycle.

Table 1. Overview of Disciplined Agile’s risk-based milestones.

Milestone	Risk Addressed	Suggested Implementation Strategies
Continued Viability	Does this initiative still make sense?	When a team works incrementally in short sprints (timeboxes), make a “go-forward” decision at the end of each sprint that considers the initiative’s viability, among other things. When a team works in a lean, continuous delivery manner, a brief review is triggered either by the calendar (i.e. once a quarter) or by automated metrics indicating a potential problem.
Delighted Stakeholders	Are stakeholders happy with what they received?	There are several strategies to consider: Automated surveys (potentially annoying); analysis of social media discussions and defect report records (potentially too late); or interviews with stakeholders (expensive and potentially biased).
Production Ready	Is the solution ready to be shipped and do stakeholders want it?	Adopt DevOps practices such as continuous integration (CI) to validate that your solution is technically ready to ship. Work closely with your stakeholders to understand when they want new value delivered.
Proven Architecture	Does the architecture work in practice?	Show that your architecture works by implementing architecturally significant functionality early in construction. This is referred to as building a working skeleton, an idea popularized by the Rational Unified Process.
Stakeholder Vision	Do stakeholders agree with the team’s strategy?	Following an initial agile envisioning effort, perform a “wall walk” of the relevant requirements, architecture, and planning artifacts with the stakeholders. You’re basically asking them to accept the work that they were actively involved with. Such a wall walk is described in Chapter 4 of my book Not Just Data: How to Deliver Continuous Enterprise Data (February 2026).
Sufficient Functionality	Has the team produced sufficient value?	When a team works incrementally in short sprints (timeboxes), make a “go-forward” decision at the end of each sprint that considers whether sufficient value has been produced since the last time the team released something into production, among other things. When a team works in a lean, continuous delivery manner, the decision to deploy should be automated. Ideally, deployment is zero-cost and zero-risk.

Isn’t “Quality Gate” An Agile Swear Word?

It shouldn’t be, but unfortunately for some people, it is. “Quality gate” is one of many terms that agile purists don’t like, along with phase, modeling, documentation, governance, and many others. This is due to two issues. First, they’re desperate to avoid anything that smells of “needless bureaucracy,” often not realizing that there are significant benefits to be gained by agilized versions of those concepts. Second, they often lack experience beyond the narrow confines of the agile frameworks in which they’ve been inculcated.

Source

Some of the material for this article came from Not Just Data: How to Deliver Continuous Enterprise Data.