Product Backlog Management
As a Product Owner, you are responsible for Product Backlog Management, in order to maximize the value of the Product. The Product Backlog is the single source of truth which contains all the work to be done on the Product. As a Product Owner, you will have to make some choices about what to build first and what to build later. But also what to build and what not to build!
In this post, we'll cover 10 tips about Product Backlog Management. In the blogs to follow, we'll also cover tips on the other aspects of Product Ownership. I hope you enjoy them!
10 Tips for Product Owners on Product Backlog Management:
1. Keep the Product Backlog manageable
A mistake we see many Product Owners making, is that their Product Backlogs are way too exhaustive. The worst Product Backlog I've ever encountered contained about 650 Product Backlog Items. This was hell! It was unmaintainable, it was impossible to manage, it was impossible to create transparency and nobody knew where the Product was heading towards. Typically, everyone understands that a Product Backlog of 650 items is unmanageable and this may have been exceptional. But what isn't so exceptional is that I meet a lot of Product Owners, who typically have 100 to 300 items on their Product Backlogs. Out of 10 Product Owners, I would say that five to eight of them have a Product Backlog containing more than 100 items. As a Product Owner, you will have to make choices! You will have to decide what not to do. Your job is to maximize outcome, by minimizing output. You'll have to say 'no'.
2. Stick to one Product Backlog
Saying 'no' to people is hard, it's difficult, because we're often afraid of disappointing people. Saying 'no' also feels permanent, definitive. But as discussed in this blog about value, value may change over time, so something you say no to today, may be something you want to do a few months from today. So, to not forget about these items, we see a lot of Product Owners adding these kinds of items to a 'separate backlog'. This 'separate backlog' operates as a container for all ideas, so that we won't forget about them. The truth however, is that if something is actually valuable, and people are waiting for it to be delivered, then it will come up again later on. So, if you say no to something today and it's really valuable, it will come up again a couple of days, weeks or months from now anyway. So, don't keep a separate list! Order, maintain and own one Product Backlog! If you don't want something on that single source of truth Product Backlog, then just say no! The side-effect of saying 'I'll put it on the other list' is that the ownership of the item is transferred from the stakeholder to you as a Product Owner. It also means that the stakeholder will be expecting you to do something with the item. What I often see happening in these situations, is that stakeholders will eventually start complaining that they never get what they asked for... That everything 'disappears' in the list, but you'll never hear about it again. And eventually, they will be disappointed. So it's much better to be clear and say no right away, rather then to let it die slowly (and trust and openness with it).
3. You don't have to do it all yourself
Since the Product Owner is responsible for Product Backlog management, many Product Owners want to do all Product Backlog management activities themselves. This isn't necessarily a bad thing. However, you are allowed to let your Development Team support you in managing the Product Backlog! So let them help you! As a Product Owner, you way want to describe all the User Stories, acceptance criteria, functional designs, etc, etc. yourself... But, maybe you want to act more as an entrepreneurial Product Owner, therefore more focussing on the vision, the long(er) term roadmap, the stakeholders, market and business value. So, don't try to do it all by yourself!
4. Not everything has to be a User Story
Willem, a colleague of mine, always had a nice way of putting it, which was: "All German Shepherds are dogs, but not all dogs are German Shepherds". This also illustrates how you should see 'User Stories'. A 'User Story' is a format:
As a <role>,
I want <functionality/what>,
So that <business value/why>.
A User Story is a template which can be used to describe Product Backlog Items. In Scrum, all items on the Product Backlog are called 'Product Backlog Items'. Some of these Product Backlog Items may written as 'User Stories', but others don't. For bugs or technical debt for example, it often has little or no value to describe such an item as a User Story.
5. Know what is on your Product Backlog
This tip may feel a bit of an open door. What I see many Product Owners do in practice however, is that they let pretty much everyone add items to the Product Backlog, resulting in an exhaustive, unmanageable list of wishes. What I used to do as a Product Owner, which worked really well for me, was that I was fully in control over the Product Backlog. I didn't have to know all the details of every single item on the Product Backlog, but I did know what items were on it. And I also knew what items I rejected, which ones I didn't want to do. Of course it is up to you to decide how you want to manage your Product Backlog, but letting everyone add stuff to the Product Backlog often results in reduced transparency, lack of clarity, a wrong ordering and loss of manageability.
6. Reorder the Product Backlog continuously
The Product Backlog is a living artifact. It's something that evolves, changes, grows and shrinks over time. Therefore, you need to reorder the Product Backlog continuously! The ordering of the Product Backlog may change from week to week, so make sure you keep the Product Backlog up-to-date. As a Product Owner, you should make the Product Backlog transparent for all the stakeholders and the Scrum Team (also see tip 9). This transparency on the Product Backlog is valuable if and when the Product Backlog is up-to-date. Besides having a transparent and ordered Product Backlog for the stakeholders, you'll want to have a transparent and ordered Product Backlog for the Development Team. Every Sprint starts with the Sprint Planning and in that meeting you'll need to have an ordered Product Backlog so that the Development Team can create an actionable plan for the Sprint. Before that Sprint Planning, you'll probably get some feedback from people during the Sprint Review and you'll get some actionable improvement actions out of the Sprint Retrospective... So as you see, you'll have to keep ordering and reordering the Product Backlog continuously!
7. The Product Backlog shouldn't be complete
A pitfall that a lot of starting Product Owners step into is that they want to create a complete Product Backlog at the start of a new project, especially when they come from more traditional or project oriented environments. They're used to defining the scope of the project or the team upfront, with all the requirements needed for the project. However, Scrum and Product Ownership aren't focussed on delivering projects. They're focussed around products. Product Development is something that never ends, as long as the Product lives, and so, the list of demands, requirements, wishes and more will keep growing and shrinking over time, as long as the Product lives. So don't try to create something like a 'complete' Product Backlog. Create a Product Backlog with the most valuable ideas for the Product and start from there! It will change over time anyway, so don't try to get it perfect at the start, when you actually know the least!
8. Focus on 'what' and 'why'
Another pitfall for a lot of Product Owners is that they are focussed too much on finding and describing 'solutions'. There are many Product Owners out there that are doing a lot of business analysis, technical analysis and who are creating (functional) designs and descriptions for the Development Team. Although it's not fundamentally wrong, I have always experienced that nine people have more creative and problem solving power than one person alone. So what I always recommend is that a Product Owner shouldn't be concerned with the (functional/technical) solution. A Product Owner shouldn't have to 'design' a feature. A Product Owner should be concerned with the problem he or she wants to solve, or the opportunity he or she wants to grasp. So, a Product Owner should mainly be focussed on the 'what' and 'why'. A Product Owner shouldn't be concerned so much with the 'how'. So, use the creative and problem solving power of the team to design the solution!
9. Put it on the wall
As mentioned earlier, the Product Backlog should be transparent for stakeholders and the Development Team. There are many ways of creating more transparency, but one of the most powerful ones is to literally put the Product Backlog on the wall! Of course you have to take all kinds of things into account (like a distributed setting or access restrictions), but what typically works great to increase transparency, is to put stuff somewhere on the wall, close to the team, so that when people walk by, they can actually see what the team is working on now, and what they will be working on in the near future.
10. There is more than customer or business value
The final tip for now is that there is more than business or customer value that you need to consider. Of course you want to deliver as much value for customers, users and the organization as possible, but should it be at all costs? I hope not! What we've seen a lot of Product Owners do, is that they are fully focussed on delivering as much features as possible. But, as a Product Owner, you are not responsible for delivering more features! You are responsible for maximizing value for customers and users! To put it otherwise: You are responsible for the success of the Product. This doesn't only included deciding on new features or functionalities in the Product. It also means that you should consider resolving bugs, technical debt, improving the Products' architecture, improving performance and security. It also means you should spend time on test-automation and the deployment/delivery process. If you spend time on automating manual testing and/or manual deployments, you will eventually be able to deliver more value, with higher quality in a shorter period of time!
So, these are the 10 tips for Product Owners on the topic of Product Backlog Management! I hope you enjoyed them and that they'll help you in becoming a better Product Owner!
Also check out these other tips for Product Owners!
Holy Guacamoly! Are there even more tips for Product Owners? Yes there are! We've described 60 more tips for Product Owners, to help you to become better in your role! We've defined 7 aspects of Product Ownership on which we have interesting tips to share with you, so check them out: