One way to eliminate defects in agile development is to groom the product and defect backlogs to refine, reprioritize and improve the lists. Grooming is typically performed at a workshop held separately from the sprint planning session. During the meeting, the Product Owner and the rest of team review the backlogs to ensure that they are current, relevant and contains the appropriate items. They also ensure that the items in the backlog are properly prioritized with those on the top of backlog being included in the next release. This meeting occurs on a regular basis, i.e., every two to three weeks. Some of the activities that occur at this meeting include:
- Refining, reprioritizing and improving user stories especially those related to test criteria.
- Refining, reprioritizing and improving refactors that are also included in the backlog.
- Splitting user stories for the next iteration when they are too coarse grain to be effective.
- Adding new user stories (including non-functional ones), then prioritizing and estimating them.
- Refining time and personnel estimates for backlog items using feedback from completed sprints.
- Removing user stories from the backlog when they are no longer relevant.
For the defect backlog:
- Refining and reprioritizing defects in the backlog.
- Removing defects from the backlog that are no longer relevant.
Normally, backlog grooming sessions are held right after the start of a sprint. Everyone on the team participates as they view the activity as a shared responsibility. The meeting starts with a demonstration of the prior sprint’s deliverables. This keeps the conversation flowing because it focuses the team on the capabilities of the release and filling the gaps identified by the backlogs. The PO, not the Scrum Master, runs the meeting because he/she makes the decisions relative to the release’s contents and priorities.
The quality benefits of backlog grooming are many. Most important is that the contents of both the product and defect backlogs when used for sprint planning are current, detailed, relevant and estimated. This reduces the number of defects that occur when items being addressed are no longer relevant or low priority.
This blog is taken from Chapter 13 of my new book entitled “Agile Software Quality: One Team, One Approach, Build Quality In” which will be available next year.