Backlogs and Bugs…

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.

3 thoughts on “Backlogs and Bugs…

  1. Hello, great writing 🙂
    A question though, like you have mentioned in one of your post that we can have a separate backlog for technical debt items, how about maintaining a similar one for “Bugs” so the backlog does not gets confusing with loads of different stuff? PO needs to be aware of all of them off course.

    • Hi Avid Dreamer

      I believe bugs should be either part of the tech debt backlog or the PO’s backlog as opposed to having a completely separate ‘Bug Backlog’. Later on in this reply I’ll explain how this can work, but first of all, let’s look at WHEN a bug gets worked on. When we know WHEN to tackle a bug (i.e., in the current sprint or at a later date), we can then look to figure out WHICH backlog it is best suited to.

      If the bug has emerged a result of sprint work, then the scrum team tackle in accordance to what has been agreed between them and the PO in the Definition of Done (DoD). If the DoD states that ALL bugs must be completed in sprint, then it is handled in the sprint and therefore is not added to the backlog. Other lower priority stories may have to be descoped by the PO to accommodate additional work as a result of bugs on higher priority stories. However, if the DoD states for example, that only critical bugs are tackled in sprint, then anything deemed ‘non-critical’ is added to the backlog. The Scrum development team and the PO can decide together which backlog the bug fits with best, and if there is trust in the team this works perfectly. For example, a backend defect is arguably better placed in the tech backlog, whereas a cosmetic defect may sit better with the PO’s new feature backlog, because the PO is not technical (usually) and can understand the implications of front end issues or perhaps email notification issues etc. An experienced Scrum Team will start to self-organise and will just know which bugs should go where and why. The DoD is the guide when deciding which sort of bugs gets completed in sprint, and which do not. I say ‘guide’ becuase there may be times when a cosmetic bug may not be ‘critical’ in the eyes of the Scrum development team, but the PO deems it critical becuase he or she thinks it will drastically effect usability. As long as the team and the PO are communicating effectively, the right conversations can be had at the right time and in the right level of detail. Scrum aims to always ensure people talk at the right times, and also that the PO is available. If the PO is not available to answer queries from the team, on bugs or anything else for that matter, it quickly emerges that the team are not getting what they need, and therefore sprint goals become at risk and sprint goals start to be missed. Hope this helps! Amy

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s