A Scrum Master can help the Product Owner manage the Product Backlog by guiding him to keep these five tips in mind

What is a Product Backlog?

As per the Scrum Guide, “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”. Very simply put, a Product Backlog is a collection of every good idea, request, and possibility for Product, Product extensions, or even entirely new offerings. Product Owner updates the Product Backlog when feedback from the market, customers, and stakeholders rolls in.

Why should a Product Owner know about Product Backlog management?

Let us refer to the Scrum Guide to understand the Product Owner’s accountability towards the Product Backlog. Scrum Guide states that “The Product Owner is also accountable for effective Product Backlog management”.

Let us try to understand why does Product Owner need to manage the Product Backlog. A Product Backlog’s utility lies in the accuracy and volume of its contents. More importantly, the Product Backlog must enable the product team to prioritise future work. If the Product Owner is not careful, then the Product Backlog is treated as a dumping ground for anything not requiring immediate attention. It becomes an easy excuse to thwart stakeholder’s wondering what happened to their request or pet project (“it’s in the backlog, we’ll get to it eventually”).

Tip #1 – Everything on your Product Backlog need not be a User Story

Many times, Product Owners and even Scrum Master are under the impression that everything must be in User Story in the Product backlog. Please remember that in Scrum, all items on the Product Backlog are called “Product Backlog Items” and not User Stories. User Story is a template used to describe Product Backlog Items. The User Story format looks like this:

As a < Persona / Who / Role >

I want < Functionality / Do some action / What >

So that < I get the value / Why >

For Bugs or Technical Debt or Technical Tasks, it often fails or has little or no value to describe such an item as a User Story. Please refer to an excellent article to learn about the syntax from the Feature Driven Development to write Technical User Stories.

Tip #2 – Ordering the Product Backlog continuously

Scrum Guide defines Product Backlog to be ‘emergent’ for a reason. Many Product Owners who transition from a Business Analyst background consider Product Backlog to be a different format of Software Requirement Specification. They think that a Product Backlog once created is good forever. As a Scrum Master, you have to educate the PO that a Product Backlog is a living artefact.

A Product Backlog evolves, changes, grows and shrinks over time. Therefore, it is imperative that the Product Owner continuously order the Product Backlog. As a Scrum Master, you must train your Product Owner on different ordering techniques, which they can then apply to order the Product Backlog. We will cover the various ordering techniques in a separate blog post.

​Every Sprint starts with a Sprint Planning event. For the development team to create an effective and actionable plan for Sprint, they will need an up-to-date and ordered Product Backlog.

Tip #3 – Focus on what and why

A prevalent trap that the Product Owner falls into is finding and describing solutions. This behaviour also depends on the culture and the expectations of the organisation. I am aware of many Product Owners who do a lot of business analysis, technical analysis, and create functional designs and descriptions for the Development Team. Work with your Product Owner to focus on What and Why. In other words, a Product Owner should only focus on the problem they are trying to solve or what is the opportunity they want to grab and why. A Product Owner must not focus on ‘How’. In any case, a team has more creative and problem-solving power than what one person (Product Owner) alone can have.

Tip #4 – Challenge the Product Owner with these 3 W’s

It is the job of the Scrum Master to ensure that the Product Owner stays honest to their original Product Vision. One of the techniques which the Scrum Master can use is to ask “The 3 W’s continually”:

• Who is the feature/functionality for?
• What need will this feature/functionality solve for that person or role?
• Why are we willing to fill that need, or what will be the ROI we will achieve by fulfilling this need?

Tip #5 – Work with the Product Owner to make the Product Backlog Visible

A Product Owner must make the Product Backlog transparent for all the stakeholders and the Scrum Team. There are multiple ways to achieve this transparency. One of the simplest ways is to make the Product Backlog visible and accessible to all. In the case of remote teams, you can consider using a tool like JIRA or Pivotal Tracker or Trello or even a shared Spreadsheet works. Having your Backlog on a wall is excellent if your team is in a shared physical location. At the same time, please remember to remind your Product Owner that this transparency works only if and when the Product Backlog is up-to-date.