A healthy Product Backlog is like a healthy person: uncluttered, organized, transparent.

A well-prioritized Agile Backlog not only simplifies release and iteration planning, but also meticulously plans out all the work the team plans to do — including internal work that customers don’t even care about. Especially when stakeholders and other teams have additional work demands on the team, Backlog can help them set expectations while also making engineering time valuable and producing actual deliverable results.

What is a Product Backlog?

The Product Backlog is a prioritized list created by the development team based on the roadmap and requirements. The most important items are displayed at the top of the Product Backlog, making sure the team knows that they are what needs to be delivered first. Therefore, the development team does not work at the pace dictated by the Product Owner, nor is the Product Owner the driver of the development team’s work. Instead, the development team works sequentially from the Product Backlog, completing projects through continuous improvements to kanban or iterations of Scrum.

Expert tip: Store all work in the same task tracker — don’t use multiple systems to manage bugs, requirements, and development work items. If it’s something that the development team is required to do, keep it in a single list.

Start with the two R’s

The team roadmap and requirements lay the foundation for the Product Backlog. The roadmap plan can be broken down into several epIcs, each containing several requirements and user stories. Let’s take a look at the roadmap for a fictional product called Teams in Space.

Since the Teams in Space site is the first task on the roadmap, we wanted to break this task down into the following three different development epics (shown here in green, blue, and turquoise) and the different user stories within each epic.

The Product Owner then consolidates the requirements for each user story into a single list for the development team. The Product Owner can first provide a single complete epic (left picture). Or, if the test of booking a discount flight is more important to the system, you need a couple of epic user stories (right). Here are two examples:

What factors might affect the prioritization of a Product Owner?

  • Customer priority
  • Urgent feedback
  • Relative difficulty of implementation
  • Relationships between work items (e.g., B is easier if A is done first)

While prioritizing the Product Backlog is the Product Owner’s task, it should never be done behind closed doors. In fact, the Product Owner collects comments and feedback from customers, designers, and development teams to optimize each person’s workload and the Product to be delivered.

Make sure the Backlog is in a healthy state

Once the Product Backlog is created, it is important to maintain it regularly to ensure that it is consistent with the overall rhythm of the development project. The Product Owner should review the backlog before each iteration planning meeting to ensure that the priorities are correct and that feedback from the previous iteration has been incorporated into the current iteration. Periodic reviews of the Product Backlog are commonly referred to in agile circles as “Backlog grooming.” If the Product Backlog becomes larger, the Product Owner needs to group the Backlog for short – and long-term projects. Short term projects need to be detailed before labeling. This requires working with design and development to develop a complete user story and estimate development time. Longer term projects don’t need to be particularly clear and specific, but it’s good to have the development team do a rough estimate to determine the project’s priorities. The key word here is “rough” — that is, all estimates are subject to change once the team fully understands and starts working on the long-term project. The Backlog serves as a bridge between the Product Owner and the development team. The Product Owner can reprioritize the Backlog at any time due to customer feedback, refined estimates, and new requirements. However, once you are in development, try to keep changes to a minimum as they disrupt the pace of the development team and affect focus, flow, and morale.

Experts say: Once the backlog is too large for the team’s long-term capabilities, try closing the backlog for tasks that the team can barely accomplish. In the team’s task tracker, mark these tasks with special expressions, such as “out of scope,” for later study.

Unconventional phenomena to watch out for:

  • The Product Owner prioritized the backlog at the beginning of the project and did not adjust it when developers and stakeholders provided feedback.
  • The development team restricts the backlog to customer-facing projects.
  • Backlogs are stored locally and not often shared, leaving the updated content unavailable to interested parties.

How does the Product Backlog keep teams agile?

Experienced Product owners rigorously modify the Product Backlog for their projects to make it a reliable and shareable outline of work. Backlog encourages discussions and decisions that can make a project healthier — because not every task can be number one. It is good practice for stakeholders to question established priorities. Having a discussion around priorities ensures that everyone’s priorities are aligned. These discussions promote a team culture of consistent priorities and ensure that everyone on the project is thinking in the same way. The Product Backlog is also the foundation of iterative planning. All work items should be included in the backlog: user stories, bugs, design changes, technical debt, user requests, action items in review, etc. Doing so ensures that everyone’s work items from each iteration are included in the overall discussion. Then, with full knowledge of everything that needs to be done, team members can weigh the work items for the iteration with the Product Owner before the iteration begins.

The Product Owner prioritizes the backlog of work items, while the development team uses the backlog to determine team development speed. For a new Product Owner who wants to “push” work to the team, this can be a difficult balancing act.


Worktile’s website: Worktile.com

Translation/proofreading: Worktile

This article was first published on Worktile’s official blog.