Who ‘owns’ the bugs? Should bugs be included in the backlog? Who decides when bugs should be fixed? How do we decide when a bug should be fixed in sprint?
These are questions I have answered many times, so I thought I’d blog about it!
I believe the PO should own the entire backlog. A product backlog contains Product Backlog Items (PBI’s). An ‘Item’ being deliberately nondescript as a Product Backlog does not just contain user stories, it contains all the defects and tasks that the PO knows need to be included in a sprint at some point for the development team to work on. Agile champions One Backlog. One ‘forced-rank’ list of prioritised PBI’s. The latter meaning, no two items can carry the same prioritisation. Something must preside over another, and there is always something, no matter how minor, to determine this. Bugs need to be included in the PB so they can be prioritised. It may be that in one particular sprint, a few outstanding defects are actually of a higher priority than developing new functionality.
The PO should know their backlog and their product like the back of their hand. If visibility of the defects are taken out of their backlog and recorded elsewhere instead, the risk is that the PO may lose sight of work that needs doing and also the impact of a bug on the product may be pacified or forgotten. Although the dev team are undoubtedly knowledgeable, they are unlikely to know as much as the PO what the impact of not amending, for example, a cosmetic/UI bug is, because it is the PO who liaises frequently with the customer and understands their pain points. Something irrelevant to developers may actually be a big deal to the customer. It is my belief that the PO alone decides what goes into a sprint (based on their backlog prioritisation) unless the team express a technical dependency which will force the stack rank to be changed (stack rank is terminology from Kanban referring to prioritisation).
The tolerance levels to bugs in a sprint is a decision for the teams to make with the product owner, and there are discussion points to consider for every product as a unique entity, and there are reasons for this. There are obviously standards which are never compromised on, such as no bug that is deemed ‘critical’ should be allowed to be released, but how bugs are categorised is a team decision based on what they believe is acceptable, and the PO needs to have a say in this (but must also be mindful to be realistic).
Tolerance levels outside of critical bugs need to me decided and agreed accordingly and will become part of the dev team’s Definition of Done’. So they need to confirm and document “What is the criteria for a critical bug?”, “What is the criteria for a non-critical bug that should be fixed in sprint?” . I have not mentioned how to classify a bug not to be fixed in sprint because they should automatically be added to the Backlog by the PO.
The reason I say that all projects need bug tolerances to be decided on a project by project basis is because different customers have different levels of tolerance themselves. For some customers’ products, the PO may not deem cosmetic/UI bugs to be as critical as code bugs and so the tolerance level is lowered on cosmetic/UI bugs. Alternatively, what if the product you are building is aimed at an audience with impaired sight or learning difficulties? Perhaps with the development of these features, cosmetic/UI bugs are deemed of equal importance in all cases and so demand to be completed in the sprint in order for the story to be ‘done’. There may also be bugs that although have been agreed as not necessary to complete in sprint and therefore not a requirement in order for the team to meet the ‘Definition of Done’, the PO may know it is an exception and so asks the team to fix it in sprint. The PO must appreciate that this may mean removing another PBI (note I say PBI and not story, as a PBI is an ITEM that can be a task or a bug also) from the sprint in order for the team to accommodate.