5 exercises — gather, capture, and respond to sprint review feedback professionally.
0 / 5 completed
1 / 5
After demonstrating a new onboarding flow, you want to invite honest stakeholder feedback. Which phrase opens the most productive conversation?
"What did you think of..." combined with a reference anchor is the most effective feedback invitation in sprint reviews.
Why Option B works: 1. "What did you think of [specific thing]" — focused on a concrete item, not vague impressions 2. "Does it match what you had in mind" — anchors feedback in the original requirement 3. This framing invites gap analysis, not just sentiment — stakeholders think "does this match the spec?" not just "do I like it?"
Why "Did you like it?" is weak: It invites a yes/no answer and puts stakeholders in an awkward position if they have concerns. People are less likely to give critical feedback when asked "did you like it?"
Better feedback invitation phrases: • "What did you think of the [feature name]?" • "Is this what you were expecting to see?" • "Does this address the problem you described in planning?" • "What would make this more useful for your team?"
Never say "we worked really hard on it": Effort claims before feedback make stakeholders feel guilty about giving honest criticism. They'll soften their feedback to protect your feelings — which hurts the product.
2 / 5
A product owner says "This is almost right, but the filter should stay visible after the user selects an option — right now it disappears." How do you respond in the sprint review?
"Noted — we'll adjust" is the gold-standard sprint review feedback acknowledgement phrase.
Why Option B is complete: 1. "Noted" — acknowledges the feedback immediately without defensiveness 2. "We'll adjust" — commits to action without over-promising scope 3. "Our interpretation of the story" — owns the gap without blaming the PO for unclear requirements 4. "This is clear" — validates that the new direction is understood 5. "I'll update the ticket" — shows it won't get lost 6. "Or sooner if blocking" — demonstrates business awareness
Why "that's not in the acceptance criteria" fails: Even if true, this response is adversarial. It creates a conflict over who is "right" rather than solving the problem. In sprint review, the goal is alignment — not defending your implementation.
Key phrases for receiving sprint review feedback: • "Noted — we'll adjust." • "Good catch — I'll add that to the ticket." • "That's a fair point — let me capture that." • "Understood — I'll update the acceptance criteria and we can revisit in the next sprint."
3 / 5
You want to check whether the stakeholder's expectation was met — not just whether they like the feature. Which question is most useful?
"Is this what you expected to see?" is the correct expectation-checking question in sprint reviews.
Why phrasing matters:
Option A ("Was it what you expected?"): Grammatically slightly awkward in British English for software demos; also uses past tense which distances from the current screen.
Option B ("Is this what you expected to see?"): Present tense, refers to what's on the screen right now, clear yes/no anchor with room to expand. The correct choice.
Option C ("We're all aligned, right?"): A loaded question — it pressures stakeholders to agree. People will often say yes even when they have concerns, to avoid conflict.
Option D ("You expected something different"): Leading and slightly accusatory. Don't put words in stakeholders' mouths.
Expectation-checking patterns: • "Is this what you expected to see?" • "Does this match the outcome you described in the kick-off?" • "Is this the direction you had in mind?" • "How does this compare to what you were expecting?"
Follow-up if the answer is "no": "Tell me more about what you were expecting — that'll help us understand the gap."
4 / 5
A stakeholder gives a lot of verbal feedback during the demo. You want to make sure nothing gets lost. What do you say?
Option C demonstrates live feedback capture — a critical sprint review skill.
What makes Option C effective: 1. Reads back what you captured — "three items: X, Y, Z" — confirms accuracy in real time 2. Commits to a specific action — "follow-up comment on the ticket" — not "I'll note it somewhere" 3. Gives a timeframe — "after the call" — immediate, not "eventually" 4. Checks for completeness — "Does that cover everything?" — invites the stakeholder to add missing items
Why "I'll try to remember" fails: It signals that feedback might get lost. Stakeholders who don't trust their feedback will be captured tend to repeat it, interrupt, or escalate.
Live capture techniques: • Keep a notes doc open during demos • Say items aloud as you write them — this confirms accuracy • Use numbered lists: "That's item 1... and item 2 is..." • End with a check: "Does that capture everything?"
Where to log sprint review feedback: Jira ticket comments (preferred), Confluence meeting notes, or a Slack thread pinned to the sprint channel — not personal notes that only you can see.
5 / 5
The PO says "This is great overall, but I think the colour scheme feels off — can we change it to match our brand guidelines?" This is a new request, not in the sprint scope. How do you handle it?
Option C shows how to handle new requirements triggered by demos — a very common sprint review scenario.
The pattern: acknowledge → log → defer → confirm 1. Acknowledge — "Good feedback on the colour scheme" — not "that's out of scope" 2. Log it formally — "I'll log that as a new story" — makes it real and trackable 3. Be honest about scope — "not in the current sprint scope" — factual, not defensive 4. Propose a path — "prioritisation for Sprint 16" — don't just say no, give an alternative 5. Confirm — "Does that work?" — gets explicit agreement
Why "out of scope" as a first response fails: It sounds dismissive. Even if technically correct, it creates friction. Always acknowledge the feedback as valid before discussing scope boundaries.
Why "we'll do it now" fails: It sets a precedent that sprint scope is negotiable mid-sprint. This erodes sprint planning credibility and creates unpredictable workloads.
Sprint review new-request phrases: • "Great input — let me create a story for that." • "That's worth capturing — I'll add it to the backlog." • "Noted as a new requirement — we'll bring it to backlog refinement."