Scrum for Beginners 3-5-3 Part 9: Product Backlog and 3 Pro Patterns for Maintaining it

Hello! This is Part 9 of a series on scrum using the 3-5-3 framework (3 roles, 5 events, and 3 outputs) where we use the Scrum Guide as a base for our learning.

In this article we will cover:

• What is the product backlog?
• 3 product backlog management pro patterns 🌸

Click the emoji to jump to each section in the article.

What is the Product Backlog?

If you have been part of any team doing scrum, you have heard of the product backlog. It is what it sounds like: a backlog for the product.

And it's more than that.

As a tip, if you want to know basic information about scrum, the Scrum Guide is a fantastic resource.

The Scrum Guide says:

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

With this explanation we can conclude that the product backlog is a list of required tasks for new features, improvements, and testing criteria for a single product.

As the words "single source" indicate, there is no other place for work to exist other than the product backlog. If the team is to do it, it must be represented in the product backlog.

This next part of the Scrum Guide explains a little more about what goes into the product backlog:

Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities.

Using this long list of features, tasks, and dreams developers and PO work together to set priorities and create a working increment by the end of the sprint (1-4 weeks).

There is one downfall of the product backlog that you may have already noticed-

"Aren't you just building a list of random things with arbitrary priorities?"

You would be if not for the required commitment of the product backlog. Here, "commitment" has the same meaning as "output".

The Scrum Guide explains what the commitment is for the product backlog:

 Commitment: Product Goals based on the Product Vision

 The product goal describes a future state of the product which can serve as a target for the scrum team to plan against. Let's go a little more meta on "product" in order to see how all of these concepts work together.

The Scrum Guide says that a product is

...a vehicle to deliver value. It has a clear boundary, known stakeholders, and well-defined users or customers. A product could be a service, a physical product, or something more abstract.

The product goal for the product is in the product backlog. The rest of the product backlog emerges to define “what” will achieve the product goal.

 The product goal is the long-term objective for the scrum team. There may be multiple however the teams must fulfill (or abandon) one objective before taking on the next.

If our commitment is the product goal and every product backlog item (PBI) is in service to that goal, then our priorities become clear.

A product backlog without a product goal leaves the scrum team scrambling to find purpose in their work and can at worst, have them building the wrong things for the wrong reasons.

It is the PO's responsibility to have the product goal be understood by all stakeholders, domain experts, and most importantly, the scrum team/s that will build the product.

3 Product Backlog Management Pro Patterns for any team

Here are 3 quick pro patterns for more effective product backlog management:

1 .Put your product goal into your product backlog
As we learned earlier, the product backlog cannot exist without a product goal. The product goal is the North Star for the team/s who will be working on the product.
Having your product goal in your backlog makes it easier to have conversations about what is actually required for the next sprint in order to move closer to the goal, and what can wait until later.

The product goal should be visible somewhere in your backlog, whether it is a digital tool like JIRA or a large piece of construction paper on the back wall of the office.

2. Balance implementing new features with improvements to existing features
It is a common pitfall to over-prioritize new features over improvements like refactoring. The opposite can also be true. Either way, the result is often a lower quality product delivered later than needed. This is not a healthy product backlog.
There are many different ways to address this, one being keeping the scrum team's Definition of Done up to date. However, you can also address this imbalance within the product backlog itself.

The PO sets the priorities for the product backlog, however anyone at any time can add items. Have a healthy balance of new features (user stories) and necessary improvements to bring to product backlog refinement.

3  Visualize the product backlog with user story mapping
For all the value a well-organized, well-prioritized product backlog gives, it is still 2-dimensional. It can only ever tell you the priority of an item and a certain level of detail.

For many teams building products and services for their users, this leaves out the users.

One answer to this problem is user story mapping, a user-focused approach to building the product backlog.With user story mapping, priorities become clearer, the user journey is prioritized, and the potential releasable slices of the product are easier to visualize.

For more on user story mapping I recommend this book: User Story Mapping by Jeff Patton.
https://jpattonassociates.com/jeff-pattons-book-released-user-story-mapping/

I hope this helps clear up some basic information about the product backlog and gives you some inspiration for how you can better utilize your product backlog.