5 exercises — gather, capture, and respond to sprint review feedback professionally.
0 / 10 completed
1 / 10
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 / 10
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 / 10
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 / 10
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 / 10
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."
6 / 10
During the sprint demo, Sarah (the UX designer) points out that the button styling isn't consistent with the rest of the application. You're leading a code review discussion. Which statement best focuses the team on resolving this issue?
Insufficient is too vague and doesn't offer a clear direction. The best response immediately establishes the priority of UI consistency, aligning with good design practices. Option 3 encourages further investigation, while option 4 deflects responsibility to a later stage – both are less effective than proactively setting expectations.
7 / 10
After the demo, Mark (the Sales Lead) sends you a Slack message: 'This looks great for internal demos, but I'm worried about how it will translate to our client presentations. The data visualizations are too complex.' What's the most appropriate response?
Insufficient offers a superficial fix. Mark's concern highlights a critical difference between internal and external usage; scheduling a follow-up demonstrates proactive engagement and addresses the underlying issue of client comprehension. Options 3 and 4 dismiss or misinterpret Mark's feedback.
8 / 10
You're writing a Pull Request description for a new feature that allows users to export data. The description should clearly communicate the functionality and its intended use. Which of these is the MOST effective?
Insufficient is simply stating the obvious. The best description provides specific details about the functionality (export button and CSV files) and clarifies its purpose (containing all user data). Option 3 lacks detail, while option 4 focuses on a bug fix rather than the feature itself.
9 / 10
During the daily standup, David says, 'I'm blocked because I need more context about the API endpoint for user authentication. The documentation is unclear.' How should you respond to help him proceed?
Insufficient is unhelpful and dismissive. Offering to investigate the documentation *with* David demonstrates support and collaboration. Options 3 and 4 are unproductive and reflect poorly on teamwork. A good developer provides assistance when a team member needs it.
10 / 10
The Product Owner says: 'This dashboard is fantastic for internal reporting! However, our marketing team wants to add some custom branding elements—like their logo and color palette. It's not in the original scope, but it would significantly improve engagement.' How do you respond?
Insufficient is a closed-off response that doesn't explore potential value. The best approach involves actively seeking requirements and assessing alignment with the product strategy—demonstrating a collaborative and strategic mindset. Options 3 and 4 are too simplistic and don't address the broader implications.
What will I learn from the "Demo Feedback Language — Sprint Demo Exercises" exercise?
Practice gathering and responding to sprint review feedback: 'what did you think of', 'is this what you expected', 'noted — we'll adjust', and capturing new requirements during demos. 5 exercises.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall required.
How many questions are in this exercise?
This set contains 10 multiple-choice questions, each with a detailed explanation shown after you answer.
Do I need to create an account to track my progress?
No account is required. Your progress bar and score reset each time you reload the page, but you can retry the exercise as many times as you like.
Who is this Sprint Demo & Releases exercise for?
This exercise is built for IT professionals and non-native English speakers who need to read, write, and discuss sprint demo & releases topics confidently at work.
What happens if I answer a question incorrectly?
You will see the correct answer highlighted along with a detailed explanation of why it is correct -- so every wrong answer becomes a learning moment, not just a lost point.
Can I retry this exercise?
Yes -- click "Try again" on the results screen at any time to reset your score and go through all the questions again.
How long does this exercise take to complete?
Most learners finish all 10 questions in under 10 minutes, since each question is answered by clicking a single option.
Where can I find more Sprint Demo & Releases exercises?
See the full Sprint Demo & Releases exercises hub for more vocabulary drills on this topic.
Is this exercise mobile-friendly?
Yes -- the exercise works on any device with a modern browser, including phones and tablets, with no app download required.