Skip to content

Commit 8c9c9dd

Browse files
MrHinshMrHinsh
authored
2025 03 17 your evolving definition of done (#347)
2 parents 87c6aa3 + 6d0a6f8 commit 8c9c9dd

File tree

9 files changed

+2069
-9
lines changed

9 files changed

+2069
-9
lines changed

‎site/content/categories/scrum/_index.md

+2
Original file line numberDiff line numberDiff line change
@@ -22,4 +22,6 @@ headline:
2222
subtitle: A framework for collaborative problem-solving that maximises value delivery through iterative learning and continuous improvement.
2323
content: A structured approach for fostering collaboration and enhancing team performance, emphasising iterative progress and adaptive planning. Posts should explore team dynamics, roles, ceremonies, and techniques for maximising value delivery, as well as methods for continuous learning and improvement in complex environments.
2424
updated: 2025-02-13T21:02:24Z
25+
2526
---
27+

‎site/content/resources/blog/2025/2025-03-17-your-evolving-definition-of-done/data.index.classifications.json

+1,874
Large diffs are not rendered by default.

‎site/content/resources/blog/2025/2025-03-17-your-evolving-definition-of-done/index.md

+122
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,122 @@
1+
---
2+
title: Your Evolving Definition of Done
3+
description: Evolve your Definition of Done (DoD) to align with organisational goals, ensuring quality and strategic value in every product increment.
4+
ResourceId: 5wIEg7lD_Xd
5+
ResourceType: blog
6+
ResourceImport: false
7+
date: 2025-03-31T09:00:00
8+
weight: 225
9+
AudioNative: true
10+
creator: Martin Hinshelwood
11+
layout: blog
12+
resourceTypes: blog
13+
aliases:
14+
- /resources/5wIEg7lD_Xd
15+
aliasesArchive:
16+
- /your-evolving-definition-of-done
17+
- /blog/your-evolving-definition-of-done
18+
categories:
19+
- Social Technologies
20+
- Scrum
21+
tags:
22+
- Definition of Done
23+
- Software Development
24+
- Scrum Product Development
25+
- Strategy
26+
- Professional Scrum
27+
- Value Delivery
28+
- Engineering Practices
29+
- Product Delivery
30+
- Agile Product Management
31+
- Practical Techniques and Tooling
32+
- Shift-Left Strategy
33+
---
34+
35+
The [Definition of Done (DoD)]({{< ref "/tags/definition-of-done" >}}) is not a static artefact; it evolves over time as a [Scrum Team]({{< ref "/tags/scrum-team" >}}) gains experience and capability. While the [Scrum Guide]({{< ref "/resources/guides/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.
36+
37+
The [Definition of Done (DoD) is an objective, measurable standard of quality]({{< ref "/resources/blog/2025/2025-01-03-definition-of-done-objective-vs-subjective" >}})—not a negotiable target. Keep it clear, enforceable, and automated to ensure every Increment meets professional expectations.
38+
39+
## Definition of Done - The Organisational quotient
40+
41+
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.
42+
43+
This means organisations should define a business DoD that may include:
44+
45+
- Regulatory compliance
46+
- Market readiness (e.g., beta testing completion, go-to-market strategies)
47+
- Customer experience and feedback incorporation
48+
- Financial viability assessment
49+
- Alignment with broader company objectives
50+
51+
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:
52+
53+
> Live an in production
54+
>
55+
> gathering telemetry
56+
>
57+
> supporting or diminishing
58+
>
59+
> the starting hypothesis
60+
61+
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.
62+
63+
1. "Live an in production" - done here mean that it is in the hands of real users
64+
65+
2. "gathering telemetry" - done here mean that the Developers must add code that collects relevant information from usage, performance, and such...
66+
67+
3. "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.
68+
69+
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.
70+
71+
## Definition of Done - Translating Organisational Standards into Team Practice
72+
73+
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]({{< ref "/resources/blog/2025/2025-03-12-balance-of-leadership-and-control-in-scrum" >}}) that upholds both autonomy and accountability. Scrum isn’t anarchy; it’s a [social technology]({{< ref "/categories/social-technologies" >}}) that enables self-management within clear constraints—Scrum events, commitments, and organisational expectations.
74+
75+
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.
76+
77+
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]({{< ref "/tags/engineering-practices" >}}), preferably within the bounds of a [shift-left strategy]({{< ref "/tags/shift-left-strategy" >}}), such as:
78+
79+
- **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.
80+
81+
- **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.
82+
83+
- **Adhering to Security and Compliance Requirements** – try embeding security scanning into [CI/CD pipelines]({{< ref "/tags/continuous-delivery" >}}) with automated dependency checks and policy enforcement, catching vulnerabilities before they reach production—and preferably treating security as code, ensuring it evolves alongside development.
84+
85+
- **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).
86+
87+
- **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.
88+
89+
Each aspect contributes to quality, reducing the likelihood of defects and [technical debt]({{< ref "/tags/technical-debt" >}}). However, quality isn’t just a technical concern—it is an economic and strategic one.
90+
91+
## The Evolution of Done Over Time
92+
93+
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]({{< ref "/tags/deployment-frequency" >}}) due to existing technical debt. Over time, through Sprint Retrospectives and deliberate improvements, the DoD should:
94+
95+
1. Start at a minimal viable level (e.g., basic testing, peer reviews).
96+
2. Expand to include automated testing, security checks, and CI/CD.
97+
3. Reach a state where every increment is truly releasable.
98+
99+
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.
100+
101+
#### Common Misconceptions
102+
103+
1. **Can the DoD Change Per Sprint?**\
104+
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.
105+
106+
2. **Can the DoD Be Lowered to Deliver More Features?**
107+
108+
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.
109+
110+
3. **Can We Have Different DoDs Per Backlog Item?**
111+
112+
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.
113+
114+
4. **Should the DoD Be Fluid and Change Every Sprint?**
115+
116+
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.
117+
118+
## DoD as a Strategic Lever
119+
120+
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.
121+
122+
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.

