EP147 – Done Right: The DoD Explained

To minimize technical debt, teams should prioritize high-value features and build quality into their work. A well-defined Definition of Done (DoD) is crucial for maintaining quality, managing expectations, and ensuring a smooth development process. #AdvancedQualityPrograms #TheQualityGuy #DoD #Done

“Take responsibility for quality, not external factors. As Shakespeare said in ‘Julius Caesar’, ‘The fault, dear Brutus, is not in our stars, but in ourselves.’”

Definition of Ready

Let’s start from the top, Definition of Ready. Many agile teams use a Definition of Ready (DoR) to help them with the planning process. This is often an overlooked tool that can yield powerful results for the team.

It creates an agreement on the expectations that define success when bringing an item or story into the development process, preventing wasted time and resources.

A Definition of Ready (DoR) can apply to various work items, including inputs, backlog tasks, ideas, or product features. Its primary function is to determine readiness for development. Commonly used for creating requirements lists, the DoR helps teams decide if user feedback is sufficiently developed for inclusion in a task.

The team collaboratively defines the DoR, regularly updating it based on lessons learned. Essential elements include clear articulation of business value and a commitment to task completion before the next development meeting.

A Definition of Ready (DoR) fosters consistent expectations, reduces rework, and enhances team accountability. It’s essential to avoid overcomplicating the process, as open communication remains vital. A well-implemented DoR significantly improves the overall development process.

Definition of Done

This brings us to the Definition of Done (DoD), which clarifies what constitutes a completed work item. It applies to various project elements, including inputs, backlog tasks, ideas, and product features. By defining completion criteria, the DoD prevents rework, improves efficiency, and ensures shared understanding within the team.

A DoD helps teams define tasks, estimate work, develop accountability, and set expectations. It is a list of criteria developed by the team and updated as needed to meet the needs of the team and stakeholders. It’s a self-management tool that enables continuous improvement.

Including technical excellence in the DoD is crucial for successful development. This means defining what it takes to meet requirements correctly, not just quickly, thereby preventing the need for refactoring and rework later. Examples of DoD criteria include peer-reviewed code, completed documentation, and thorough testing.

A DoD should apply to all items the team is working on, including all user requirements. One benefit of a DoD is that it guides the team in estimating during team planning meetings. For example, if a developer estimates a requirement will take six hours to develop, they should also consider the time needed for review, testing, documentation, and other tasks. This often leads to more accurate and comprehensive estimates.

Technical Debt

When development teams work quickly without considering the product vision and roadmap, they often take shortcuts, leading to what we call technical debt. This is the most obvious cost incurred from cutting corners during the development process and is particularly evident in teams that misunderstand Agile by focusing entirely on the current development task without considering the bigger picture. Excessive technical debt slows down the team’s pace and delivery over time as these earlier shortcuts create more work for the team to correct and add new functionality.

However, some technical debt can be used strategically, especially during experiments and prototyping where shortcuts are taken to learn and commit to a technical path later.

To minimize technical debt, two key steps are essential.

First, having a solid, value-based product vision and roadmap.

Second, a meaningful DoD that emphasizes quality and technical excellence.

This long-term perspective helps the team make daily technical decisions that align with the overall strategy, reducing future refactoring and rework. It also keeps the team accountable for their estimates and workload.

A product owner should closely monitor technical debt as it can compromise future development processes, product flexibility, performance, modifications, and overall architecture, leading to extended time-to-market for new features. This can result in customer frustration due to product issues and slow response times. Additionally, developers’ morale may suffer from dealing with a messy tasks and delayed market delivery.

To reduce technical debt, teams should first identify which functions and features are highly valued and focus their development efforts on these. They should agree to build quality into their estimates to avoid creating a messy product delivery. Maintaining a well-created DoD ensures quality, sets clear expectations, and reduces technical debt and cleanup work. It helps teams maintain a smooth flow and pace. For product owners and project managers, facilitating the creation and understanding of a meaningful DoD is crucial.

“Alone we can do so little; together we can do so much.”

– Helen Keller