A product backlog is a list — in priority order — of all the tasks required to execute a strategic roadmap. It serves as a reminder of what the development team needs to focus on, e.g updates, bug fixes, and user stories.
The product backlog is a critical artifact in the Scrum development process and is the responsibility of the product owner, who maintains its content, availability and ordering.
Crucially, this backlog is not a static to-do list for your development team. It is a dynamic and living document, constantly evolving as required based upon feedback, technological advances or changes in stakeholder requirements.
By prioritizing outstanding tasks, the team has a clear vision and direction. However, unlike a product roadmap — which focuses on higher level themes and epics — the product backlog contains task-level priorities. It is in executing these task-level activities that the team reaches the strategic goal illustrated in the product roadmap.
Whilst these task-level priorities will differ from team to team, the most useful product backlogs all share a number of common characteristics.
The best product backlogs are described by agile experts, like Roman Pichler and Mike Cohn, as 'DEEP':
D - Detailed Appropriately. Upcoming items are detailed enough to be understood by the whole team. Items which will not be completed for awhile contain less detail.
E - Estimated. A product backlog is a planning tool, helping to organize development resources available. However, only upcoming stories should have a precise time estimate. Items further down the backlog are not yet fully detailed and therefore will have less precise time estimates.
E - Emergent. A product backlog should change and evolve. As the team learns more through developing the product, items from the backlog will be added, removed or reprioritized.
P - Prioritized. A product backlog should always be sorted with the most valuable items at the top and the lowest value items at the bottom. If the team is unable to value an item, they should question whether it belongs on the backlog at this time.
For the individual backlog items or activities, it is best practice for the items to follow Bill Wake's INVEST model:
I - Independent. Each item should not depend on, or overlap with, other items.
N - Negotiable. Each item should be created in collaboration with key stakeholders.
V - Valuable. Each item should be valuable to the customer.
E - Estimable. Each item should be estimated, so they can be prioritized with the development resources available.
S - Small. The best backlog items are small and concisely written, so it's easy for all parties to understand what work needs to be done.
T - Testable. It should be obvious when the goal of a backlog item is met.
The whole team should collaborate to create the backlog, but the product owner holds it together, taking responsibility for maintaining and organizing it.
According to the Scrum Guide, a product owner is “responsible for maximizing the value of the product resulting from work of the development team" and is "the sole person responsible for managing the product backlog".
This management comprises of:
Clearly expressing backlog items.
Ordering the items in the product backlog to best achieve strategic goals and missions.
Optimizing the value of the work the development team performs.
Ensuring that the product backlog is visible, transparent, and shows what the Scrum Team will work on next.
Ensuring the development team understands items in the backlog to the level needed.
Some teams may have an additional sprint backlog owned by a delivery team or additional backlogs with different owners and purposes.
Whereas a product backlog lists the tasks required to develop the product at task-level, a product roadmap focuses on the strategy behind the product.
This makes them very different, but perfect when used together. For a new product, use a roadmap to get started and define the direction you want your product to take. Then, create a product backlog to show the small steps required to get there. This ensures the roadmap and backlog are aligned.
If you notice the backlog and roadmap aren’t aligned, stop development until you have a clear — and agreed — vision for moving forward.
When you start developing a new product or feature, you should avoid making backlog items too detailed. Instead, keep your lower-priority items coarse-grained and refine them when you decide when you want to implement them. This allows you to use your latest customer feedback and insights to shape further developments, rather than making incorrect assumptions too early.
A great product backlog is written with the help of the development team. This allows you to benefit from their knowledge and spot technical risks quicker. Even better, you'll get buy-in from the team, making them more motivated and productive.
A great product owner rejects items/actions which do not help the product achieve its goals. This ensures the product moves in towards its product vision. If the idea is important, but can't be achieved within the next few sprints, it should be added to the product roadmap instead.
A cluttered product backlog risks slowing development time and wasting resources on non-essential activities.
Prioritization is hard. That's why we've made prioritization a key part of airfocus, so that you can most effective route toward your shared company vision.
Remember: the product backlog should be a living document. If your backlog is locked away in Excel, PowerPoint or on paper, it's difficult to keep up-to-date and circulate to all stakeholders. As such, it’s important to make sure that you embark on your product backlog process with a purpose-built tool. With a dedicated tool, you can create and update backlog items in minutes and share a visually compelling backlog to stakeholders instantly.