PMP · Question #459
During a retrospective meeting a project manager hears that stakeholders have been constantly complaining at iteration demos about product features not being delivered as requested. What advice…
The correct answer is B. Validate acceptance criteria with stakeholders prior to backlog refinement. Stakeholders are consistently dissatisfied with delivered features during iteration demos, indicating a misalignment between their expectations and the product owner's understanding of requirements. The project manager should advise the product owner to validate acceptance…
Question
During a retrospective meeting a project manager hears that stakeholders have been constantly complaining at iteration demos about product features not being delivered as requested. What advice should the project manager give to the Product owner to ensure that product features are always delivered as requested?
Options
- AInclude stakeholders during daily standup meetings to monitor progress
- BValidate acceptance criteria with stakeholders prior to backlog refinement
- CAvoid including stakeholders in iteration reviews
- DCreate a requirements traceability matrix and distribute it accordingly
How the community answered
(57 responses)- A14% (8)
- B74% (42)
- C9% (5)
- D4% (2)
Why each option
Stakeholders are consistently dissatisfied with delivered features during iteration demos, indicating a misalignment between their expectations and the product owner's understanding of requirements. The project manager should advise the product owner to validate acceptance criteria with stakeholders early.
Including stakeholders in daily standups can disrupt the team's internal synchronization and is generally not recommended for external monitoring; it doesn't solve the problem of misaligned requirements.
The root cause of features not being delivered as requested often lies in unclear or unvalidated requirements and acceptance criteria. By validating acceptance criteria with stakeholders *before* backlog refinement, the Product Owner ensures a shared understanding of "done" for each feature, reducing discrepancies and improving satisfaction at iteration demos.
Avoiding stakeholders in iteration reviews is counterproductive as these events are crucial for transparency, feedback, and validating that the product meets their needs.
A requirements traceability matrix tracks requirements but doesn't inherently ensure they are correctly understood or reflect stakeholder desires if the initial acceptance criteria are flawed.
Concept tested: Agile requirements validation and backlog refinement
Source: https://www.scrum.org/resources/what-is-product-owner
Topics
Community Discussion
4
Yusuf A.Jul 3, 2026B is the right call here. One of the senior PMs at my company told me the trick is that "as requested" language almost always points back to acceptance criteria, so validating those with stakeholders early is what prevents surprises at the demo. If you wait until the iteration review to find out people expected something different, the work is already done. A sounds tempting but standups are for the dev team, not stakeholder status updates, and D is really a plan-driven artifact that does not fit this agile scenario.
Nina C.Jun 7, 2026B. A trips people up but standups are for devs, not stakeholder demos.
Ola B.Jun 21, 2026Going with D here. A requirements traceability matrix gives you that visible thread from each requested feature all the way through to delivery, so when stakeholders show up at the demo nobody is surprised about what got built. I actually spun up a quick template in a sandbox project last month and walked through it with stakeholders mid-iteration, and the griping at demos dropped to almost zero because everything was tracked and signed off in writing. B sounds agile-friendly but validating acceptance criteria only at backlog refinement is too early and too far upstream to catch the drift that happens during the actual build.
Yusuf A.Jun 22, 2026Actually B is correct here, and the key is that validating acceptance criteria during the build keeps you connected to what actually gets delivered, not just what got requested up front. One of the seniors on my team showed me how drift happens during implementation, so catching it mid-build is exactly the point.