Add the Definition of Ready to Your Agile Toolkit for Predictable Delivery by Jennifer Parker
As teams embrace agile, they often adopt a team-centric “Definition of Done” as part of their norming process. Developing a definition of done is critical in calibrating and aligning the team on what it looks like to complete a story or epic.
Although this is a critically important piece, it alone is not a guarantee of success. Before delving into additional norming activities that can help a project be successful, it’s important to highlight what a Definition of Done is and how a team can define one.
What is the Definition of Done?
Simply put, the Definition of Done is a set of criteria or conditions that must be met for a story or epic to be considered complete and shippable. It encompasses all the tasks, activities, and quality standards necessary to deliver a valuable increment of work. While the Definition of Done may vary from one team to another or from one project to another, it typically includes elements such as coding standards, testing requirements, documentation, integration, and user acceptance.
Why is the Definition of Done Important?
Quality Assurance: By clearly defining what constitutes "done," the team ensures that all work meets a consistent standard of quality. This helps prevent the accumulation of technical debt and reduces the likelihood of defects or bugs slipping through the cracks.
Transparency: The Definition of Done provides transparency and clarity regarding the expectations for each story. It helps stakeholders understand what they can expect to receive at the end of each sprint, fostering trust and alignment within the team and with external stakeholders.
Incremental Delivery: Adopting a clear Definition of Done enables the team to deliver incremental value to the customer at the end of each sprint. This iterative approach allows for faster feedback cycles, enabling the team to course-correct and adapt to changing requirements more effectively.
Team Collaboration: Defining the Definition of Done is a collaborative effort that involves the entire Scrum team, including developers, qa, product owners, and other stakeholders. This collaborative process encourages shared understanding and accountability, fostering a sense of ownership and teamwork within the group.
Continuous Improvement: The Definition of Done is not set in stone but evolves over time as the team learns and improves. By reviewing and refining the Definition of Done as part of the retrospectives, the team can identify areas for improvement.
How can a team define done?
Hold a brainstorming/norming meeting where all stakeholders and team members help to identify what “done” looks like. After all ideas are on the table, have the team rank them and agree on which ones are important to include initially. Once the team agrees, document the team’s definition of done and refer to it during sprint reviews and retrospectives to review work completed and make any adjustments as needed.
Why is this not enough to ensure success?
Often times, especially as an organization or team is adopting agile, there is a gap between expectations of when a story is ready to be worked on and what discovery looks like. If a team takes in a story before it’s ready to be worked on, there is a huge risk that the story will not be able to be completed or that it will far surpass the estimates given by the team.
When a story isn’t ready to be implemented, the development team is likely to spin their wheels. Anyone picking up the story will have to do all the legwork of tracking down requirements. When the requirements are ambiguous, there is a high likelihood of rework as additional discovery happens.
Adopting this loose methodology means that the team is not going to be able to predictably deliver. It means that velocity and other metrics that the organization may want to track are meaningless. There is no way to predict when stories will be finished. Some sprints may go smoothly and some may be complete chaos as developers scramble to understand “just-in-time” requirements.
Adopting a “Definition of Ready” can combat this and help to expose gaps in knowledge, discovery, and requirements gathering early.
Why is the Definition of Ready Important?
Developer Productivity: If the story is well-defined and ready to be implemented, developers will not have to do as much leg work.
Quality: As part of the definition of ready, QA will be able to begin to plan testing and think about what test cases should be part of the Definition of Done of the story.
Predictable Delivery: Because stories are well-defined, the team will be able to achieve a predictable velocity barring any other team changes in about three sprints. This leads to the product organization having a better forecasting method for determining when MVPs and other features can be delivered.
Organizational Trust: Stories that are clearly defined will meet the expectations of the organization without as much rework, leading to organizational trust and confidence in the team and the project.
Like “Definition of Done,” the entire team should be involved in defining the “Definition of Ready.” The Definition of Ready should be front-and-center during any sprint refinement meetings to help get stories ready for bringing in to a sprint. Likewise, the Definition of Ready is imperative during sprint planning activities to ensure the team is confident and comfortable committing to the items being brought in.
Further, by creating a deep backlog with stories that have been clearly defined, scrum masters and the PMO now have the flexibility of creating cohesive sprint goals that align with clear business initiatives, creating a better outcome for your organization.
Key Takeaways
To obtain a high functioning and predictable software delivery team, it’s critical the team understands the work in detail. Defining not only what “done” looks like but also what it means for a story to be “ready” means far less is left to chance and teams become more predictable as a direct outcome.