Demystifying The Product Backlog

Within the context of agile software development, the product backlog is a “living” platform where all the potential work (product backlog items) that need to be delivered are recorded, tracked and prioritized. Though owned by the Product Owner, anyone may suggest items to add to it. It is refined and re-prioritised by the Product Owner throughout the project and can be viewed by relevant stakeholders. The product backlog is a combination of epics, stories and other key work items that are relevant to the development of the final product or solution. The items on the backlog are prioritized with higher value work done first.

A periodic review of the backlog should be done constantly to ensure that changes to stakeholders’ needs and priorities are captured.

Smaller units of work on the backlog are called user stories. The work for each user story needs to be small enough to be completed in a single sprint (2 to 5 days of effort); user stories are often too small to deliver value by themselves, with several stories adding value under the same “epic”. User stories are usually described using the format specified below:

As a  (role/user)

I want (description of what is needed)

So that (the reason/why it’s needed)

User stories have to be supported by acceptance criteria however, a list of conditions to be met for the story to be considered “done”. 

Tasks can be linked to user stories where they provide a more detailed description of what needs to be done for a story to be considered “done”. Tasks are however estimated in hours, not story points.

The sprint backlog is a subset of the product backlog that the team commits to deliver during each sprint, which could be stories or spikes. Spikes are time-boxed experiments completed within a sprint to research, design or explore certain concepts and can help the team understand a story. The sprint backlog thus includes all the planned work in the sprint which could be stories, defect fixes, items for reducing technical debt, enhancements, etc. The sprint backlog is usually placed in a visible area of the team’s location or may even be displayed electronically.

The backlog may also contain other items like risk items, non-functional requirements, change requests, defects, planned rework, documentation tasks, etc. Each product backlog item typically contains description, priority and estimates assigned to it as part of backlog refinement. Product items that can be completed by the development team within a sprint are tagged as “ready” for selection during the sprint planning ceremony.

Though the Product Owner is ultimately responsible for the product backlog and its contents, the development team are responsible for estimates as they are best placed to determine how much effort is required for each item on the backlog to be considered done.