The product backlog derives from the product roadmap. It lists the tasks that the development team need to complete in order of priority, with the most important tasks listed first. It provides a link between the product owner and the development team.
In agile, the development team pull work from the backlog as they have capacity for it, continually if using Kanban or by iteration if using Scrum.
Why have a Product Backlog?
Having a product backlog makes release and iteration planning much easier as it identifies all of the tasks that the team will spend time on, whilst providing the flexibility to adapt to new customer needs.
The backlog also provides a common ground, which aligns stakeholders and teams, ensuring that the most valuable tasks are implemented.
Product Backlog structure
There are four main categories in the product backlog, referred to as product backlog items (PBIs). Two categories are visible to customers (features and bugs), whilst the remaining two (technical debt and research) remain invisible.
New features
Requests for new features come from various sources, such as end users, sales, support and product management. New features are difficult to prioritise, as existing customers must be kept satisfied, whilst maximising near-term sales opportunities and working towards the long-term vision of the product.
It is the product owner’s responsibility to monitor and resolve any conflicting requests to ensure that the backlog contains new features that will attract new customers and ensure remaining customers remain loyal.
Technical debt
Work required for the product to remain up-to-date and be maintainable is included in technical debt. This work can include product upgrades, refactoring source code and making changes, which will support increased scalability. Allowing technical debt to build up can result in delayed product releases.
Technical debt is referred to as such, because it is similar to financial debt, interest is paid on technical debt in the form of longer development times. These PBIs should be included in the product backlog and prioritised alongside features and defects.
Bugs
Bugs, or defects, are issues discovered by the end user, which have escaped quality control during the development process. In agile it is common to make a product live with some minor, or moderate, defects, as opposed to Waterfall, which conducts testing during the last stage of development.
If bugs aren’t resolved then they can accumulate over time, and as such, they are managed with an issue tracker or included as part of the backlog.
Research
If little is known about how to implement a new feature or concept, or something new is being trialled, then research is instrumental. Time, referred to as “spikes”, should be set aside to expand the teams knowledge and understanding.
Product Backlog properties
A number of properties defines the product backlog:
Entries add value
Only entries that add customer value should be added to the backlog. This also includes entries that do not directly add to the functionality of the product but add value by improving quality or reducing incidents.
Entries include, but are not limited to, exploring customer needs and technical specifications, descriptions of functional and non-functional requirements and the work needed to launch the product.
Living document
The product backlog remains live throughout the entirety of the product and should be updated with new or refined requirements as appropriate. This means that the product backlog can and should be changed during the duration of the project.
Differing level of details
Only tasks that are to be implemented in the next couple of iterations should be described in detail in the product backlog. As the backlog is a living document it is likely that long-term tasks will change and so time should not be wasted working out detailed specifications for tasks that are not due to be implemented yet.
Ordered by priority
Each entry is prioritised using factors such as added value, costs and risks; the priority of each entry determines the order of the backlog.
Maintaining the Product Backlog
Referred to as backlog grooming or backlog refinement, maintaining the product backlog is essential to ensure it keeps pace with the programme.
The product owner should review the backlog before each iteration, ensuring that the priority remains correct and that feedback from previous iterations is incorporated.
Over the course of the project, it is likely that the backlog will become larger. At this point, the product owner should group the backlog tasks into short and long-term priorities.
Short-term priorities should be listed in detail; however, it is acceptable for long-term priorities to be vaguer, with rough estimates given to assist with prioritisation. Those rough estimates should be refined when the team start to work on the long-term tasks.
Summary
The product backlog is a vital tool to prioritise tasks, providing a link between the product owner and development team, and providing a common ground. It should not however, be mistaken for a to-do list, despite it being referred as such. To-do lists confer a list of tasks that must be done, making them rigid, whereas the product backlog is a flexible, living document.
