This article originally appeared in the March 2013 edition of Web and PHP magazine and is republished with permission.
Last month, I wrote about the need for development teams to develop increments of functionality that are “done” but what does that mean exactly? This article will explore the concepts of the definition of ready and the definition of done and will help you better understand how using them can help you successfully deliver increments of functionality in a sprint.
Two challenges agile teams face is building a common understanding of when a backlog item is ready to sprint and when they are done. There are two simple checklists teams can build to achieve this conveniently called the definition of ready and the definition of done.
The definition of ready is an agreement between the Product Owner and the development team as to what needs to happen before the team can consider a backlog item ready to work on in a sprint. It should contain a mix of activities for both the Product Owner and the team.
Table 1 below shows an example definition of ready.
|Backlog item is estimated by the team|
|Backlog item contains clear success criteria|
|The team feels comfortable taking this backlog item into the sprint|
|The team understands the impact of this feature on the existing system|
Table 1-Sample definition of ready
Teams can build their definition of ready early in the project but they should make it evolve continuously throughout the project. The challenge in building this definition is finding the right balance between all the up-front work a team can potentially do in a traditional project and the lightweight requirements of an agile project.
The purpose of the definition of ready is to gather the information needed to help the team rapidly build a common understanding of a backlog item.
Backlog maintenance sessions
It is normal for teams to spend ten to fifteen percent of the available time in a sprint preparing the next sprint. Preparation is the key to having backlog items ready when the team is examining them in the sprint planning meeting. One best practice teams use is to hold regular backlog maintenance (or grooming) sessions during a sprint.
In these sessions, the teams review the highest priority backlog items for the next sprint to build a common understanding of them before the sprint planning meeting. Teams can also use these sessions to review each high priority backlog item and see if it meets their definition of ready.
Including all team members in these work sessions also allows the team to build a common understanding of the backlog item before they begin working on it, which will increase the efficiency of the sprint planning meeting.
Other possible activities in the backlog maintenance sessions include breaking down backlog items in multiple smaller slices to allow them to have pieces they can complete in a sprint or estimating any new backlog items. Doing regular maintenance sessions allows the team to progressively break down items in the Product Backlog in a timely manner as they are getting closer to working on them.
The definition of done
The definition of done helps teams better understand everything they need to do to deliver completed increments of software to a production environment. It is a checklist the team can use to make sure they did everything they needed to do before making the feature available to users.
I have a simple trick to help you understand what belongs in a definition of done. The next time your team tells you they completed a backlog item ask them to put it in production right away. After the big gasp of fear, they will start telling you what they still need to do which can be anything from performance testing, to code reviews, to externalizing strings for translation. Whatever they tell you probably belongs in their definition of done.
Teams should build their definition of done early in the project by considering various elements such as quality, documentation, deployment, governance and approvals. Table 2 below provides examples of possible considerations for each element.
Table 2 – Potential definition of done elements
Teams must identify the right definition of done level (backlog item, sprint or release) for each item they identify. Table 3 below defines the three possible definition of done levels.
Table 3-The three levels of “Done”
Done at the backlog item level
The success conditions of a backlog item provide a checklist to allow teams to make sure they are delivering the right solution. These conditions apply to a single backlog item while the definition of done implicitly applies to all backlog items. This mean team members must consider this checklist during the sprint planning meeting when they are creating and estimating the tasks they need to carry out to complete a backlog item.
Table 4 below shows some of the typical things you will see in a definition of done at the backlog item level.
|Code review completed|
|Code integrated in source control|
|User acceptance tests performed|
|Unit tests written|
|UI text externalized|
Table 4-Backlog level definition of done
Done at the sprint level
This done level allows the team to identify work needed to deliver an increment of functionality to production and guarantee quality at the end of a sprint. For example, in some organizations teams may need to prepare deployment and rollback plans before putting in place any new functionality.
Teams can also use this definition of done level to show their quality thresholds. One team I worked with used to pile up their defects and only fixed them late in the release cycle. This created painful end of release cycles where the team had over eight hundred defects to fix. When this team decided they needed to fix all severity one and two defects as part of their definition of done, they reached the end of their release with around thirty defects which were severity three and four defects.
Table 5 below shows some of the typical things you will see in a definition of done at the backlog item level.
|All severity 1 and 2 defects are closed|
|All user stories completed and meet success conditions|
|All code changes for completed backlog items merged in the integration branch|
|All automated tests integrated in build and running successfully|
Table 5-Sprint level definition of done
Done at the release level
This definition of done provides the team with a means to ensure they are doing everything they need to in order to properly close out a release. Teams should add any governance requirements, such as architecture review board approvals or needed documentation to transfer the project to the support team at this level.
Teams should keep an eye on the items at this level throughout the release and make sure they cover all items (especially approvals) in a timely manner instead of waiting at the end of the release.
Table 6 below shows some of the typical things you will see in a release level definition of done.
|All necessary approvals received|
|All necessary deployment documentation completed|
|All severity 1 and 2 defects closed|
|All necessary user documentation completed|
Table 6-Release level definition of done
Being ready is the key to being done. The definition of ready helps teams build an agreement with their Product Owner on what they need to accept to take a backlog item in a sprint. Teams can use backlog maintenance sessions to regularly groom the product backlog and make sure the high priority items meet their definition of ready.
The definition of done is a checklist that allows teams to guarantee the quality of the increments they will deliver to the Product Owner. Teams can have a definition of done at three levels: Backlog Item, Sprint and Release. When planning their sprints, teams need to consider their definition of done and either factor it in the task estimates or create extra tasks in the sprint backlog to meet these requirements.
Checklist items the team does not complete from their definition of done becomes technical debt which the team must keep visible for themselves as well as the Product Owner. Heavy technical debt hurts the ability of the team to deliver a quality product to their customers. Needing stabilization sprints at the end of your releases is a sign your team is carrying lots of technical debt.
Putting all these pieces together will help you be more successful delivering your agile projects. Remember, it is normal to spend ten to fifteen percent of the time of a sprint preparing for the next one so feel free to plan this time and spend it wisely!
About Web and PHP Magazine
Web & PHP Magazine dives into the latest front- and back-end developments and practices in the world of PHP and web technologies, with feature articles by industry experts and innovators. Web & PHP is a community resource, so completely free to download! Visit our website at http://www.webandphp.com.