Product Backlog – The main responsibility of the Product Manager

As a Product Manager you have plenty of responsibilities, all leading to my favorite definition of the product management: building the right product and building it right. There are many factors on which this depends and one of the most important is the quality of the Product Backlog.

What is the Product Backlog?

The Product Backlog is one of the three artifacts described in the SCRUM theory along with the Sprint Backlog and the product Increment. And since the Sprint Backlog is basically a subset of the Product Backlog and the Increment is a result of it, I would venture to say that the Product Backlog is the most important artifact and the main responsibility of a Product Manager.

In the Scrum Guide, the Product Backlog is described as being:

„An ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.”

Product Backlog Item Types

A product backlog typically includes:

1. New features
2. Changes to existing features
3. Defects / Bug fixes
4. Other type of activities necessary to deliver product increments

While the first three types are pretty self explanatory, the last one needs some clarifications. The other type of activities necessary to deliver product increments could be infrastructure changes, technical debt tasks, technical spikes, business requirements, etc.

A feature is a piece of functionality that a user needs and which brings value to the product. The manner in which the feature is described in the product backlog depends on preferences of the Product Manager and/or the development team but very frequent in the agile development you will hear about “epics” and “stories”. An epic is one big piece of functionality, usually too big to be completed in one sprint and should be split up into smaller bodies of work while a story  is a specific task within an epic. A good product backlog will contain stories at the top of the list and epics towards the end of it. Because…

The Product Backlog needs Prioritization

Having items added to the product backlog is not enough. Generating a list of things it should or it would be nice to have in a product can be done by anyone. If it would be that simple then nobody would need a Product Manager. The Product Backlog is a living artifact which exists as long as the product exists. There is no such thing like an empty product backlog. Anyone who ever worked on a product development will tell you there is no such thing like “we have finished everything, product is done, we don’t need a product backlog anymore”. On the contrary, they will tell you that it can get so big that it can no longer be managed properly.

That’s why the Product Backlog needs Prioritization. And the only one who is responsible for this is the Product Manager. He or she should always be connected to the products stakeholders, development team and users and based on this permanent communication and feedback to decide what must be done, what would be good to be done and even what shouldn’t be done.

One popular technique for prioritization is MoSCoW. The term MoSCoW itself is an acronym derived from the first letter of each of four prioritization categories (Must have, Should have, Could have, and Won’t have) with some adjustments so it can be pronounceable. As you can imagine the Product Manager should identify the must haves, the “should”s, the “could”s and what doesn’t belong to the product backlog.

The most important items are the ones that Must be developed and they should stay on the top of the Product Backlog having the highest priority. The Should requirements are as important as the Must ones are, but they can wait before they are implemented. Requirements labeled as Could, are desirable but not necessary and while they can add value to the product, they don’t need to be performed first.  The Won’t items are lowest-payback items, or not appropriate at that time, and they will not be planned into the schedule for the next delivery time box. Sometimes the Won’t items will stay on the bottom of the Product Backlog and sometimes they will not even be included in the backlog.

Whenever Product Managers are using this technique for prioritization they should bare in mind that is not just the value of the item itself which dictates where to fit in the MoSCoW paradigm. A very important factor to be considered is the dependency. Sometimes an item could look as not being very important in terms of the value added for the final user, but it could be an important piece in terms of dependencies. Not having that particular item completed could prevent you from having other more important ones so it’s mandatory to be performed first. That’s why the Product Manager should communicate with the development team as frequent or even more than he or she is doing it with the stakeholders.

The Product Backlog needs Transparency

Even if the Product Manager is the only person allowed to make changes to the Product Backlog (or with his/her permission), this doesn’t mean this is a top secret artifact. On contrary, transparency it’s one of the main attribute of it and it’s the Product Manager responsibility to ensure this is actually happening. He or she must ensure that everyone within organization is having easy access to the Product Backlog and, just as important, all the items are clear enough and easy to understand. That’s why many teams are choosing to use physical white boards with items written on post-it sheets of paper located somewhere in the office where everyone have access.

The Product Backlog needs Refinement

As stated before, the Product Backlog is a living artifacts which exists as long as the product exists. Its “living” characteristic refers to the fact that the Product Backlog content is dynamic and should change as frequent as needed. Beside prioritization which involves moving items on a vertical axis, from urgent to less important, backlog items can be added, “groomed” or removed.

It’s the Product Manager job to stay connected to stakeholders and customers feedback and adjust the items accordingly. Market conditions can and usually will change so the product backlog should reflect this reality. One item that made sense at some point can become obsolete and while it doesn’t make sense anymore should be removed or dramatically changed. Even worse, sometimes the product needs a complete pivot so most of the product backlog items must be replaced.

According to the Agile Alliance these are the most common activities performed for the Product Backlog Refinement:

• removing user stories that no longer appear relevant
• creating new user stories in response to newly discovered needs
• re-assessing the relative priority of stories
• assigning estimates to stories which have yet to receive one
• correcting estimates in light of newly discovered information
• splitting user stories which are high priority but too coarse grained to fit in an upcoming iteration

Final words

A good, updated and well-prioritized product backlog plays a crucial role for the success or failure of a product. It’s not only making release and iteration planning easier but also reflect all the things the team is intending to spend time on, including the internal work that is usually not very obvious to the final user but is very important for the stakeholders. This helps setting expectations and it’s the Product Manager safety net when unrealistic expectations are about to happen. So make sure you keep it strong!