Building Your Product Backlog

Building a good Product Backlog according to the "three F" is key to realising your product vision

A rudimentary Product Backlog. Back then, pink was fashionable.

When starting your journey to build a new product, you probably already have a clear notion of where you want to be. If not, then you might want to first check out my post about phrasing your product vision.

Now, even if you have a clear vision about your product, you often do not know how to get there or what awaits you along the way. This is precisely the reason why teams employ agile methodologies to make their product vision come true, as it enables them to anticipate and swiftly react to change while following a common guiding star.

At the core of this lies an artefact called the Product Backlog, which, when used skillfully, will make your team deliver your vision to the maximum benefit for its stakeholders.

What is a Product Backlog?

The term Product Backlog become popular with Scrum, an agile process framework that has been widely adopted for agile project management. By definition in the Scrum Guide, a Product Backlog is

An ordered list of everything that is known to be needed in the product.

Scrum is not the only agile methodology that your team can employ when working with a Product Backlog. Rather, it is important to make use of the 3 key principles behind a Product Backlog, which can of course also be met when using other agile methodologies.

What are the Key Principles of a Product Backlog?

When filling up your Product Backlog with elements, the so-called Product Backlog Items, be sure to keep the following 3 key principles (the three F) in mind. By adhering to them, your team makes sure that at each point in time, your product delivers the maximum possible value to your stakeholders. This is especially important when dealing with a VUCA environment.

Principle 1: Forced Ranking

Each element in the Product Backlog is assigned a business value that is either higher or lower than those of other elements. The ordered list concept implies that the higher the business value of an element is, the higher up it is in the list. If your team pulls the Product Backlog Items to be implemented from the top of the Product Backlog, your team will always work on what generates the most value for your product.

Principle 2: Focus on Stakeholders

Your team wants your product to deliver maximum value to its stakeholders. This implies that each Product Backlog Item needs to have originated from a "conversation" with a stakeholder who voiced his needs. In doing so, each element can be related to a stakeholder that benefits from its implementation and your team can decide upon the overarching business value (see above).

Principle 3: Fuzzy Planning

We can not possibly know what happens in the future, although we often pretend to. But we can try to predict it. Such a prediction is called planning and, naturally, often gets less accurate the farther in the future our prediction lies. In spite of this uncertainty, your team should plan ahead, but only try to roughly sketch Product Backlog Items having low business value, as they will be implemented farther away in the future. This implies that your team needs to constantly reassess the Product Backlog and replan it, if necessary.

Steps to Building Your Product Backlog

There exist many ways to build a Product Backlog and to represent the corresponding Product Backlog Items. As long as the result meets the above principles, your team can use varying approaches in different projects, depending on the circumstances.

I made some good experiences when structuring the Product Backlog into stakeholder-centred Epics and User Stories, an approach that I will outline in the following.

Step 1: Identify Stakeholders and Their Needs

First, start off with examining your product vision and your company's mission statement. Devise which stakeholder groups need to be benefit from your product in which way and gather as much input as possible from them. This step is crucial and can be accomplished in many ways, which is why I will dedicate an entire future post to it. I recommend getting as close to the stakeholders as possible in order to properly understand and record their needs.

Step 2: Formulate Epics

In a next step, your team should use the gathered input to formulate so-called Epics, which are Product Backlog Items that describe a need of one or several stakeholder groups in a succinct manner. Each Epic typically needs several iterations to be completed. In case you want to know more, please have a look at my post on how to phrase Epics.

Step 3: Rank by Business Value

Once you have devised all Epics that are (currently) known to be needed in the product, assign a business value to each of them and rank them according to descending value. Again, there are several ways to accomplish that. In Scrum, for instance, the Product Owner would rank the Product Backlog either on his own or in the course of a Product Backlog Refinement together with the Development Team.

Step 4: Devise User Stories

The concluding step to building your Product Backlog is to examine each Epic and its Acceptance Criteria in order to devise the related User Stories. In contrast to an Epic, a User Story needs to be completable within at most one iteration and focuses on one stakeholder only. As soon as your team has created a reasonable amount of User Stories (keep Fuzzy Planning in mind!) you again need to rank them by business value. For your ranking, you can use the ordering of the related Epics for guidance, but you do not have to. It also pays off to keep Epics and User Stories in two separate columns of the same list, as only the latter will finally be implemented in an iteration (i.e. placed in the Sprint Backlog).

How Do You Become Entangled?

By building a Product Backlog, your team has already made a first step to turn vision into reality. In the process, your team connected to your company, since it translated its vision into a product vision and used its mission statement to identify the most relevant stakeholders.

Your team also became entangled with the latter, since it built up the ability to communicate with and obtain feedback from stakeholders. This concerns your stakeholder's needs as well as the business value they attribute to the realisation of each need. Stay entangled by iterating and never losing contact with both your company and your stakeholders!

Care to Know More?

Initially, I wanted to state the following in the caption of the image at the top: "This is how a Product Backlog should not look like" . Giving it a second thought, I realised that this would be too harsh a statement, as also the simplest of Product Backlogs can satisfy the three F. Therefore, be creative with how you define Product Backlog Items and always try to think of the best approach for the given circumstances.

Would you also like to know more about this post's topic? If so, then please post your questions in the comments below and I will be answering them. If the subject of your question is a hot topic, then I will dedicate a post to it in the future.