Inherited a messy product backlog? Start with the next decision

1. Start with the goal and the commitments

Purpose: Understand the goal and existing commitments before changing the order.

Ask the Product Owner or relevant decision-maker what the product is trying to achieve next. Then ask which commitments have already been made, to whom, and where the evidence sits. A promised customer update, an operational risk and an interesting feature idea need different conversations.

If you are the new Product Owner, speak to stakeholders and the team before announcing a new order. In Scrum, ordering the Product Backlog is part of your accountability. Understanding existing commitments helps you exercise that accountability responsibly.

Use these opening questions:

• What outcome matters most over the next few weeks?
• Which entries support that outcome, and how do we know?
• What is already in progress or promised externally?
• Which risks or dependencies could change the order?
• Who can clarify an item when its author has moved on?

2. Review a useful sample

Purpose: Identify which items need clarification, investigation or a decision.

Start with the items near the top, work already under way, and anything connected to a current commitment. The first ten is a reasonable starting sample, not a required rule.

For each, identify the user or operational problem, the evidence behind it and the decision needed. Mark uncertainty explicitly. An unexplained title is a request for clarification, not proof that the work has no value.

Group potential duplicates for discussion. Link their evidence before combining them, and preserve the history your organisation needs. Agree an approach to archiving old requests before moving them out of the active view.

Worked example: three tickets, one underlying problem

Purpose: Explore how several requests can point to the same underlying problem.

This is a fictional teaching example, not a client case study.

A membership platform has three requests: “Add CSV export”, “Improve reporting” and “Email weekly attendance”. A conversation with the service team reveals that all three arose because coordinators spend Friday afternoons collecting attendance figures manually.

That finding does not automatically mean the requests should become one feature. It gives the team a clearer problem to investigate: help coordinators prepare their weekly attendance report with less manual work.

The next decision is which information they need, how frequently and in what format. A sample report and a short conversation with coordinators could answer that before anyone estimates three separate solutions.

Record the original requests, link them to the shared problem and explain what is still uncertain. Avoid presenting a proposed solution as an approved commitment.

Run a focused 30-minute review

Purpose: Leave the review with clear actions and a date to revisit them.

Invite the people needed for the decisions: usually product, development and someone who understands the user or service problem. Adjust this suggested agenda to the work.

• First five minutes: confirm the outcome and any existing commitments.
• Next ten minutes: examine a small set of relevant items and their evidence.
• Next ten minutes: identify duplicates, unanswered questions and dependencies.
• Final five minutes: agree the next action, who will take it and when to revisit it.

Success might be three clarified items and one useful investigation. You do not need an empty inbox or a perfectly tidy backlog to make progress.

Copy this backlog review note

Purpose: Capture the evidence, uncertainty and decision needed in one place.

Use one note per problem or related group of requests.

• Item or group:
• Problem and who experiences it:
• Evidence available, including its date:
• Link to the current product goal:
• Existing commitment or dependency:
• What remains uncertain:
• Decision needed and who can make it:
• Next action, owner and review date:

Choose five items near the top of your backlog. Complete the note for each and bring the unanswered questions to the people who can resolve them. If no shared product goal exists, make agreeing that goal the first conversation.