The Definition of Ready and Its Dangers
The article “The Definition of Ready and Its Dangers” by Mike Cohn on Mountain Goat Software explores the concept of a ‘Definition of Ready’ in Scrum teams. This definition acts as a set of criteria determining whether a product backlog item is ready for a sprint. It’s likened to a bouncer at a nightclub, only allowing certain user stories to enter the iteration based on specific conditions like size, detailed acceptance criteria, and resolved external dependencies.
While a Definition of Ready can prevent problems like oversized stories or unresolved dependencies from entering a sprint, it’s not always beneficial. It can lead to a stage-gate approach, where one stage must be completed before moving to the next, potentially hindering agility. This approach contrasts with the concurrent engineering practice in Agile, where overlapping activities like analysis, design, coding, and testing are encouraged.
Cohn advises caution with the Definition of Ready, suggesting it should be used more as guidelines than strict rules. He emphasizes the importance of allowing some degree of subjectivity and flexibility to maintain agility and avoid regressing to a waterfall approach.
Balancing Rigidity and Flexibility: To ensure that the Definition of Ready (DoR) does not become overly rigid and hinder the Agile process, teams can adopt a few strategies:
- Iterative Refinement: Treat the DoR as a living document that evolves based on team experiences and project needs. Regularly review and adjust it to prevent it from becoming a bottleneck.
- Empower Team Decision-Making: Encourage team members to use their judgment in determining if a backlog item meets the DoR. This approach fosters a sense of ownership and responsibility, which is crucial in Agile methodologies.
- Focus on Principles, Not Rules: Emphasize the principles behind the DoR, such as ensuring clarity and feasibility, rather than strict adherence to specific criteria. This approach maintains the spirit of Agile – flexibility and adaptability.
Concurrent Engineering in Agile: To effectively integrate contemporary engineering while maintaining a DoR, teams can:
- Overlap Phases with Caution: Allow for some overlap in development phases, such as design and coding, while ensuring that essential criteria in the DoR are met to avoid significant rework.
- Incremental Readiness: Adopt a phased approach where items meet essential readiness criteria initially and are further refined as they move through the sprint. This method allows for continuous improvement and adaptation.
- Collaborative Cross-Functionality: Encourage cross-functional collaboration where team members with different expertise contribute to refining backlog items, ensuring they meet the DoR while promoting concurrent activities.
Customizing the Definition of Ready: To tailor the DoR to specific team needs without compromising Agile principles:
- Team-Specific Criteria: Develop DoR criteria based on the unique challenges and strengths of the team. This customization ensures the DoR is relevant and practical for the team’s context.
- Feedback Loops: Implement regular feedback sessions to discuss the effectiveness of the DoR. Use insights from these discussions to make necessary adjustments.
- Balance with Agile Values: Ensure that any customization aligns with core Agile values like collaboration, customer focus, and responsiveness to change. The DoR should enhance, not hinder, these values.