As an experienced agile and leadership coach, I’ve seen teams grapple with the concept of the Definition of Done (DoD) more times than I can count. It’s one of those seemingly simple ideas that can make or break your agile practice. Today, I want to share some surprising aspects of the DoD that you might not have considered before.
Why Do We Need a DoD?
First off, let’s clarify why the DoD is crucial:
- Alignment on Expectations: It ensures everyone agrees on what “done” actually means. For instance, if a developer thinks “coded and running on QA” is “done,” but the product manager assumes “done” means fully tested and deployed to production, you can see how misalignment happens. By agreeing on a shared Definition of Done, we eliminate these misunderstandings.
- Quality Assurance: It sets a baseline for the minimum quality and completeness of work. This is essential for maintaining consistent delivery standards across the team.
- Transparency: It makes the team’s progress and workflow transparent to all stakeholders, reducing the chances of unpleasant surprises down the line.
DoD vs. Acceptance Criteria: Know the Difference
It’s easy to confuse the DoD with acceptance criteria, but they’re not the same.
- Definition of Done (DoD):
- A set of non-functional requirements (NFRs) that apply to all user stories.
- Includes cross-cutting concerns like performance, security, or language support.
- Represents the team’s workflow agreements and quality standards.
- Example: Instead of specifying “feature must be available in English and German” in every user story, we include it once in the DoD.
- Acceptance Criteria:
- Specific to each user story or feature.
- A checklist of what needs to be fulfilled for that particular item.
- Focuses on the functional requirements and expected behavior.
- Example: For a login feature, acceptance criteria might include “user can log in with email and password” and “error message must not reveal if user is in the database.”
When we accept a story and declare it ready for the customer, both the specific acceptance criteria and the general DoD should be fulfilled.
Actionable Tip: Encourage your team to maintain a concise DoD that covers overarching quality aspects, and let acceptance criteria handle the specifics of each story.
The Pitfall of an Extensive Upfront DoD
I’ve witnessed managers draft DoDs that span two pages, loaded with bureaucratic hurdles, excessive documentation, and unnecessary safety checks.
- Why This Is a Problem:
- Slows Down Development: A lengthy checklist can paralyze progress. Teams spend more time on paperwork than delivering value.
- Breeds Distrust: Often reflects a lack of trust in the team’s abilities. It shows managers don’t believe teams can make the right decisions.
- Reduces Agility: Long feedback cycles (think 2-3 months) are the antithesis of agile. In some cases, a bloated DoD made it impossible to ship a feature in less than 6 months.
- Real-World Example:
- Managers included all kinds of unnecessary items from their scaled environment, such as redundant documentation efforts and restrictive controls that stifled team autonomy.
- This approach mirrored old project management thinking, where a manager coordinates hand-offs between teams, rather than empowering teams to coordinate directly.
Actionable Tip: Keep the DoD lightweight. Ask yourselves, “What can we remove or solve in a different way?” rather than “What else can we add just in case?”
DoD Over DoR: Ditch the Definition of Ready
I consider the Definition of Ready (DoR) an anti-pattern in agile environments.
- Issues with DoR:
- Acts as a phase-gate, hindering flow. It’s an arbitrary checkpoint that can stall progress.
- Separates Thinking from Doing: Encourages a hand-off mentality between product and development teams, reminiscent of outdated scientific management theories by Taylor.
- Creates Blame Games: Becomes a tool for pointing fingers rather than fostering collaboration. I’ve seen teams where product management and developers use the DoR to blame each other when things go wrong.
- Real-World Example:
- In one company, they produced months or even years’ worth of “user stories” before hiring any development teams. This approach is the antithesis of agile, which values early and continuous delivery of valuable software.
- How a Good DoD Helps:
- Unifies the Team: Aligns both product and development on what “done” means, fostering a shared understanding and collaboration.
- Eliminates Unnecessary Gates: Focuses on delivering a working product rather than meeting arbitrary checkpoints.
- Empowers Self-Managing Teams: Teams decide how they work, rather than being dictated by external managers.
Actionable Tip: Focus on refining your DoD to encompass the team’s shared understanding and goals, making a DoR redundant.
See also the related article The Danger of the Detached Product Owner
Adapt Your DoD Over Time
Your DoD isn’t set in stone; it should evolve with your team.
- During Retrospectives:
- Identify recurring issues or quality gaps.
- Add new agreements to the DoD to address these areas.
- Example:
- If you’re fighting with lots of bugs, you might find that hard-to-understand code is the culprit. A solution could be to implement pair programming or ensure that all code follows the red-green-refactor cycle.
- You might add to the DoD: “Each piece of code must have been reviewed or, better yet, developed through pair programming,” and “Code must be refactored where necessary.”
- Evolving Practices:
- As new workflows become ingrained, you might remove certain items from the DoD. For example, if automated testing becomes second nature, there’s no need to keep it explicitly in the DoD.
- You can keep a copy for onboarding new colleagues, but better rely on pairing or face-to-face communication rather than bogging down the DoD.
Actionable Tip: Use retrospectives to regularly revisit and update the DoD, ensuring it remains relevant and effective.
Starting with an Empty DoD
Believe it or not, I often advise teams to start with an almost empty DoD.
- Why This Works:
- Avoids Overwhelm: Teams aren’t bogged down by a massive checklist from day one.
- Promotes Ownership: The team builds the DoD based on actual needs and experiences.
- Encourages Continuous Improvement: Gaps become evident naturally, prompting timely additions.
- Real-World Scenario:
- I usually ask the team to have no DoD initially, or maybe just 2 or 3 essential items.
- After the first review and retrospective, things become evident. If we failed in the review because of varying understandings of “done,” we can add this new understanding to the DoD.
Actionable Tip: Begin with the bare essentials in your DoD and let it grow organically through team collaboration and reflection.
Tailoring the DoD to Your Team’s Technical Excellence
One size doesn’t fit all when it comes to the DoD.
- For Novice Teams:
- May need explicit reminders: “Run the linter before committing code,” “Ensure all tests pass before merging,” or “Deploy the solution to the staging server.”
- Example: For someone new to software development, these steps might not be second nature and need to be spelled out.
- For Experienced Teams:
- These practices are second nature and need not be spelled out.
- The DoD can focus on more advanced quality measures or innovative practices.
Actionable Tip: Assess your team’s skill level and customize the DoD to provide just enough guidance without stating the obvious.
The Scaled DoD: Handling Complex Environments
In large-scale or complex projects, a single DoD might not suffice.
- Multiple Levels of DoD:
- Team Level: Immediate quality checks and standards.
- Program Level (e.g., Agile Release Train in SAFe): Broader concerns like compliance.
- Solution Level: Long-term goals like full internationalization.
- Real-World Example:
- With large and complex products in a scaled environment, we often cannot do everything we would love to get done in an iteration like a two-week sprint.
- For example, translating each feature into 20 languages during each sprint might not be feasible. The team could opt for only two languages (to prove the internationalization capability) and then add the remaining translations later during the Program Increment (PI).
- Be Cautious:
- Avoid Hiding Undone Work: Be transparent about what isn’t covered at each level.
- Maintain Agility: Don’t let additional DoDs become bottlenecks.
Actionable Tip: Clearly define the scope of each DoD level and ensure they complement rather than complicate each other. When taking this approach, consider the risk of unintentionally hiding undone work.
Final Thoughts: Keep It Collaborative and Agile
Remember, the DoD is a living agreement that should empower your team, not constrain it.
- Promote Self-Management: Let the team define how they work best. The DoD and acceptance criteria should be defined by the team working on the product. While you can add constraints from outside the team, it’s usually not a good idea for a manager to write the DoD without team involvement.
- Foster Open Communication: Use face-to-face interactions or pairing to onboard new team members, rather than relying solely on documentation.
- Stay Agile: Continuously adapt and improve your DoD to meet the evolving needs of your project and team.
Actionable Tip: Regularly revisit the DoD in team meetings to ensure it remains a tool for alignment and quality, not a bureaucratic hurdle.
By focusing on these often-overlooked aspects of the Definition of Done, you can enhance your team’s agility, foster better collaboration, and deliver higher-quality products more efficiently. Keep the DoD lightweight, adaptable, and team-driven, and you’ll be well on your way to agile success.
Thank you for reading The Agile Compass. I’m Matthias, here to help you help those around you become agile.
To get more, consider upgrading to a paid subscription. You’ll join our premium Discord community and get access to all past articles.