6 minute read
- Organisations should define a business-level Definition of Done so product quality aligns with organisational and market expectations, not just technical completeness. see why — jump to the section that argues this
- Each Scrum Team must interpret the organisational Definition of Done into its own engineering-level Definition of Done that aligns with organisational constraints and expectations. see why — jump to the section that argues this
- The Definition of Done should evolve over time only to raise quality, aiming for every Sprint increment to be truly releasable and shippable. see why — jump to the section that argues this
- Define an organisational, business-level Definition of Done that captures regulatory, market, customer, financial, and strategic quality expectations for all Scrum Teams.
- Have each Scrum Team interpret and implement the organisational Definition of Done into its own engineering-level, automated, objective, measurable, non‑negotiable quality standard.
- Continuously evolve the Definition of Done only to raise quality until every Sprint increment is truly releasable and shippable at the end of the Sprint.
The Definition of Done (DoD) is not a static artefact; it evolves over time as a Scrum Team gains experience and capability. While the Scrum Guide acknowledges that teams may refine their DoD to improve product quality, there’s an often overlooked piece: Organisations should also provide an organisational Definition of Done that reflects their needs. This organisational perspective ensures that Scrum Teams build on a solid foundation, aligning technical execution with strategic goals.
The Definition of Done (DoD) is an objective, measurable standard of quality, not a negotiable target. Keep it clear, enforceable, and automated to ensure every Increment meets professional expectations.
Definition of Done - The Organisational quotient
For a product to deliver real value, its quality criteria must align with organisational and market expectations. It should meet a minimum quality standard that ensures usability while safeguarding the organisation, its employees, and its users. Any failure to do so could damage the organisation’s reputation and trust in the product.
This means organisations should define a business DoD that may include:
- Regulatory compliance
- Market readiness (e.g., beta testing completion, go-to-market strategies)
- Customer experience and feedback incorporation
- Financial viability assessment
- Alignment with broader company objectives
Without this business-level perspective, teams risk optimising for technical completeness while missing the broader value delivery picture. The result of many iterations of the organisational definition of done for a product might look like:
Live an in production
gathering telemetry
supporting or diminishing
the starting hypothesis
This short sentence packs a lot into it, and it’s a commercial product definition of “done” for a team I have collaborated closely with for over 17 years.
“Live an in production” - done here mean that it is in the hands of real users
“gathering telemetry” - done here mean that the Developers must add code that collects relevant information from usage, performance, and such…
“supporting or diminishing the starting hypothesis” - Done here means that the team must define success metrics before building a feature or capability, ensuring that the collected data provides clear evidence of whether the intended outcomes are being achieved.
None of these elements define the “why” or “what” of what we’re building, those are captured in the backlogs. Instead, they establish the minimum quality standard required for work to be considered done.
Definition of Done - Translating Organisational Standards into Team Practice
While Scrum Teams are self-managing, that doesn’t mean they can do whatever they want. They operate within a structured environment, within a balance of leadership and control that upholds both autonomy and accountability. Scrum isn’t anarchy; it’s a social technology that enables self-management within clear constraints, Scrum events, commitments, and organisational expectations.
Each Scrum Team must interpret the organisational Definition of Done within their context, shaping an engineering-level DoD that aligns with it. While examples can guide them, it’s the team’s responsibility to determine what Done means within organisational constraints.
In addition to supporting the organisational definition of done, a robust DoD ensures that work meets a consistent level of quality before it is considered complete. This includes engineering practices, preferably within the bounds of a shift-left strategy, such as:
Writing Unit and Integration Tests – with a preference for shifting testing earlier by adopting Test-Driven Development (TDD) and automated integration testing, ensuring issues are caught before coding progresses too far, and preferably making tests a prerequisite for writing new code.
Performing Code Reviews – Rather than manual code reviews create automate code quality checks using static analysis and enforce good practices before manual reviews, allowing developers to focus on deeper logic and architectural concerns, and preferably integrating peer reviews into the development workflow, such as pair or mob programming.
Adhering to Security and Compliance Requirements – try embeding security scanning into CI/CD pipelines with automated dependency checks and policy enforcement, catching vulnerabilities before they reach production, and preferably treating security as code, ensuring it evolves alongside development.
Maintaining Updated Documentation – Automate as much of your documentation updates as possible using tools that generate API references and architecture diagrams directly from code, keeping documentation relevant and accurate, and preferably making documentation a non-negotiable part of the Definition of Done (DoD).
Ensuring Deployments are Automated and Repeatable – Implement Infrastructure as Code (IaC) and continuous deployment pipelines to guarantee consistent, error-free releases, and preferably shifting validation left with feature flags, automated rollback strategies, and deployment previews.
Each aspect contributes to quality, reducing the likelihood of defects and technical debt. However, quality isn’t just a technical concern, it is an economic and strategic one.
The Evolution of Done Over Time
New teams often start with a weak DoD that doesn’t yet guarantee releasability. A brownfield product with legacy constraints may have a DoD that initially excludes automation, testing, or continuous deployment due to existing technical debt. Over time, through Sprint Retrospectives and deliberate improvements, the DoD should:
- Start at a minimal viable level (e.g., basic testing, peer reviews).
- Expand to include automated testing, security checks, and CI/CD.
- Reach a state where every increment is truly releasable.
An experienced Scrum Team should aim for a DoD that ensures shippability at the end of every Sprint. Anything less introduces unnecessary risk and delays value realisation.
Common Misconceptions
Can the DoD Change Per Sprint?
Yes, but only to increase quality. The Sprint Retrospective is the right place to discuss DoD improvements, not reductions. However, if an issue arises, address it immediately, don’t wait for the Retrospective.Can the DoD Be Lowered to Deliver More Features?
No. Quality is a long-term investment, not a short-term lever to pull for speed. A Scrum Team has no authority to cut quality, that’s a financial and risk decision made at the highest level. This authority rarely sits with project managers or middle management. If someone asks you to lower quality, tell them to get it in writing from the financial director.
Can We Have Different DoDs Per Backlog Item?
No. The DoD is a universal standard applied to all work, ensuring consistency in quality. Acceptance Criteria define specific conditions for a backlog item, but these conditions do not belong in the DoD.
Should the DoD Be Fluid and Change Every Sprint?
No. A fluctuating DoD signals dysfunction unless it’s always improving. Constant changes undermine transparency and disrupt planning. Evolution should be deliberate, incremental, and focused on raising quality, not shifting goalposts.
Subscribe to Martin's articles
Writing since 2006
Articles, usually weekly on Mondays. One click to leave.
DoD as a Strategic Lever
A strong DoD isn’t just about engineering, it’s about protecting revenue, managing risk, and ensuring predictable delivery. Weak DoD practices lead to costly rework, delayed releases, and customer dissatisfaction. By embedding security, compliance, and quality checks into the development cycle, organisations reduce their exposure to financial and reputational risks. Teams that consistently meet a well-defined DoD can deliver with greater confidence, improving forecasting and market responsiveness.
A strong DoD reduces rework, increases predictability, and aligns technical work with business value. As organisations evolve, so should their quality expectations. This continuous refinement is not just a technical necessity, it’s a competitive advantage.
Enjoyed this? One click, no account.
Questions this answers
What is a Definition of Done in Scrum and how should it evolve over time?
The Definition of Done is an objective, measurable standard of quality that every Increment must meet before it is considered complete, and it is expected to evolve as a Scrum Team gains experience and capability. Teams typically start with a minimal viable DoD and, through retrospectives and deliberate improvements, expand it to include practices like automated testing, security checks, and CI/CD until every increment is truly releasable at the end of each Sprint.
What should be included in an organisational Definition of Done and how does it relate to team-level DoD?
An organisational Definition of Done should capture business-level quality criteria such as regulatory compliance, market readiness, customer experience feedback, financial viability, and alignment with company objectives. Each Scrum Team then interprets and applies this organisational DoD within its own context by shaping an engineering-level DoD that aligns to these organisational expectations while defining the technical practices needed to meet them.
Can the Scrum Definition of Done change, be lowered, or differ per backlog item?
The Definition of Done can change, but only to increase quality and typically via Sprint Retrospectives; it should not be lowered to deliver more features, as cutting quality is a high-level financial and risk decision beyond the Scrum Team. The DoD is a universal standard that applies to all work, so different DoDs per backlog item are not appropriate, and frequent, non-improving changes to the DoD are a sign of dysfunction.
Smart Classifications
Each classification [Concepts, Categories, & Tags] was assigned using AI-powered semantic analysis and scored across relevance, depth, and alignment. Final decisions? Still human. Always traceable. Hover to see how it applies.