The Scrum Guide is rather vague about how Product Backlog Items should be structured and how to make them transparent. That is by design because Scrum is intentionally incomplete. Understanding what attributes you are dealing with is helpful in creating a well-structured Product Backlog. Here is an excerpt from the Scrum guide under the Product Backlog section that highlights my point:
Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.
Specifically, let’s zero in on this statement:
… to add details, such as a description, order, and size. Attributes often vary with the domain of work.
Given that attributes often vary by the domain of work there is no single, best way to structure a Product Backlog Item. To further complicate this, even in your domain of work there may be different types of work items that call for different attributes.
For example, in the software development domain, these might be attributes that we want for work item types related to a new feature request:
- Title
- Description
- Size
- Target Customer Segment
Now, in the software development domain, look at the attributes that you might want for a defect:
- Title
- Description
- Reporter
- Reproduction Steps
The problem that this poses is that each work item type has subtly differing attributes which can, and often does, over complicate the Product Backlog. Overcomplicating the Product Backlog tends to reduce it’s transparency. Tools are especially susceptible to this as they are highly configurable so we, as humans, feel the desire to configure them to the fullest extent. We want to get our money’s worth!
What can you do about this problem? Here are three ideas:
- Identify Work Item Types - Spend some time identifying the different types of work items you come across in your work. A few examples of different types of work could be a new request, a problem, or an enhancement. As the Scrum guide says “Attributes often vary with the domain of work”. So will your work item types. Once these are identified make it transparent on your Product Backlog what type of work a PBI is. It can be as simple as color-coding Product Backlog Items by their work item type.
- Find Common Attributes - Find the common attributes you can use across the different work item types. Challenge whether you really need any additional attributes. Limiting the amount of attributes Product Backlog Items have keeps the Product Backlog simple. Simplification creates transparency
- Avoid Mandatory Fields - I cannot tell you how often I have come across complex Product Backlog management software where it takes so long to create a Product Backlog Item that teams often avoid doing so. I have even seen teams have different Product Backlogs because of this, a big no-no. Trust your teams to have the appropriate level of detail in the Product Backlog. Encourage leveraging Product Backlog refinement to add those details over time.
Every domain or work is unique and has unique work item types. Additionally, every Product Backlog Item will be unique in its own right. Be comfortable with that and let the Product Backlog (and the items within it) emerge as the work is performed. Simplicity leads to transparency. Keep it simple.
Learn more about me by checking out my profile: https://www.scrum.org/todd-miller