Backlog Refinement

Last updated on 2026-10-14 | Edit this page

Estimated time: 10 minutes

Overview

Questions

  • How do we refine the backlog?

Objectives

  • Please do not read the notes line by line or display all of the text during the course, as this may overwhelm participants. Prepare thoroughly in advance and explain in your own language or use the diagrams where present to explain concepts visually and guide discussion.

  • Keep each challenge time boxed; remember too that the timings stated are only a guide. It is likely that the learners will take longer in this chapter in the first sprint, but less time in subsequent sprints as they become accustomed to the course material.

8.1. Introduction

To recap from our first sprint, you’ve learned that the Product Owner (P.O.) represents the needs of the stakeholders and is responsible for creating and maintaining the Product Backlog. The P.O. defines the end-user requirements and works with the Development Team and Scrum Master to help capture these requirements as User Stories, prioritise and detail them, and break larger stories (Epics) into smaller actionable User Stories. This process of prioritising, detailing, and preparing User Stories for upcoming sprints is called Backlog Refinement.

During the Product Discovery phase, you already practised a form of backlog refinement (recap): you prioritised the top-priority MVP stories, wrote them clearly with descriptions and acceptance criteria, and made them ready for the first Sprint Planning. In this lesson, we will build on that knowledge and prepare for the next Sprint Planning meeting.

Agile ways of working encourage a mindset where change is expected and embraced. Backlog refinement is an ongoing activity to ensure the backlog stays relevant, prioritised, and ready for upcoming sprints.

Typically, backlog refinement takes place before each Sprint Planning meeting, often every two weeks, and lasts around 30 minutes. The P.O. may also refine the backlog at any time — for example, when new feedback comes in from customers or other stakeholders within the business.

The main goals of backlog refinement are to help you:

  1. Keep the product backlog prioritised so the most important items are at the top.
  2. Break large stories into smaller, more manageable pieces.
  3. Ensure top-priority stories are clearly defined, with actionable acceptance criteria, and are ready for Sprint Planning.

Backlog refinement meetings are usually run by the P.O., with support from the Scrum Master and at least one member of the Development Team. Not every team member needs to attend, but it is important to have someone technical present — such as a lead developer or architect to provide input on technical feasibility and help ensure stories are well-defined and ready for development.

Challenge

Challenge 1: Refine your Backlogs (5 minutes)

Goal: Ensure all current User Stories for existing personas are up-to-date, prioritised, and ready for Sprint Planning.

In your teams:

  1. Look through all existing User Stories in the product backlog (represented as a User Story Map) and see if you need to add any further ones based on what you now understand of the product, any challenges, or new requirements (e.g., clarifications or missing details in existing user journeys).
  2. Split large or unclear User Stories into smaller, actionable tasks.
  3. Make sure every User Story is correctly grouped under the right Epic.
  4. Reassess Priorities (Check whether priority levels need to change) and update MoSCoW labels accordingly:
    • This might be based on any User Stories that have been added.
    • It may be based on things you learnt during the previous Sprint.
    • It may be based on external factors or new risks that have been identified.
  5. For the top-priority User Stories, ensure details and acceptance criteria are added and clear.

Further Instructions

  • Entire Team: engage with your P.O. to confirm any changes in priorities or new demands, and refine your work accordingly.
  • Scrum Masters: ensure that all members of the team are involved.

Keep an eye on the MVP’s progress after each sprint

If the number of items is low and the team does not have enough work for the upcoming sprint, consider extending the scope by adding stories for another persona. Otherwise, this section given below can be skipped.

Callout

Keep an eye on the MVP’s progress after each sprint

If the number of items is low and the team does not have enough work for the upcoming sprint, consider extending the scope by adding stories for another persona. Otherwise, this section (6.2. Extending MVP Value Across Users) given below can be skipped.

8.2. Extending MVP Value Across Users

Throughout this course, your goal has been to work toward a Minimum Viable Product (MVP), also referred to as the first release — the smallest version of the product that still delivers real, usable value.

As a recap from the Product Discovery chapter, you created your product backlog (as a User Story Map) and developed your first release plan focused on your top-priority user identified in Challenge 2: Ranking the User Types / Personas for the required Product. The purpose of this was to help you deliver real, end-to-end value for that single user, allowing you to test assumptions and ensure the product works fully for that user before expanding to others.

In real-world projects, teams rarely have unlimited time, budget, or resources to satisfy every user at once. Agile encourages you to make strategic choices — deciding which user’s needs will deliver the most value first. This approach helps you focus limited resources where they’ll have the greatest impact.

Now, you’ll revisit your MVP and learn how to extend its value to additional essential users. A fully functional MVP must include the minimum features required for all essential users to make the system work end-to-end.

For example, a Rental Booking product can’t operate with only the guest’s features — it must also include the host’s basic functionality to complete the booking process.

In this section, you’ll expand your Product Backlog (using your User Story Map) to cover the next-highest-priority user. This exercise will help your MVP evolve into a more balanced, ecosystem-ready product that supports all key personas, while continuing to deliver value incrementally.

Challenge

Challenge 2: Extend and Refine Your Product Backlog and Release Plan for Other Personas (10 minutes)

In your teams:

  1. Review MVP Coverage

    • Ask: does the current MVP still support all essential users and complete the main user journeys?
    • Identify any missing interactions or dependencies that would prevent the MVP from functioning end-to-end.

  2. Decide Whether to Extend

  3. Prioritise New Stories

    • Apply MoSCoW labels to all new stories, organise them from high priority (Must-have) to low priority (Won’t-have), and decide which stories belong in the MVP.
    • For any stories added to the MVP, refine them by writing clear descriptions and acceptance criteria using the Gherkin syntax (Given / When / Then) (recap here) to prepare them for Sprint Planning.

Further Instructions

  • Entire Team: engage with your Facilitator (acting Product Owner) throughout the activity
  • Scrum Masters: ensure that all members of the team are involved
Callout

There are a number of terms used to mean Backlog Refinement.

Others are “Backlog Enhancement”, “Backlog Grooming” or “Backlog Pruning”.

Our Product Backlog is once more up to date with the latest set of requirements from the Stakeholder(s) broken down into User Stories. We are now ready to do the Sprint Planning meeting, where we will select the next subset of User Stories to go into the Sprint Backlog, and we can return to Chapter 4 to do this.

Key Points
  • Adding and prioritising User Stories is an ongoing task, known as Backlog Refinement. (AKA “Backlog Enhancement”, “Backlog Grooming” or “Backlog Pruning”.)
  • The Backlog needs to be fully refined and up-to-date before each Sprint Planning session begins.
  • The MVP should provide the minimum functionality needed to support all essential users, ensuring the product works as a complete system.