Use Defect Thresholds to Help Product Quality
Most scrum teams have backlogs that contain more than just user stories and new product features. Oftentimes, they contain bugs and defects that have been reported by customers or users or even by the team itself. These aren’t always handled right away.
This isn’t necessarily a bad thing, as perhaps none of these bugs or defects are considered high priority or need fixing immediately. However, once there are a large amount of these in the backlog it can make your product seem sloppy or bug-ridden – no single bug may be a priority, but collectively the probably should be.
Placing a maximum threshold on the number of bugs or defects that a backlog can contain before triggering them being prioritized for the next sprint. This sets a minimum quality standard, and gives a consistent approach to handling issues that come up with the product.
You could apply the same principle to larger programs that contain multiple backlogs.
Let’s say you set the threshold to five, or eight items. Once that threshold has been reached collectively across all backlogs, this sends a signal to teams that they have to prioritize handling those defects for the next sprint. With this process in place, teams will never see a proliferation of defects and you always make sure you have a quality and stable product.
I hope that Agile Quicktip was valuable for you and your teams. Let me know what number of items you choose for your own defect threshold in the comments and also how it works for you. Don’t forget to check out the rest of the series, and make sure to stop by Thinklouder.com where you can learn more about how our training and coaching offerings can help you and your team.