A product backlog is a list of tasks and features that need to be done to develop a product. It helps teams plan and organise their work in order of importance. The top items on the product backlog show the team what to work on first.

The development team doesn’t wait for the product owner to assign work. Instead, they take on tasks from the backlog when they have the capacity for it following a methodology like Kanban or Scrum. The product backlog is based on the team’s roadmap and requirements. The roadmap is made up of big goals that are broken down into epics, which then have specific requirements and user stories.

How to prioritise your backlog?

A prioritisation methodology can help define the order of your backlog. Common techniques include RICE, MoSCoW and Effort vs. Value. I won’t go into specifics into the pros and cons of each methodology in this blog post (possibly a future blog post). I personally lean into MoSCoW and Effort vs. Value more as using RICE can be challenging to quantify.

As a Product Manager, I’m constantly reviewing the items using these prioritisation methods. The key is to use data from users (qualitative and quantitative), impact on the product, implementation time, stakeholder feedback, and input from the wider business to decide the order of a backlog. Make this prioritisation open and transparent so it is clear to stakeholders why you are working on something first.

Before planning meetings, Product Managers should check the list of tasks to make sure they are in the right order and that any feedback from the last round of work has been included. This regular checking of the list is often called “backlog grooming” or “backlog refinement” in agile teams.

‘Prioritisation is knowing what comes first, and what comes after’ an image by Black ice: https://www.pexels.com/photo/blue-background-with-text-overlay-1314536/

How to structure your backlog?

You’ve heard of Earth, Wind and Fire? Now it’s time for Ice, Water and Steam.

Here’s a simplified way to label your backlog:

• Ice: Clear understanding of estimates, tasks, complexity, value, and potential deadline.
• Water: Some idea of scope, but with remaining questions. Deadline is flexible and value is subjective, requiring further discovery.
• Steam: Initiative is recognised, but not yet thoroughly explored. More effort needed to develop it into ‘Water’.

The diagram below visualises how to structure your backlog.

‘A way to visualise your backlog’ an image by Hustle Badger: https://www.hustlebadger.com/what-do-product-teams-do/product-backlog/

Simplify how your team sees the backlog

Of course, a backlog can be a mammoth beast to wrestle with. It can overwhelm your team if they see all of the work to be done. That’s why I like to break down my backlog further into a sprint backlog.

‘A product backlog and how it feeds into a sprint backlog’ an image by Sakshipore: https://medium.com/@sakshipore28/product-backlog-vs-sprint-backlog-b5ddc6f87f6a

The sprint backlog is a list of tasks the development team agrees to complete during a sprint. It aims to break down product backlog items into actionable tasks and create a clear plan for the sprint, which is a set period for work. The items are usually user stories or tasks.

The sprint backlog begins with a planning meeting, where the team chooses tasks from the product backlog. As work advances, the team refines and updates the backlog. In daily standup meetings, team members share progress and any obstacles they face, keeping the backlog current and ensuring the team stays on course to meet the sprint’s goals.

‘The difference between a product backlog and a sprint backlog’ an image by ProjectCubicle: https://www.projectcubicle.com/product-backlog-vs-sprint-backlog/

Things to look out for

• The backlog is not being constantly prioritised, and adjusted based on feedback.
• The team is focusing on user-facing stories and not addressing technical debt, bugs and back-end changes.
• The backlog is not shared with others. Your work should be open and transparent. Importantly, this doesn’t mean anyone can add items to your backlog without speaking to the team.
• Backlog items are not aligned with the roadmap. Consider removing anything if it doesn’t align with your vision and strategy.
• The items in the backlog are not well understood. Pre-planning and planning is an opportunity to ensure the team is on the same page.

In conclusion, a well-organised product backlog is crucial for product managers as it outlines tasks for engineers, tracks feature confidence, and provides insight into the team’s health and future success.