Backlog Refinement
Backlog refinement is the continuous activity that splits items into smaller items and adds the detail a team needs to finish them within one iteration. It is usually run in preparation for a planning workshop: the product owner, members of the team and the stakeholders concerned review the items at the top, clarify the need, split what is too big, add acceptance criteria and check the result against the Definition of Ready, the criteria the team has set itself for holding an item ready. Refining an item is finished once the team has enough information to execute it. The backlog thus keeps its detail graded: precise and split at the top, broad and rough at the bottom.
Goal
Backlog refinement gives items enough detail and clarity for the delivery team to finish a batch of them within one iteration. It answers an asymmetry: an item enters the backlog as a broad need, worded by someone who will not do the work, and it has to leave in a form a team executes without reopening the discussion.
The output of the activity is a set of items ready for the next iteration and a shared understanding, inside the team, of what each one asks for. The Agile Extension to the BABOK Guide adds a second effect: the session gives the team a view of what is expected next for the solution.
The Scrum Guide defines the act directly: "Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items." It describes it as an ongoing activity that adds details such as a description, order and size. The same act still circulates under its former name, backlog grooming, in teams and in tools.
The boundary with backlog management
Backlog management holds the list itself, from an item's entry to its exit, and answers for its order over time. Refinement works the content of the items that order has put on top; the Agile Extension also lists, among its activities, the review of priorities and the removal of items that have become unnecessary, the point where the two techniques overlap. Downstream, the planning workshop picks, among the ready items, the ones the team commits to deliver over the period.
The three often run in the same week and sometimes in the same room, which does not make them interchangeable. With no order there is no top of the list to refine, and with no ready items the planning session turns into a refinement session, with the whole team tied up for work three people would have done.
Usage
When to use it
- An iteration opening in a few days: prepare the items at the top before the planning workshop.
- A team working in continuous flow: refine each item as it arrives.
- An item too big for one iteration: split it into items that can be delivered separately, each carrying value.
- Field feedback on a delivered feature: revisit the wording and the priority of the items it touches.
- Open questions on a priority item: raise them early enough for the product owner to answer before execution.
When not to use it
- An unordered backlog: start with backlog management.
- An unstable vision and roadmap: the detail is redone before it has served, so stabilise the product intent first.
Description
Detail is graded down the list
The detail of a backlog is uneven by construction. The items at the top are sized for the coming iteration and carry enough detail to be finished; those at the bottom stay big and rough. Refinement acts on that grading: each pass adds one notch of precision to the items approaching the top.
The Agile Extension states the limit. Refining a story before it is needed may cause rework. An item only needs to be ready when it is about to enter development, immediately or in the near future.
↩ Field feedback: rejoins the bottom of the backlog
The four elements
The backlog is the ordered list of the features, requirements and work needed for the expected outcomes of the solution. Refinement keeps it relevant and current for the team.
The backlog item carries one or more requirements. It most often takes the form of a user story, sometimes of a job story or of a mock-up. Splitting aims at items that satisfy the INVEST criteria, the quality test for a user story.
The refinement meeting reviews the items at the top of the backlog. It has no standard format and is most often led by the product owner or by a customer representative. It ends on the confirmation that the top items are ready for the next iteration and the list of what remains to be clarified. The Agile Extension also allows the informal route, refinement happening in the course of the work.
The Definition of Ready is the set of criteria the team agrees to satisfy before holding an item ready. A team starting out can settle for the agreement of a critical mass of its members; criteria are added later, as it draws the lessons of what has blocked it. The term belongs to the Agile Extension; the Scrum Guide does not name it.
The cadence follows the team's
At the head of its limitations the Agile Extension puts refinement whose rhythm does not follow the team's. The rule it gives: the frequency of refinement follows the frequency at which the team reviews its backlog.
| Way of working | Backlog review rhythm | When refinement happens |
|---|---|---|
| Continuous flow | Daily. | On every item entering the backlog. |
| Iterations | At every iteration. | A few days before the planning session. |
What makes refinement fail
The three-person session
Refinement is usually done by a few members of the team, and the Agile Extension names the cost: the point of view of those who do not take part is set aside without anyone having decided it. The absent developer is the one who knew about the dependency on a third-party service, and it resurfaces in the middle of the sprint. The counter is rotating the participants and a short report-back in the planning session, where the item meets the whole team before any commitment.
Refining too far ahead
Going down the backlog to get ahead is the reflex of a conscientious team. The detail produced does not survive the feedback that arrives before the item comes back up, and the next session rediscusses an item somebody believes already settled.
The Definition of Ready that keeps growing
A list of criteria that lengthens after every incident ends up ruling out items the team would have known how to build. The Agile Extension attaches those criteria to the team and to its progress: the team sets them, the team revises them. A criterion that has never prevented a blockage is removed the way it was added.
The session that drifts into design
An item at the top calls for business answers: which threshold, which channel, which exception case. When the room switches to implementation, the product owner has nothing left to arbitrate and the session consumes several developers' time for a discussion that belongs inside the sprint.
AI considerations
A language model reads the backlog and flags what a human review takes time to find: the items whose description does not allow the work to be started, those that overlap, those depending on an item still low in the list. On a designated item it proposes candidate splits and drafts acceptance criteria in the format the team uses. It checks the top items against the written Definition of Ready and returns the list of what is missing, item by item.
It does not take the decision that makes an item executable. The threshold chosen, the channel selected, the treatment of foreign-currency accounts follow from no corpus: they are asked of the product owner and of compliance. Pressed to decide, a model produces a plausible answer the team will implement in good faith. The passage before the Definition of Ready belongs to the team that executes, since ready means ready for them. A backlog carries customer segments, amounts and regulatory constraints that are stripped out before anything is sent to a public model.
Examples
A team at a retail bank in French-speaking Switzerland delivers in two-week sprints on its online banking application. Three days before the planning workshop, the refinement meeting takes the item that the last reordering put at the top:
"As a customer, I want to be alerted when my balance drops below CHF 1'000, so that I can head off an overdraft."
Three questions make it impossible to execute as it stands: the channel of the alert, the fixed or adjustable threshold and the treatment of foreign-currency accounts. The product owner decides in the session; the team splits the item into three, attaches its acceptance criteria to each one and checks it against the Definition of Ready.
| Item from the split | Acceptance criteria | Definition of Ready |
|---|---|---|
| Push notification when the balance drops below CHF 1'000, fixed threshold | The alert goes out within 60 seconds of the entry being posted. At most one alert per day and per account. | Mock-up attached, dependency on the notification service confirmed, size compatible with a sprint: ready. |
| Threshold adjustable by the customer in the application settings | The customer enters an amount between CHF 0 and CHF 10'000. The default value stays CHF 1'000. | Mock-up attached, settings screen already in place, size compatible with a sprint: ready. |
| SMS fallback for customers without the mobile application | The SMS goes out if the customer has not enabled push notifications. The text mentions no amount. | Cost per SMS and operator contract still to be confirmed: pending, the item stays in the backlog. |
The product owner rules foreign-currency accounts out of the release and no item is created. The items further down the backlog were not touched during the session.
Visualisations
The refinement funnel is the drawing that carries the technique. The backlog reads from the bottom up: broad, rough items at the bottom, a refinement-meeting floor in the middle where they are split, detailed and given acceptance criteria, small and precise items at the top. A line marks the Definition of Ready and the crossing into the planning workshop, the only place in the drawing where an item leaves the backlog.
Cost
| Phase | Level | Justification |
|---|---|---|
| Preparation | Low | The material is the backlog itself. What remains is choosing the items to review and gathering the people who can answer the questions. |
| Execution | Medium | The session ties up the product owner and part of the team for a few hours per iteration. The outlay comes back every cycle. |
| Documentation | Low | The result lives in the backlog tool: revised description, acceptance criteria, items from the split. |
Tooling
Backlog tools (Jira, Azure DevOps, GitLab and their equivalents) carry the activity itself: a hierarchy of items, the split of one item into linked items, a dedicated field for acceptance criteria, an item template that carries the Definition of Ready as a checklist. They also date the last change, the only information that tells a refined item apart from one that has been waiting for six months.
Collaborative whiteboards (Miro, Mural, FigJam and their equivalents) serve the splitting of a big item: moving cards brings the slices out faster than the list view of a backlog tool. The result then goes back into the tool, the only place where it survives the week; a wall and cards do the same job for a co-located team refining in a short slot, on the same condition.
Video conferencing with screen sharing holds the session remotely, provided that the shared screen is the backlog tool and that the changes are made in it during the discussion.
Sources
- IIBA, Agile Extension to the BABOK Guide, §7.1 Backlog Refinement: the purpose of the technique, its continuous character and its place in preparation for a planning workshop, the elaboration and story-splitting activities, the split towards items satisfying the INVEST criteria, the four elements, backlog, backlog item, refinement meeting and Definition of Ready, together with the strengths and limitations stated, among them the misaligned cadence and participation restricted to a few members.
- IIBA, Agile Extension to the BABOK Guide, §6.3.1 and §6.3.2, the Delivery horizon: a story only needs to be ready when it is about to enter development, refining it earlier may cause rework and refinement is conducted either in a meeting or in the course of the work.
- Ken Schwaber and Jeff Sutherland, The Scrum Guide (November 2020), "Product Backlog" section: the act defined as breaking down Product Backlog items into smaller and more precise items, described as an ongoing activity that adds details such as a description, order and size.