Backlog Review

A well-organized agile backlog not only makes release and iteration planning easier, it also conveys everything your team intends to work on—including internal work that the customer will never notice. This helps set expectations with stakeholders and other teams, especially when they take on additional work for you, and makes the engineering team’s time fixed.

The product backlog is a list of work that the development team must accomplish organized by priorities. It comes from the product roadmap and its requirements. The most important items are shown at the top of the product backlog so the team knows what to do first. The development team does not work on the backlog at the product owner’s pace , and the product owner does not forward work to the development team. Instead, the development team takes work from the product backlog according to its capacity, either at a continuous pace ( Kanban ) or by iteration ( Scrum ).

A team’s roadmap and requirements provide the basis for the product backlog. Roadmap initiatives are split into multiple epics, and each epic will have multiple requirements and user stories. Let’s look at the roadmap for a fictional product called Teams in Space.

As the Teams in Space site is the first initiative on the roadmap, we’re going to break this initiative down into epics (shown here in green, blue, and teal) and user stories for each of those epics.

The product owner organizes user stories into a single list for the development team. The product owner may decide to offer a full epic first (left). Or it may be more important for the program to test book a discounted flight, which requires stories from multiple epics (right). See the two examples below.

What can influence the product owner’s prioritization?

• customer priority
• Urgency in receiving feedback
• Relative implementation difficulty
• Symbiotic relationships between work items (e.g. B is easier if we do A first)

While the product owner is tasked with prioritizing the backlog, those priorities don’t come out of nowhere. Effective product owners seek feedback and feedback from customers, designers, and the development team to optimize workload and product delivery for everyone.

Once the product backlog is created, it is important to regularly keep pace with the program . Product owners should review the backlog prior to each iteration planning meeting to ensure that the prioritization is correct and that feedback from the last iteration has been incorporated. Regular backlog review is often referred to as “backlog preparation” in agile circles (some use the term backlog refinement).

When the backlog gets bigger, product owners need to group the backlog into short-term and long-term items. Short-term items need to be fully realized before being labeled as such. This means that complete user stories were written, design and development collaboration was organized, and development estimates were made. Items with longer deadlines can remain a little vague, but it’s a good idea to have a rough estimate from the development team to help prioritize them. The key word here is “approximate”: estimates will change once the team has a full understanding and starts working on the longer-term items.

The backlog serves as the connection between the product owner and the development team. The product owner is free to change work priorities in the backlog at any time based on customer feedback, resetting estimates and new requirements. However, when work is in progress, make minimal changes as they disrupt the development team and affect focus, flow, and mood.

Anti-patterns that must be observed

• The product owner prioritizes the backlog early in the project, but does not adjust it as feedback passes through developers and stakeholders.
• The team limits items on the backlog to those that are customer-facing.
• The backlog is maintained as a document stored locally and shared infrequently, preventing stakeholders from receiving updates.

Smart product owners rigorously organize their program’s product backlog, making it a reliable and shareable highlighting tool for a project’s work items.

Parties will challenge priorities, and that’s a good thing. Fostering discussion around what’s important keeps everyone’s priorities in sync. These discussions foster a culture of group prioritization, ensuring that everyone thinks the same about the program.

The product backlog also serves as the basis for iteration planning. All work items must be included in the backlog: user stories, bugs, design changes, technical debt, customer requests, retrospective action items, etc. This ensures that everyone’s work items are included in the overall discussion for each iteration. Team members can compromise with the product owner before starting an iteration with full knowledge of everything that needs to be done.