Improving Quality Standards in Scrum

In agile software development, the Definition of Done (DoD) is a formal description of the state of the Increment when it meets the quality measures required for the product. When a Product Backlog Item (PBI) meets the Definition of Done, an Increment is born. 

The DoD is an essential practice to ensure transparency and provide a shared understanding of the work completed as part of the Increment. If a PBI does not meet the DoD, it cannot be released or presented at the Sprint Review and returned to the Product Backlog for future consideration.

This post delves into the most efficient methods to tackle the Team Definition of Done and reveals vital best practices that can be adopted during various phases of your learning journey. By adhering to these fundamental techniques, you can develop the competence and awareness necessary to execute effective team strategies. Nonetheless, it's crucial to recognize that the Team Definition of Done is only a fragment of the broader context. To attain a comprehensive insight into your team's present process status, we suggest using our free agile assessment for Team Agility.

Team Definition of Done and The Learning Journey

At Lean Agile Intelligence, we recognize the Team Definition of Done is the team's ability to create and evolve common quality standards. We divided the learning journey into 4 different stages: Developing, Emerging, Adapting, and Optimizing. In the following sections, we will discuss each stage in detail as well as provide practical tips and techniques to help you strengthen your skills in this area.

Source - 5 Steps to Find Your Definition of Done (With Examples and Workflows)

Developing

Teams that are “developing” an understanding of the value of Team Definition of Done and adopting the foundational techniques should focus on the following improvements

• The What: The team has a Definition of Done for backlog items (i.e., User Stories) completed in an iteration (i.e., sprint)
  

  • The How: In order to get started with this practice, the first step is to create a definition of done for story and sprint level PBIs which acts as a working agreement to and within the development team and between the development team and the business. Start with the question… “What are the things that must be true for our PBIs to be considered potentially shippable?” The criteria for the definition of done is not specific to one PBI but will apply to potentially all PBIs.

  • Robert Galen has some fantastic thoughts on the topic. One example can be found here.

• The What: All team members are aware of the backlog item (i.e., User Story) Definition of Done and agree it should be followed

  • The How: Alignment is required to make the practice of using a definition of done successfully. If it’s created by one individual and used by some people on the team but not others it will not be valuable. It’s a good practice to co-create the DOD as a team with the product owner and clarify the details with stakeholders so everyone is in the agreement with what “done” means.

Emerging

Teams that are “emerging” beyond the foundational techniques of Team Definition of Done and are embracing it as they become more proficient, should focus on the following improvements

• The What: The team enforces the backlog item (i.e., User Story) Definition of Done (DOD) with rare exceptions and only when there is a valid, team-agreed-upon reason not to abide

  • The How: In order for the DOD to be an effective working agreement is must be owned and upheld by the team. As mentioned in the criteria above, start with an agreement about what is in the DOD and how it will be used. In addition, discuss edge cases when it might not be applicable and come to an agreement on what to do In that scenario. For instance, technical stories, research, etc might have different “done” criteria than stories or other PBi’s. Create an agreement around the differences and define a way that the members of the team will uphold the agreement. You can ask “What we will do if we don’t follow our own agreement?”

*   *   *   *   *   *

"Alignment is required to make the practice of using a definition of done successfully."

*   *   *   *   *   *

Adapting

• The What: The team routinely extends the backlog item (i.e., User Story) Definition of Done to promote a higher quality
  • The How: It’s a good practice to revisit your definition of done at team retrospectives with the intent of modifying as needed. You can even have a mini retro on the definition of done itself. As your team matures and CI/CD, DevOps practices mature in and around your team, the DOD should be updated accordingly.

Source - What is Definition and How to Create it? (With Examples)

Optimizing

Teams “optimizing” the knowledge sharing of the Team Definition of Done practice learnings across the enterprise should focus on the following improvements

• The What: The team(s) working on a product have a Definition of Done for a Release

  • The How: If the “done” criteria for a PBI does not mean that it is yet releasable (i.e it’s not exactly the same) then it’s a good practice to include a release DOD. We encourage teams to try to get these as close to the same as possible but every context is different. For example, releasing a single story or update might be good enough for a PBI DOD but pushing a major release of multiple combined features might require another level in order for it to be considered “done” or “potentially releasable.” Its common organizations will have marketing, tech writing, etc involved in a release. Also, there may be more testing required for a major release than a small incremental release to production. This will be completely dependent on how your products are architected for release and if you can separate deployment from release by using techniques such as feature toggles.

  • Robert Galen discussing this in one of his excellent posts about the Definition of Done here.

*   *   *   *   *   *

"When a Product Backlog Item (PBI) meets the Definition of Done, an Increment is born."

*   *   *   *   *   *

Conclusion

In conclusion, the Definition of Done is a crucial practice for ensuring that the Increment meets the required quality measures for the product. The DoD creates transparency by providing everyone a shared understanding of the work completed as part of the Increment. To get started with this practice, teams should create a Definition of Done for PBIs completed in an iteration and ensure that all team members and stakeholders are aware of it and agree to follow it. Additionally, teams should enforce the Definition of Done 100% of the time, routinely extend it to promote higher quality, and have a common PBI Definition of Done for teams working on the same product. By doing so, teams can create and evolve common quality standards and promote team accountability. For a thorough assessment of your team's current process status, we offer a free agile assessment for Team Agility that you can take advantage of.