So far I have discussed, basic Scrum theory and the Scrum roles in my previous posts. Moving forward, in the next three posts (including this), lets explore the next three essentials of Scrum i.e. the three artefacts. Let’s start in order, with Product Backlog.
Product Backlog
As Scrum guide describes,
The Product Backlog is an ordered list of everything that is needed in the product.
The product backlog is a living artefact. It evolves as more is known about the product, the domain it operates in and the customers or end-users of the product. It is never complete and exists as long as the product exists.
The Product Backlog raises transparency for everyone who is involved with the product. At any given point in time the work remaining can be summed and can be used to assess the progress towards the completion of the product.
For a product there is only and only one Product Backlog. Even in the case of multiple teams working on the same product; the Product Backlog is only one. This is the single source of truth for the scrum team. The development team does not work on anything outside of the product backlog. The Product Backlog consists of all features, functions, requirements, enhancements, bugs, defects and fixes that constitute the changes to be made to the product. Even any of the non-functional requirements that are needed for the product go to the product backlog.
It is owned and ordered by the Product Owner. New items can be added or existing items updated on the Product Backlog at any time by the Product Owner or at PO’s discretion. The PBIs ordered towards the top are more granular, have more clarity and are better understood by everyone; as compared the PBIs that are towards the bottom. More often it is the Product Owners responsibility to keep the higher ordered PBIs detailed appropriately. The Product Owner is also responsible for helping the development team understand the PBIs.
Some additional stuff to ponder:
The Product Backlog is an “ordered” list not “prioritized”. Let us explore this aspect. Earlier to the 2011 version of Scrum guide, it was essentially a “prioritized” list but later on it was made “ordered” list. Is there really a difference? Yes, there is. Priority, means treating one thing more important than other. It is subjective, what seems more important to me, may not be important to others. Ordering on the other hand is more of a sequence of doing things. And no matter whoever is involved, the order would remain the same.
Consider an analogy of tumor operation, for the patient the priority is to get rid of tumor; get healthy. For the doctor the priority might be to give the patient anesthesia so that the patient doesn’t feel the pain. However, for both of them the “order” or sequence of performing the operation remains same i.e.
- Give anesthesia to patient.
- Cut open the part with tumor.
- Remove the tumor.
- Stitch back the open cut.
- Keep patient in observation.
- Discharge healthy patient.
Priority of a PBI can be one of the ways to “Order” the product backlog, other ways may include- risk associated with the item, development cohesion, cost of delay etc.
Why is it a backlog and not a queue? Well, the answer is much simpler. A queue is always “First In First Out” i.e. the item which is added first should be done first. However, this is not true for a backlog; and also not same for a product. The PBI which PO/Stakeholders/team added to the backlog thinking that it adds value to the product may not be valuable anymore or may add value at a later point in time. Thus, the order of the item needs to be changed as per current needs of the business. Had it been a queue, there would be a constraint on changing the order of PBIs. Hence, it is a Backlog and not a queue.
