Product Owner Backlog Blues

How to work through common product owner scenarios that can cause an unhealthy product backlog

Backlogs are the backbone of development but it can be difficult to keep them healthy, especially when teams believe many problems are out of their control. A team might not be able to fix everything themselves, but they have much more influence over the situation than they believe.

Before we continue, let’s just go over the characteristics of a healthy backlog.

  • Has less than 100 items (for a team of 5–9)
  • The items are less than 9 month old
  • There are 1–2 months of work ready to go for the team to work on
  • Includes tech debt, bugs, and new feature work

If some simple tips to manage your backlog as found in my article, Tips for a Healthy Backlog in 2018 won’t do the trick, maybe you have a deeper issue. Let’s go over three common scenarios with product owners that can cause issues with maintaining a team’s backlog.

  • Product owner doesn’t have a strong vision
  • There’t not a product owner
  • Too many product owners

Product owner doesn’t have a strong vision

This can lead to a backlog with too much on it because the product owner is constantly changing their vision or a backlog that is sparse because the future of the product is uncertain, causing the team to hold on week by week.

Ask the product owner to work on the vision with the team.

It’s a big task, but by working together the entire team can come to a shared understanding that will improve future work. From there, I would have the product owner talk about the biggest problem they would like to tackle, not feature they would like to build, but problem they would like to solve for the customer and bring the team in early on this to think of solutions. The product owner can then determine, based on business decisions, which is the best decision and work with the team to build the backlog or focus the backlog.

There‘s not a product owner

This is a tricky one, but you can work through this. Usually, this is only for a short period of time due to restructuring, individuals moving on, or because the team is an internal team that supports a platform.

The team should be working on ensuring tech debt is on the backlog and ready to go. For feature improvements the team can work on items that have been on the backlog and have been previously validated. Without product management and a method to validate and determine what features should be added or modified then the team should most likely not continue with any “new” business feature work.

If the team is internal and supports a platform or product then someone should be designated to take on the responsibility of the product owner. This person can help narrow down what the next problems are that the team should tackle by reaching out to internal users for feedback and working with the team to validate future items for the backlog.

Too many product owners

This can often happen with internal tools or platforms that many departments of the organization consume. This situation in particular can be very stressful on the team. It usually leads to having too many items on the backlog from too many stakeholders. This causes the team to still be reactive because they are rushing around to find stakeholders for more information.

Standards are the most important in this scenario. First off, the team and everyone submitting work should have the shared understanding of what it means for work to be ready for development. Once you have this you are slowly making progress. Below is a standard definition of ready that I have used with teams before, which can be modified to suit your needs.

Definition of Ready

  • Stories are well written and clearly understood by the whole team
  • Acceptance criteria
  • Small, vertical stories
  • Estimated
  • Technical & design direction
  • Dependencies resolved
  • No impediments to beginning implementation

Once you have standards in place you can work with the stakeholders to determine one representative to be the representative to the development team. This would allow for all the stakeholders to determine their prioritization between each other and give just one point person for the team to work with. It simplifies the process for the team and gives more structure for the stakeholders to operate in.

If one stakeholder is never going to happen you can get the stakeholders together and talk about ways to prioritize across everyone. Whatever plan you come to might not please everyone but at least it gives everyone an opportunity to provide input.

A few ideas to work with this situation are:

  • Allot stories/hours each sprint or week to a stakeholder. Help them break up stories if smaller intervals are needed. Let them decide what is most important, if something more important comes up, explain to them how it affects the backlog and their current work on the backlog will get pushed to a later sprint.
  • Have all the stakeholders get together to assign a business value of 0–100 to the stories on the backlog, and a number cannot be used more than once. This keeps everything from being 100 or 90 and allows all the stakeholders to see the backlog based on business value rather than just work important to them.

Maintaining a healthy backlog can be difficult in and of itself, when you are presented with certain situations that only make it more daunting for the team, you just need to take a step back and try to improve some small aspects. It may take time before you get to your ideal backlog but realize you and your team do have the power to improve your situation, it just takes a little determination, and possibly taking your team and product owner out for a drink.

If you have any thoughts, comments, or ideas for working with product owners and backlogs, please share them below.