How to build a Scrum Product Backlog you can be proud of
According to the Scrum Guide, there are three artifacts that represent work or value to provide transparency and opportunities for inspection and adaptation. The Scrum Product Backlog is one of those artifacts and therefore an essential part of every Scrum Project. Consequently, you as a Product Owner should take your responsibility seriously when it comes to “owning” the Product Backlog. Here are a few ideas to consider when working with your Scrum Product Backlog.
Use your Product Backlog as a single source of truth
Your Product Backlog should be seen as a living document that is constantly changing and evolving. It should be flexible and always up to date. As a result, your Product Backlog might change several times a day, since you are constantly working on it. And that is totally fine. Avoid treating your Product Backlog as a fixed list of finalized requirements. It should not only include perfectly specified and aligned items, but also those fuzzy ideas you just scribbled down when you had a spark of inspiration. You do not want to have a “shadow list” of those ideas where you refine them. Instead, you want to have every idea transparent in your Product Backlog. No matter the maturity.
Do not delegate owning the Product Backlog
In many scrum teams, the Product Owner is a quite busy person that has to deal with a lot of topics. So, they look for opportunities to delegate tasks. Constantly updating and working with the Product Backlog then seems to be a task that can be delegated to another person. But, that is usually a bad idea. At all times you should have a good idea of what is where in the backlog. The Scrum Product Backlog is one of the most important artifacts to define product success. A delegation of this responsibility must raise the question if your team needs your assigned Product Owner in the first place or if the receiver of this task should become the Product Owner instead. Also, you add another step in the chain of communication. As a result, you are not only increasing your communication overhead, but also increase your risk for misunderstandings.
So when you as a Product Owner feel overwhelmed with your tasks, here is what I suggest you to do instead of delegating your ownership over the Product Backlog:
Keep your Product Backlog Items simple
In my experience Product Owners often are ambitious people with high motivation. That is great and exactly what is needed in this role! But sometimes they also tend to have a desire for perfectionism. However, perfectionism is not required in every Product Backlog Item.
The goal of this life [or product backlog] isn’t to be perfect, but to be progressively less stupid
Marshall Rosenberg
In some scrum teams, it is becoming an anti-pattern, that they try to use “the user story format” to define every single item on their list. Avoid being dogmatic about it. Although this format might be helpful, it is not essential for your product success. Instead, a shared understanding of requirements is essential. The user story format is just a tool to help you with that. So, relax and do not waste too much time in defining the perfect product backlog item. Also, use refinement sessions to add details to the story over time. Higher ordered items on the list are usually clearer and more detailed. Lower ordered items are allowed to be a bit fuzzy. Remember, your product backlog is constantly changing and evolving.
Use a one-dimensional list
Let’s face it: Requirements often are complex items with many dimensions that finally define their importance. You should always consider criteria such as risk, value, effort, urgency, etc. But, it is crucial that your consideration always results in a one-dimensional list of priorities. Two Product Backlog Items should never be in the same position on your priority list. Sometimes this might require tough decisions to be made. But those decisions are required to unleash the potential of your scrum team. So avoid the temptation to document your requirements in a 2-dimensional matrix or multi-dimensional table without consolidating them into a one-dimensional list.
Keep your Product Backlog clean
If you have been working with your product backlog for a while, chances are, that your list is getting messy. But, you might want your product backlog to be clear, relevant and useful. A neat backlog will have 20-30 Product Backlog Items, with more details in the higher ordered small items and less detail in lower ordered large items. In order to achieve that, you should do some “housekeeping”. So here is a step-by-step process how to clean up your Product Backlog on a regular basis:
- Remove every item you haven’t touched for x (I suggest 12) weeks. Chances are, that you will not work on this item any time soon. If it is still important, be faithful that it will come up again later.
- Re-consider if you still want to implement your optional “maybe later” requirements. If those requirements are waiting for implementation for quite a while, chances are, that you will never implement them.
- Check for items that became obsolete. Sometimes requirements just become irrelevant.
- Avoid too much detail in Product Backlog Items that will not be implemented in the next 2-3 Sprints. Adding too many details too early will result in many changes and therefore result in waste.
Also check out my article on The ugly truth about why you fail with your agile team to get more advice for your agile success!
Key Takeaways
- Use your Scrum Product Backlog as a single source of truth
- Do not delegate owning the Product Backlog
- Keep your Product Backlog Items simple
- Use a one-dimensional list
- Keep your Product Backlog clean
