In Scrum, it is the expectation that the Product Owner makes the Product Backlog transparent. Making the Product Backlog transparent doesn’t just mean making it visible; it means making it easy to understand, to convey meaning, and to have it illustrate the ‘why’ behind the Product Owner’s decisions. Introducing levels of decomposition is an optional practice that can be applied when a situation calls for it.
Creating transparency in the Product Backlog is an ongoing journey with no single, prescriptive way that fits every situation. One of the major challenges in managing a Product Backlog is that there are often Product Backlog Items (PBIs) that vary in how much detail each holds. More vague PBIs tend to, over time, be decomposed into multiple other PBIs.
Image 1.0 illustrates the varying amount of sizes that may exist in the Product Backlog. The different sizes of the blocks represent the amount of vagueness a PBI may have. The smaller the block the more we might know about it. The larger the block, the more likely it is to turn into smaller blocks as the Scrum Team refines it.
(Image 1.0 - the varying amount of sizes of PBIs exist on a Product Backlog)
Although PBIs may contain some kind of estimate, we don’t know the true effort it takes to complete them until the work is done. This further complicates creating Product Backlog transparency because we cannot predict, with accuracy, how long it may take to complete a PBI even if we attempt to add details over time.
So what is a way that you can create some transparency about the vagueness of PBIs and their decomposition over time? One option is to introduce different levels of decomposition within the Product Backlog.
Levels of decomposition mean that you have designated naming conventions to convey the amount of vagueness a PBI might have. Image 1.1 illustrates three different levels of decomposition: Epic, Feature, and PBI.
(Image 1.1 - one example of leveraging three different levels of decomposition)
An important note about image 1.1 is that the terms Epic and Feature are used to convey the level of vagueness. The terms Epic and Feature convey vagueness but they should still be considered PBIs. Epic means a really big PBI which may consist of many Features. Those Features may consist of many PBIs. All PBIs and their details will emerge over time.
You may vary these terms and/or levels of decomposition to fit your context. As an example, image 1.2 shows two levels of decomposition; Epic and PBI.
(Image 1.2 - an example that illustrates two different levels of decomposition)
There are many options you can use to convey different levels of vagueness. However, there are some cautions that you should be cognizant of. Adding levels of decomposition is no guarantee that additional transparency will be created. In fact, the opposite could be true.
I have seen many Product Backlogs over-complicated because there are too many levels of decomposition. A rule of thumb that I often use is that simplicity creates transparency. I cannot tell you exactly what you should do in your situation. I encourage you to experiment and then validate whether implementing a tactic such as levels of decomposition has made your Product Backlog clearer.
Last, remember that everything on your Product Backlog is a hypothesis of value. Strive for the minimally sufficient Product Backlog that your Scrum Team needs to get the job done.
Learn more about me by checking out my profile: https://www.scrum.org/todd-miller