Shared Definition of Done (DoD)

Play Description

Pattern Summary 

In a networked environment of multiple teams building the same product, clarity on what constitutes “done” is essential. A Shared Definition of Done (DoD) creates this clarity by establishing common expectations for quality, completeness, and consistency. Unlike a single-team DoD, a shared DoD extends across teams, often with diverse skills, domains, and contexts. Its purpose is to ensure that all components delivered by different teams integrate into a cohesive, high-quality product by providing clarity for all teams on what constitutes “done” work.

Related Patterns

Shared Definition of Ready (TBD), Cross-Team Coordination

Symptoms Categories

Inconsistent Quality, Lack of Alignment, Delivery Delays, Miscommunication, Rework

Symptoms Addressed

This pattern can help address:

• Lack of clarity on quality of deliverables, leading to frequent misunderstandings across teams.
• Inconsistencies in quality standards that result in rework and delays.
• Difficulty in integrating work from multiple teams due to differing completion criteria.
• Misalignment between development teams and business stakeholders regarding release readiness.

Detailed Description

A Shared Definition of Done (DoD) ensures alignment across multiple teams working on the same product. Unlike a single-team DoD, which focuses on internal quality, a Shared DoD establishes uniform expectations across teams to reduce integration risks, enhance predictability, and improve product quality. By aligning on testing, documentation, and performance standards, teams create a common language that simplifies collaboration and ensures smoother coordination of work.

This shared approach minimizes late-stage surprises by enforcing consistent coding standards and integration practices. It fosters cross-team communication, balancing autonomy with alignment, and ensuring deliverables meet product-wide expectations.

Key Differences from a Single-Team DoD

In Frameworks

Various agile scaling frameworks offer guidance on shared DoDs. Here’s a brief comparison:

SAFe (Scaled Agile Framework):
SAFe emphasizes a “Team of Teams” model, where DoD is extended to a “Program Definition of Done” to align multiple Agile Release Trains. It incorporates quality standards across teams for solution-level work.

Scrum at Scale (S@S):
S@S focuses on creating consistency across Scrum teams through the “MetaScrum” and “Scrum-of-Scrums” constructs. Shared DoDs help synchronize cross-team work while preserving team-level autonomy.

LeSS (Large-Scale Scrum):
LeSS encourages simplicity and relies on a single, organization-wide DoD to ensure consistency across teams working on the same product. Teams collaboratively evolve the shared DoD during joint reviews.

Nexus (Scrum.org):
Nexus extends Scrum to manage multiple teams by introducing the Nexus Integration Team. A shared DoD ensures that teams deliver work that integrates successfully at each sprint boundary.

Disciplined Agile (DA):
DA provides flexibility by allowing teams to choose their way of working while encouraging shared technical and architectural standards through common DoD practices for teams working on the same product line.

How To Use

Incorporating a shared DoD involves aligning teams, fostering a collaborative mindset, and embedding shared standards into daily work. Teams can:

• Facilitate joint workshops to agree on shared standards.
• Maintain a visible, accessible DoD repository.
• Review use and effectiveness during cross-team events.
• Encourage teams to suggest improvements based on their experiences.
• Align shared DoD criteria with organizational goals and product strategy.

Do Not Use This Pattern When

While shared DoDs offer many benefits, there are contexts where their application may create more friction than value. Consider the following scenarios:

• High Team Autonomy with Minimal Overlap: If teams deliver independent products with few integration points, a shared DoD can impose unnecessary constraints.
• Highly Specialized Teams: Teams working in highly distinct domains (e.g., firmware vs. cloud services) might find more value in domain-specific DoDs.
• Emergent, Innovative Work: In early-stage, experimental work, rigid shared standards may inhibit learning and innovation.
• Excessive Overhead for Small Scale: When only two or three teams collaborate, informal agreements may suffice without the complexity of a shared DoD.