‎site/content/tags/agile-project-management/_index.md

+26
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,30 @@
11
---
22
title: Agile Project Management
3+
date: 2025-03-17T14:46:20Z
4+
description: Agile Project Management focuses on iterative progress, collaboration, and flexibility, enabling teams to adapt quickly to changes and deliver value efficiently.
5+
Instructions: |-
6+
**Use this category only for discussions on Agile Project Management.**
7+
Agile Project Management is centred around iterative progress, collaboration, and flexibility, allowing teams to respond swiftly to changes and deliver value efficiently. This category encompasses methodologies and practices that promote adaptive planning, evolutionary development, and continuous improvement.
8+
9+
**Key Topics:**
10+
- Principles and values of the Agile Manifesto
11+
- Iterative and incremental development processes
12+
- Roles and responsibilities within Agile teams (e.g., Scrum Master, Product Owner)
13+
- Agile frameworks such as Scrum, Kanban, and Extreme Programming (XP)
14+
- Techniques for effective collaboration and communication in Agile teams
15+
- Tools and practices for managing Agile projects (e.g., user stories, sprints, retrospectives)
16+
- Metrics and performance indicators for Agile project success
17+
- Strategies for scaling Agile practices across larger organisations
18+
- Challenges and solutions in implementing Agile methodologies
19+
20+
**Strictly exclude** discussions on unrelated project management methodologies (e.g., Waterfall), non-Agile frameworks, or misinterpretations of Agile principles that do not align with the core philosophies of Agile Project Management.
21+
headline:
22+
cards: []
23+
title: Agile Project Management
24+
subtitle: Dynamic project oversight emphasising iterative progress, team collaboration, and adaptability to deliver consistent value in complex environments.
25+
content: A framework for managing projects that prioritises iterative development, team collaboration, and responsiveness to change. It encompasses practices for visualising workflows, enhancing communication, and fostering continuous improvement, while addressing complexity and uncertainty in project environments. Topics include team dynamics, process optimisation, and value delivery.
26+
updated: 2025-03-17T14:46:22Z
327
trustpilot: false
28+
429
---
30+

‎site/content/tags/definition-of-done/_index.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -23,8 +23,8 @@ headline:
2323
subtitle: Ensuring Quality, Transparency, and Releasability
2424
content: The **Definition of Done (DoD)** establishes a shared understanding of what makes a product increment **complete and releasable**, ensuring all work meets a **minimum quality standard**. It enhances transparency, consistency, and empirical decision-making by providing clear criteria for done work. This includes an Organisational Definition of Done that applies across teams, with team-specific extensions as needed. A well-defined DoD is essential for adaptation, accountability, and delivering valuable, verifiable, and production-ready increments.
2525
updated: 2025-02-13T12:05:05Z
26-
---
2726

27+
---
2828
The **Definition of Done (DoD)** establishes a shared understanding of what constitutes a **completed and releasable** product increment. It ensures that all work meets a **minimum quality standard**, providing transparency, consistency, and the ability to make **empirical decisions** based on real-world feedback.
2929

