Tips for Product Backlog Management

Product Backlog Management

A

s 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 article, we’ll cover tips about Product Backlog Management.

Tips for Product Owners:

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 more than half 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.

Only 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 past articles about product 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, there is no need to 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…

Share some tasks to the Team

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 Engineering Team support you in managing the Product Backlog! So let them help you! As a Product Owner, you don’t want to describe all the User Stories, acceptance criteria, functional designs, etc. yourself. But, maybe you want to act more as an entrepreneurial Product Owner, therefore more focussing on the vision, the long-term roadmap, the stakeholders, market and business value. So, why not share some of the tasks with them!

Not everything is a User Story

We all know the ‘User Story’ 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.

Know your Product Backlog

What I see many times in practice, is that Product Owners 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, and worked really well, 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. 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.

Reorder 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. 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 keep ordering and reordering the Product Backlog continuously!

 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 (Value). 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!

Keep 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. For me, 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!

Everyone must see it

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 or board! 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.

There is more than customer or business value

The final tip for today 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? Hopefully 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!

These are the useful tips for Product Owners on the topic of Product Backlog Management! I hope you learned a few things and enjoyed them.