When Product Backlog Is a Mess

I work with a lot of companies that are learning to use Scrum as a tool to drive agility. Recently, I spotted a trend: if a Scrum team cannot articulate their Sprint Goal, the problem quite often lies with the Product Backlog. As a rule, it looks a lot like my favorite mixed salad (or, frankly speaking, a mess). It's not easy to make sense out of this mixture.

Over time, individual cases have formed a pattern, and I realized that the Sprint Goal is one of the indicators of the Product Backlog's health, because it is the Sprint Goal that puts a common idea behind the various Product Backlog items and creates the foundation for teamwork. The Product Backlog, in turn, ultimately defines the success of the product and serves as a master plan for the Scrum Team.

Let's see how to check whether your Backlog is a mess and, what to do if it is.

Signs That Your Product Backlog Is a Mess

I have identified four markers that help evaluate the quality of your Product Backlog.

They are:

• The Backlog isn’t clear for anyone outside the Scrum team.
• The Backlog looks like a bunch of random things thrown together.
• You cannot see the product development strategy behind the Product Backlog items.
• There is a lot of technical terminology.

If at least two of these apply, oops! Your Backlog is a salad. Don't worry, I know how to fix this.

What Do I Do With a Messy (Salad-Like) Product? Backlog?

From my experience, most issues with a Product Backlog can be solved by leveling up the Product Owner, enhancing the Product work (and Product definition), and reviewing the rules of Backlog processing. Here are some activities that can help:

Level Up the Product Owner

Give him/her the real power. Make sure that the person called the Product Owner actually OWNS the product. A real Product Owner aims to optimize the product's business value for the whole company. A Product Owner acts as a mini-CEO of the product and as an entrepreneur. Not everyone needs to be happy with the Product Owner's decisions, but everyone should respect them and comply with them.

Use business metrics. Make sure that the Product Owner is responsible for business metrics, such as the Return On Investment (ROI), the Cost Benefit Ratio, Profits and Losses (P&L), etc. If the scope of work is fixed and rigid, there will be no stimulus to optimize business value and prioritize the Product Backlog. Moreover, in this case, the Product Owner likely won't be interested in looking for business value. He/she will only focus on managing the triple constraint (Time, Scope, and Cost).

Help establish cooperation with the stakeholders. Some Product Owners, like the fox from the old Nintendo game “Egg,” are always in a hurry to collect the requirements (eggs) that fall on them from different departments (hen houses). Help the Product Owner identify stakeholders and develop a clear and concise strategy for interacting with them.

Help create the product roadmap and set business goals for the next quarter(s). Make your goals measurable (SMART) and pick several criteria that you'll use for evaluating each item of the Product Backlog. Obtain support and approval from the stakeholders. This way, the next time Mr. Smith comes to the Product Owner asking them to include an important feature into the Backlog, he/she can say, 'Mr. Smith, we agreed that we should reduce operational costs during this quarter. How does your idea fit into that?'

Enhance Your Work With the Product

Use Feature Teams. Scrum teams are often organized around business processes and/or architectural components. Usually, these teams are named something like the Front-End System Team, the Back-End System Team, the Core System Team, or the Platform Team.

A real product is something that brings business value to the end customer. Try to organize work around Feature Teams that have an end-to-end focus on the client so that you can use the advantages of Scrum to their fullest.

Create a product vision. A lack of a common vision between the development team, the Product Owner, and the stakeholders can be a reason why your Product Backlog is a mess. Create a common vision to help the stakeholders evaluate their ideas and fill the Backlog only with the things that really matter.

Stop sidetracking the team with other products/projects. A development team will lose focus when working on several products/projects at once. Switching between different contexts is exhausting, and the work becomes a tiresome marathon run. Make everything possible for the development team to focus on a single product or service at a time.

Enhance Your Product Backlog

Connect features to your business goals. Use Impact Mapping to connect your business goals to the features in the Product Backlog. I believe that this is one of the most powerful product techniques that help you make sure you aren't doing something meaningless.

Assign the four attributes to each PBI. Make sure that each Product Backlog Item (PBI) has four mandatory attributes: the order, the business value, the estimate, and the description. This will help the Product Owner to order the Product Backlog. It will be easier for him/her to calculate ROI for each item and sort the items accordingly.

Have a clear feature description. A good Product Backlog should be simple and easy for the user to understand. If the users have a hard time while deciphering the obscure terms and phrases, you need to review the descriptions and move the focus of the development team to what really matters.

Summing Up

A Product Backlog is a powerful artifact that serves as a master plan for the Scrum team. You cannot move on unless you treat it seriously. Can you easily articulate your Sprint Goal? If not, your Backlog may be prone to messiness and is blocking you from delivering value.

I hope you found my article useful. Now, what's your Product Backlog like? What do you do if it becomes a mess? Is it easy for you to articulate your Sprint Goal? I'll be waiting for your comments.

Scrum ON!