3030
This document outlines the **Organisational Definition of Done**, which applies across all teams, as well as **team-specific extensions** that may be necessary based on product requirements. It also highlights why the DoD is essential for **transparency, adaptation, and ensuring that every increment is valuable, verifiable, and production-ready**.

‎site/content/tags/shift-left/_index.md

+36
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,36 @@
1+
---
2+
title: Shift-Left Strategy
3+
date: 2025-03-17T14:46:11Z
4+
trustpilot: false
5+
description: A **Shift-Left Strategy** brings testing, security, and compliance earlier in development, reducing defects, accelerating feedback, and improving quality for faster, more reliable delivery.
6+
Instructions: |-
7+
**Use this category only for discussions on Shift-Left Strategy.**
8+
The Shift-Left Strategy focuses on integrating critical processes such as testing, security, and compliance earlier in the software development lifecycle. This proactive approach aims to identify and address potential issues sooner, thereby enhancing software quality, reducing defects, and facilitating faster feedback loops, ultimately leading to more reliable delivery.
9+
10+
**Key Topics:**
11+
- Principles and benefits of the Shift-Left Strategy in software development.
12+
- Techniques for integrating testing, security, and compliance early in the development process.
13+
- Case studies demonstrating the effectiveness of Shift-Left practices.
14+
- Tools and methodologies that support a Shift-Left approach.
15+
- The role of collaboration and communication in implementing Shift-Left strategies.
16+
- Metrics for measuring the impact of Shift-Left initiatives on software quality and delivery speed.
17+
18+
**Strictly exclude:**
19+
- Discussions unrelated to software development processes.
20+
- Misinterpretations of the Shift-Left concept, such as focusing solely on post-development testing or security measures.
21+
- General Agile or DevOps principles that do not specifically address the Shift-Left Strategy.
22+
headline:
23+
cards: []
24+
title: Shift-Left Strategy
25+
subtitle: Proactively integrate testing, security, and compliance early in development to enhance quality, speed, and reliability of software delivery.
26+
content: A proactive approach integrates essential processes such as testing, security, and compliance early in the development lifecycle. This strategy enhances software quality and reliability by minimising defects, fostering rapid feedback, and ensuring that teams can deliver value more efficiently. Topics include risk management, continuous integration, and quality assurance.
27+
updated: 2025-03-17T14:46:14Z
28+
---
29+
30+
### **Shift-Left Strategy: Enhancing Quality from the Start**
31+
32+
In modern software development, waiting until the end to test, secure, or review compliance is a costly mistake. The **Shift-Left Strategy** eliminates these risks by integrating critical activities—testing, security, and compliance—early in the development lifecycle.
33+
34+
By shifting left, teams detect defects sooner, reduce rework, and accelerate feedback loops. This approach enhances software quality, speeds up delivery, and ensures reliability from day one. Whether through **automated testing, security as code, or continuous integration**, embracing a Shift-Left Strategy is a fundamental step towards high-performing, agile, and DevOps-driven teams.
35+
36+
Don’t wait—**shift left and build quality in from the start**.

‎site/layouts/categories/list.html

+2-2
Original file line numberDiff line numberDiff line change
@@ -72,7 +72,7 @@ <h2>Categories</h2>
7272
{{ range $category, $pages := .Site.Taxonomies.categories }}
7373
<div class="col-md-3 d-flex align-items-center">
7474
<span class="text-truncate d-inline-block" style="max-width: 100%;" title="{{ .Page.Title }}">
75-
<a href="{{ .Page.Permalink }}">{{ .Page.Title }}</a>
75+
<a href="{{ .Page.Permalink }}" title="{{ .Page.Title }} - {{ .Page.Description }}">{{ .Page.Title }}</a>
7676
</span>
7777
{{- $count := len (where $pages "Draft" "!=" true) }}
7878
<span class="ms-1">({{ $count }})</span>
@@ -87,7 +87,7 @@ <h2>Tags</h2>
8787
{{ range $category, $pages := .Site.Taxonomies.tags }}
8888
<div class="col-md-3 d-flex align-items-center">
8989
<span class="text-truncate d-inline-block" style="max-width: 100%;" title="{{ .Page.Title }}">
90-
<a href="{{ .Page.Permalink }}">{{ .Page.Title }}</a>
90+
<a href="{{ .Page.Permalink }}" title="{{ .Page.Title }} - {{ .Page.Description }}">{{ .Page.Title }}</a>
9191
</span>
9292
{{- $count := len (where $pages "Draft" "!=" true) }}
9393
<span class="ms-1">({{ $count }})</span>

0 commit comments

Comments
 (0)