Scrum Rules: Your Product Owner Puts Known Defects at the Top of the Product Backlog

The Product Owner has complete authority over the ordering of the Product Backlog. However, it is strongly recommended that the Product Owner put all known defects at the top of the Product Backlog so that the Team fixes them in the very next Sprint.

Defects are features or functions of the system that have been built by the Team in previous Sprints where those features or functions do not behave according to the expectations of the Product Owner and where such misbehavior is exposed to users of the system. There may be other quality problems with a system which are not categorized as defects (e.g. duplicated code). This prioritization of defects generally results in extremely high levels of quality in a system and a long-term reduction in costs for the system (total cost of the system) by making future features easier to add, and reducing effort spent on maintenance and support. Failing to put defects on the top of the Product Backlog generally leads to decreasing overall quality and in particular can severely damage the morale of a Scrum Team thus preventing them from getting into a high-performance state.

In simple terms, the Product Owner should be considering three sources for defects that may then be put at the top of the Product Backlog. The first source is defects discovered during Sprint Review, the second source is those discovered by users of the software as they are doing their real work, and the third source is any defect database which has historical records of the system prior to the current Sprint. It is generally easy to put defects from the first and second sources onto the top of the Backlog. However, the third source, a database, may be harder to handle this way. There are two ways to address this: delete the database or deal with it by taking a small number of defects from this source and fixing them every Sprint. Deleting the database is often a good idea if there are a very large number of defects and they include defects that may have been logged years ago.

One very simple practice which many teams use to help keep defect rates low is to have a defect board in the team room which the team agrees to clear (resolve all defects) before the end of the Sprint. Any time any Team Member notices a defect, it gets put on the board and as defects are fixed by the team they are taken off the board. Defects on the board should not be tracked in a formal defect tracking system since the team is still “in development” during the Sprint. Of course, detecting defects during the Sprint means that the team should include Quality Assurance skills! The practice of putting defects on the top of the Product Backlog is not usually sustainable unless the Scrum Team adopts Acceptance Test-Driven Development (ATDD) and Continuous Integration (CI) (both Agile engineering practices) both of which help to improve external, user-visible quality during the Sprint. ATDD helps to prevent defects and CI helps a team to detect defects extremely quickly so that they can be fixed within the Sprint. These two practices then result in a dramatically reduced number of defects being detected during Sprint Review or after the Sprint has completed, which in turn makes it much more reasonable to follow this practice.

Certified ScrumMaster® – Guaranteed to Run! ✅

Certified Scrum Product Owner® – Guaranteed to Run! ✅

All virtual learning events run from 9am to 4:30pm Toronto/New York time and are 100% virtual.  Both CSM and CSPO courses have approximately 2 hours of required pre-work through our e-learning portal, and require you to have high speed internet for Zoom video conferencing and Miro virtual white-boarding.

Maybe attending a virtual training session isn’t for you, but you would like to acknowledge that this article helped you out somehow…