Turning Sprint Review feedback into backlog changes

A Sprint Review can go well and change nothing. Stakeholders are positive, the team feels appreciated, a few ideas are tossed around, and two weeks later nobody can say which of them arrived in the backlog. The event has served as a performance. The Guide intends something else, and the difference is a small amount of discipline before, during and after the meeting.

What the Guide intends

The Sprint Review's purpose is to inspect the outcome of the Sprint and determine future adaptations. During the event the team and stakeholders review what was accomplished and what has changed in their environment, and based on this information attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Guide stresses that the Review is a working session and not a presentation.

Two sentences in the Guide shape how feedback should be handled. The Product Owner is accountable for the Product Backlog, and the decisions they make are visible in its content and ordering. And those wanting to change the Product Backlog can do so by trying to convince the Product Owner. So feedback is an input, not an order. It reaches the backlog through the Product Owner's judgement.

The SBOK® Guide describes the output of its Demonstrate and Validate Sprint process as accepted and rejected user stories, updated risks and an updated release planning schedule, and says business stakeholder feedback is an important input to future Sprints. The Agile Manifesto principle of welcoming changing requirements, even late, is the reason the whole mechanism exists.

Five kinds of feedback

Sorting what people say makes decisions quicker. A comment in a Review usually falls into one of five kinds.

A defect or a miss. The Increment does not do what it should. This returns to the backlog as a fix, and the question is its priority and whether the Definition of Done missed it.

A refinement. The feature works but could be better: clearer wording, a different order of steps. It becomes a new or changed item, ordered by value.

A new need. Something the team had not considered. It needs a short conversation to understand the outcome before it is written down as an item.

A change of priority. A stakeholder says something else matters more now, because of an external event. This may reorder the backlog, and might affect the Product Goal.

An opinion or preference. "I would prefer green." Capture it, thank the person, and treat it as low-priority information unless several people say it.

Capturing the need behind the comment is usually more useful than recording the words. "Make the button bigger" might mean the button is hard to find on a phone.

A routine in four steps

1. Capture during the event. Someone other than the presenter takes notes, ideally on the shared Product Backlog itself, so each comment sits beside an item. The Scrum Master can ensure this happens. Keep to the stakeholder's words and add the underlying need afterwards.
2. Sort in the last ten minutes. Walk through the notes and tag each as one of the five kinds. Ask the stakeholders who raised them whether you understood.
3. Decide what you can, in the room. The Product Owner can say "yes, I will add it and put it above the reporting work", or "not now, and here is what would change that". Decisions made in front of stakeholders are trusted, and they save follow-up meetings. Decisions that need more thought are marked with a date. See how a Product Owner says no.
4. Close the loop. Within a day, send a short note to attendees listing what was added, what was parked and why. Next Review, show them the result.

A worked example

This is an illustrative case. A team has built a new reporting page and shows it at the Review. Six stakeholders attend. Notes taken on a shared backlog include:

• "The export is slow." (A defect.)
• "Can we filter by team?" (A refinement.)
• "We need a monthly summary email for directors." (A new need.)
• "Our audit is moving up; compliance reports are now urgent." (A change of priority.)
• "I'd like the chart in blue." (A preference.)

In the last ten minutes, the Product Owner sorts them. The export is slow: she adds a defect with a measurable target and puts it near the top. The team filter goes in as a small item for the next Sprint. The monthly summary email needs more thought, so she asks the requester for ten minutes the next day to understand the outcome. The audit change matters: she asks the compliance lead to confirm the date, reorders the top of the backlog on the spot and says that the Sprint Goal for the next Sprint will change. The blue chart goes in as a note.

The next morning, she sends a six-line note. Two weeks later, at the next Review, the team opens by showing the faster export and the team filter, and one stakeholder says it is the first time her comment has ever turned into a visible change. That experience, repeated, is what makes stakeholders keep coming.

What gets in the way

• Nobody records feedback. It exists only in people's memories and is gone by the weekend.
• Everything is accepted. The backlog fills with items without reasons, and the Product Owner stops being the one who orders it.
• Nothing is accepted. Stakeholders learn that their input is ceremonial.
• Decisions happen in side conversations. The sponsor tells a Developer after the meeting. The Product Owner then finds out later, and transparency is lost.
• The Definition of Done is not revisited. A defect found at the Review is a signal about the Definition of Done. Discuss it in the Retrospective.
• Feedback is treated as a promise. Say "I will consider it and tell you by Friday", not "we'll do it".

Feedback during the Sprint

The Guide notes that an Increment may be delivered to stakeholders before the end of the Sprint, and that the Review should never be a gate to releasing value. This means feedback can arrive earlier. A team that shows a stakeholder a working piece mid-Sprint can adjust within the Sprint, with the Product Owner renegotiating scope without endangering the Sprint Goal. The Review then collects the summary and the larger picture.

How to practise it

At your next Review, give one person the job of recording each comment against the backlog, and send the follow-up note the next day. In the simulator the Review at step 4.1 collects stakeholder feedback, and your response to it shapes the backlog that follows.