Bugs, change requirements and the PO dilemma


In my last post I didn’t have room to explore other backlog issues, which become more important once it starts the implementation phase: bugs (or defects) and change requirements (or change requests – CR). Bugs must be included in the backlog, they will take capacity to be solved and they bring user dissatisfaction. In this post we will touch different questions: which type of bugs and CRs we can face, in which contexts we will face them, who normally will report them into the backlog and the product owner dilemma between occupy capacity with new feature or fixing bugs or improving/ adapting product details (CR).

Type of bugs and change requirements we can face

As mentioned before, in the post Requirements hierarchy, what should be written per level and by whom? I explored the theme of requirements levels in Agile, the transition between high level requirements (closer to the Strategy) and the most detailed levels (closer to Implementation). I also shared my opinion about who should take the lead, writing requirements in each of the different levels. Now I would like to approach two other different type of issues we can find in the backlog: bugs and change requirements (CR).

A Bug is a software output or behavior not correspondent to what was initially specified, a function that is not preformed or it is performed with variance for the initial specification (e.g. the output partially delivered, is delivered with defects, or is not at all delivered). A change requirement is an adaptation or change in the software behavior considering an initial specification.

A bug is normally classified by two criteria: severity and frequency. Severity means how much is it blocking the end-user to use the product as initially specified. Also can consider the feature importance for the end use (e.g. is it a product core feature? or just a secondary feature, not used so often?). Frequency means how often it happens.

A bug can be functional if the function is not performed or non-functional if the function is performed but non-functional product attributes are affected, like: security or performance, for instance. Often, functional bugs are triggered with user tests (e.g. manual tests, smoke tests or sanity tests), or automated tests (e.g. regression tests). Bugs in the non-functional product parameters demand for more complex testing methods (e.g. security tests, penetration tests).

A change requirement also can be functional or non-functional and this defines normally who identifies it and write it in the backlog. Please bear in mind that a change requirement makes part of the natural product life-cycle. What can be seen as inefficiency is if the change requirement comes in the middle of the release for a new requirement that is currently in implementation for the first time.

The product owner dilemma between occupy capacity with new feature or fixing bugs or improving/ adapting product details (CR)

Bugs and CRs are often coming into the backlog after the capacity for the sprint or for the release have been completely reached and agreed. And this is a big mistake. Before agree in the release scope we must consider how much we want to invest in product quality and improvement versus new features.

This competition for team capacity must be solved in between the team with the Product Owner. For support this negotiation I recommend you to read: Get ready for a Release plan negotiation!

3 Replies to “Bugs, change requirements and the PO dilemma”

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.