5 rules to master product backlog management

A product backlog is a list of items that need to be completed to develop a product. In agile and Scrum, it acts as a compass that points in the direction towards the desired destination. When managed appropriately, the product backlog can be the product owner’s most powerful tool when it comes to focusing the team’s effort on the right tasks and promoting transparency and collaboration.

In this article, you will find five tactics that any product owner can apply to master product backlog management.

1. Perfect is the enemy of good and the bullseye metaphor

A product backlog is a live entity. By definition, things that are meant to change are not meant to be perfect.

In agile environments, there are multiple streams of feedback that make us change what we plan to build and how we plan to do it. Work items are likely to change or evolve before development starts. For that reason, it’s OK if not all the information contained in the backlog is final. It’s better if it isn’t. For efficiency purposes, if an item is likely to change drastically, it makes very little sense to spend a lot of time and effort documenting every single detail. It is more efficient to document a general understanding of the work item. As more information becomes available, it can be expanded and improved upon.

You can visualize the refinement process in the form of a bullseye. The outer part of the bullseye represents work items that have been identified, but for which information is limited. The definition of these items is vague and development work for these items isn’t expected to begin anytime soon. Conversely, items on the inner part of the bullseye are defined in detail and are widely agreed upon. These items are not likely to change drastically, they are ready for selection in a Sprint planning, and the development team could start working on them any minute.

2. Be user-centric, not user-obsessed

Agile methodologies have been strong promoters of customer-centricity. With user stories at the core of agile argot, it is easy for product owners to become obsessed with turning every single work item into a user story.

User and customer-centricity are mindsets that — like Scrum — are easy to understand but hard to apply. Sometimes, we create Frankensteins by square-pegging every work item into a user story format. If you find yourself writing something like “As a user, I want a checkbox that allows me to accept the privacy policy so that I can make sure to read it before I continue,” you’ve gone too far. Be honest with yourself. That work item is there to protect you and your company from potential lawsuits, not for the benefit of your customer.

If a work item is not user-centric, do not try to force it into a user-centric format. In this case, you could write a story from the point of view of another stakeholder (e.g. “As a regulator, I want a checkbox…”) or simply write the task in a more straightforward way such as: “Include link to privacy policy and only allow users to continue to the next page if the checkbox has been checked.”

3. Practice vertical slicing

A challenge that you will encounter as a product owner is dividing user stories into small pieces of functionality that add value on their own. You will be pressured to break user stories into smaller tasks that are stripped of any value to the user. For instance, your back-end developers will ask for a story to define an API and legal will request a story to get approval for the language used on a webpage. This happens because, in most professions, we are used to dividing complex problems into simpler and smaller parts by layers or by disciplines. In software development, for example, we are used to separating back-end from front-end work. In copywriting, we tend to separate the creative part from legal disclaimers.

In these situations, the product owner acts as a guardian of the agile principles and needs to find a balanced approach. On one hand, if the work item is a user story by nature, then it should be described from a user’s perspective. On the other hand, you need to acknowledge that your colleagues' demands indicate a need for smaller and simpler work items.

In these cases, vertical slicing is your best bet. Vertical slicing consists of dividing user stories into smaller pieces of functionality that still add value to the user. Vertically sliced stories will still require work through the same layers of development. However, they will simplify the work required on each of those layers and arrange it so that a small piece of functionality can be delivered within a sprint.

This is best explained with an example. Imagine that you’ve written this story:

As an existing customer applying for a new account, I want my contact information to be pre-filled on the application form so that it is easier for me to apply.

If you were to divide this story by layers, you might create the following tasks:

1. Define and implement an API for contact information.
2. Create a service to save changes to personal information.
3. Create a screen and pre-fill personal information.
4. Add hover-type icons that provide help for certain fields.

Following this approach, you cannot deliver any value until each of those tasks has been completed. But if you divide the story into vertical slices, you can define smaller pieces of functionality. These smaller pieces can not only be quickly delivered, but each one can also provide independent value.

• As an applicant for a new account, I need to provide my personal information so that I can submit my application.

• As an existing customer applying for a new account, I want my contact information to be pre-filled on the application form so that it is easier for me to apply.

• As an existing customer applying for a new account, I want to be able to edit the pre-filled information on my application form so that I can update it when applicable.

• As an applicant for a new account, I want explanatory texts that help me understand what I need to enter in specific fields so that it is easier for me to fill out the form.

Each of these stories is smaller than the original. That means they are simpler to work on and still have value on their own.

4. Negotiate items out before accepting items in

When I first became a product owner, I felt a lot of pressure to accept all the requests that came in. I wanted to keep everyone happy, but I quickly learned that a product owner cannot be a yes man or woman. A product owner has to protect the quality of the product, the efficiency of the Scrum team and the profitability of the business. And to do that, a product owner needs to say no — a lot.

But, I have found a way to reject requests in a way that is both useful and diplomatic. If you make your stakeholders take an item off the backlog before you accept a new one, you are protecting them from adding distractions that will steer you away from what matters to them and your customers. You will learn that, when faced with this challenge, the petitioner will often abandon their request. What they swore was critical turned out to be unimportant once they had to give up something to make room for it.

5. The product backlog is not your baby. Share responsibility

The backlog is not your baby. As a product owner, you are responsible for the product backlog. However, work items are discussions — they can and should be enriched by collaboration. Do not be afraid to let others add to your precious user stories. The solutions architect and your developers may have valuable contributions to the technical details of a work item.

It is common for product owners to be overprotective of their backlog, but agile is built on transparency and trust. If you cannot trust your team with edit permissions, you have bigger problems to worry about.

Conclusion

The product backlog is not only a powerful tool under agile and the Scrum framework, it is also the product owner’s best artifact to promote focus, transparency and collaboration. With this article, we wanted to help product owners go one step further by sharing strategies for product backlog management that can only be learned through experience.