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
“Agile teams typically have two explicit quality gates, although they don’t like calling them that,” responds Carol. “These gates are the Definition of Ready (DoR) and the Definition of Done (DoD). The team’s DoR protects them from poor-quality requests, typically poorly described requirements. The DoR is a quality gate that work requests must pass through to get to the team. Similarly, the DoD is a quality gate that the team’s work must pass through before it can be sent to downstream recipients. These recipients would include the independent testers, AI development teams using Converge for training or operational data, and our business partners who are using Converge to access data to help them make better decisions.”
Figure 1. Quality gates around a single sprint.
“The DoR for a team typically calls out analysis work to be done,” says Ankit, a Data Analyst. “The implication is that my fellow analysts and I need to work with Barbara to ensure that any requirements the team is going to work on are sufficiently described. The criteria for sufficiency need to be agreed upon. For example, we may require a sketch of how we expect a question story to be implemented and an indication of where the data will come from. Or perhaps we will decide we need only one or even neither of those things. I recommend that we require both for now and see how well that works out for us. We can always revisit this decision later if we need to.”
“I’ve got a few ideas about this,” says John. “Wayne and I don’t want the team throwing garbage over the wall to us. This used to happen all the time on Utopia because they didn’t really have their act together when it came to internal testing within the team. Given our previous discussion about CDI and the automated testing and analysis that goes along with that, I suspect that may not be a problem. I do think we need to define exactly what we hope to achieve with CDI and capture that in our DoD[1]. This will help to ensure that the independent testers can focus on finding serious problems that have slipped through the cracks rather than trivial issues that the team should have caught on their own.”
“I agree,” says Doug. “But that’s only a good start. The DoD also needs to address the operations team’s quality concerns. These concerns are addressed by the quality-of-service (QoS) requirements that we captured last week[2]. Like what John asked for, I’m asking for explicit recognition that the work of the team must pass the corresponding tests that verify that the work of the team conforms to QoS requirements.”
Agile Quality Gates: Risk-Based Milestones
The risk-based milestones, overviewed in Figure 2 and summarized in Table 1, are proven software engineering concepts from PMI’s Disciplined Agile (DA) toolkit.
Figure 2. Quality gates throughout the lifecycle.
Table 1. Overview of Disciplined Agile’s risk-based milestones.
| Milestone | Risk Addressed | Recommended Strategy |
| Continued Viability | Does this initiative still make sense? | How to Implement |
| Delighted Stakeholders | Are stakeholders happy with what they received? | How to Implement |
| 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 shipped to them. |
| Proven Architecture | Does the architecture work in practice? | Show that your architecture works by implementing architecturally significant functionality early in construction. This is often 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? | How to Implement |
| Sufficient Functionality | Has the team produced sufficient value? | How to Implement |
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.
Recommended Resources
- Definition of Ready (DoR) for a Data Warehouse Team
- Definition of Done (DoD) for a Data Warehouse Team
- Risk-Based Milestones