Project Management

Please login or join to subscribe to this thread

Confusing Agile Scenario: Responding to "No Value" Feedback

linkedin twitter facebook   Agile  
avatar
beatriz del pilar colon None miami, FL, United States

Hi everyone,



I'm working through some practice scenarios and have come across one that is causing a lot of debate. I'd love to get this group's expert opinion.



(To respect copyright, I have completely rephrased the scenario and options.)



 


The Scenario

 



An agile project is underway to create a new system that will automate a currently manual process. During a sprint demo (iteration review), the key business stakeholders review the increment and express a serious concern, stating that they "would not gain any value" from the system as it has been presented.



Question: What is the project manager's immediate next action?



 


The Conflicting Options

 



The debate comes down to two primary actions:



Option A: Discuss this feedback with the product manager (I am assuming they are referring to product owner) to analyze the concern and determine how to adapt the backlog (e.g., identify new user stories).



Option D: Review the established performance metrics with the stakeholders to ensure the system accomplished the agreed-upon metrics.



The "official" answer I've seen for this is Option D. However, this seems counter-intuitive to me, and I've seen strong arguments for Option A.


 

 


The Case FOR Option D (Reviewing Metrics First)

 



The rationale for choosing D as the first step is based on a few points:



"No value" is too vague. Before jumping to solutions (like new user stories), the PM must first investigate and understand the specifics of the stakeholders' concern.



The "agreed-upon metrics" are the project's objective language for defining value. Reviewing these metrics with the stakeholder is the most direct, data-driven way to start the root cause analysis.



For example, the stakeholders might be feeling it has no value, but the metrics (e.g., "manual task time reduced from 5 min to 1 min") might prove the value is there. This helps pinpoint if the issue is a misunderstanding, a failure of the demo, or a genuine gap.



It is considered premature to involve the Product Owner (Option A) without first understanding the root cause. The PM should diagnose the problem with the stakeholder first, then go to the PO with a clear, data-backed problem to solve.


 

 


The Case FOR Option A (Discussing with Product Manager First)

 



The arguments against D and in favor of A are also very strong:



The "Metrics" Trap: The term "performance metrics" in an agile context (especially during a demo) is ambiguous.



If it means team metrics (like velocity or burndown), reviewing them is defensive and irrelevant to a product value complaint.



If it means business value metrics (like ROI or customer adoption), those are lagging indicators that are impossible to measure for a new system during a demo.



The Event Context: This is a sprint demo. The entire purpose of this event is for stakeholders to give this exact kind of qualitative feedback to the team and the Product Owner (who should be present).



The Agile Role: The Product Owner is the single person accountable for product value and direction. The PM's role as a facilitator is to ensure this critical feedback loop is closed immediately. The PM's first step should be to engage the PO (who is accountable) rather than starting an independent investigation (Option D).



Option A ("Discuss with the product manager") is the start of the root cause analysis, but it places the accountability with the correct agile role.


 

 


My Question for the Group

 



So, what is the immediate next step for the PM?



Is it to (D) start a data-driven investigation with the stakeholder using the metrics as a baseline?



Or is it to (A) ensure this critical feedback on value is immediately handed to the Product Owner, who is ultimately accountable for it?



I feel like I'm missing a key piece of context or a specific PMI definition of "metrics" in this situation. Any insights you all have would be incredibly helpful!



Thanks!
Sort By:
avatar
Kiron Bondale Retired | Mentor| Retired Welland, Ontario, Canada
Beatriz -

Unfortunately this is one of the cases where there is insufficient context to conclusively pick the correct answer. If we assume that the metrics related to the expected improvement in efficiency of the process by being automated then this could be a case where even though the expected performance was achieved, the stakeholder now feel that a higher level of performance is needed (based on changes in the external environment) to make the investment in the project worthwhile. That assumption could only be validated by reviewing their concerns with the PO.

Kiron
avatar
Luis Branco CEO| Business Insight, Consultores de Gestão, Ldª Carcavelos, Lisboa, Portugal

This is an excellent and nuanced discussion, and one that highlights the ongoing tension between measuring value and creating value in agile delivery.

Both Option A and Option D can be valid actions, but not necessarily in the same sequence of intent.

The key lies in understanding who owns what and what the moment requires.

1. Clarify the Event Context

During a Sprint Review, the purpose is not to defend performance but to inspect and adapt the product. Stakeholder feedback, even if vague (“no value”), is a signal for conversation, not confrontation.

The immediate facilitator of that loop is the Product Owner, not the PM.

So, engaging the PO first (Option A) honors agile accountability.

2. Diagnose Through Evidence, but With the Right Timing

Once the PO and team acknowledge the feedback, then metrics can be used to explore causes.

Data should serve reflection, not deflection.

Reviewing agreed-upon metrics too early risks turning a learning moment into a debate.

3. Integrate Both Views

A regenerative approach would merge both options in sequence:

  • Engage the Product Owner to align on intent and perception.
  • Collaborate with stakeholders to examine objective indicators (metrics) and uncover the gap between perceived and demonstrated value.

That order preserves trust, reinforces agile roles, and ensures that data supports dialogue, not the other way around.

In short:

The best first step is relational (Option A), and the best next step is analytical (Option D).

Value conversations start with empathy, and mature with evidence.
avatar
Fabian Crosa
Community Champion
PMO Leader | Speaker & Mentor | Content Leader – PMOGA Latin America Hub| Catholic University of Uruguay Montevideo, Montevideo, Uruguay
Hi Beatriz,
Very good scenario
I would lean towards option A.
In an agile environment, the first thing to do is to involve the Product Owner, who manages the value of the product and channels that feedback into the backlog.
Metrics help later, but the conversation about value starts with people. 💬
avatar
Ashwin Kumar H M
Community Champion
Consultant| Canarys Automation Ltd Bangalore, Karnataka, India
Great question—and your confusion is valid. From a PMI exam perspective, Option D is the better first step because the stakeholder feedback (“no value”) is vague, and PMI expects the PM to clarify and validate value using agreed-upon business or outcome metrics before taking action. This helps determine whether the issue is a misunderstanding, a demo gap, or a real value shortfall. While Option A (engaging the Product Owner) is what many Agile practitioners would naturally do in real life—and would likely follow next—PMI emphasizes diagnosis before adaptation. So the key is interpreting “metrics” as value criteria, not team metrics, and recognizing that Option D enables a focused, fact-based conversation before backlog changes are discussed.
avatar
Melvin Noche Functional Manager| Google Sunnyvale, Ca, United States
Hi Beatriz, this is an excellent question, and you are not missing anything obvious. This scenario is confusing because it sits right at the intersection of PMI exam logic, Agile roles, and real-world instincts, which do not always line up cleanly.

From a PMI exam perspective, the key is to anchor on intent and sequencing, not on what feels most collaborative or efficient in practice.

When stakeholders say “this provides no value” during a sprint review, PMI treats that statement as ambiguous feedback, not yet a validated problem. Before the PM facilitates solutioning or backlog changes, the PM’s first responsibility is to clarify what “value” means in objective terms that were already agreed upon.

That is why the official answer often points to reviewing the agreed-upon metrics first.
In PMI’s worldview, those metrics represent the shared definition of value between stakeholders and the team. The PM is expected to ground the conversation there to determine whether the issue is:
  • a perception gap,
  • a demo or communication issue,
  • or a genuine value gap that requires backlog adaptation.
Only after that clarification does it become appropriate to engage the Product Owner to adjust the backlog. Going straight to the PO without first clarifying the concern can be interpreted, in exam terms, as skipping diagnosis and jumping to solutioning, even though that is very common in real Agile teams.
Your instincts about the “metrics trap” are also valid. PMI is not referring to team performance metrics like velocity or burndown, nor to lagging ROI measures. The intent is closer to leading indicators tied to the original business case or success criteria, even if they are qualitative or proxy-based at this stage.
So if you had to summarize the PMI logic in one line, it would be:

The PM first clarifies and validates the value concern using the agreed success criteria, then ensures the Product Owner takes ownership of adapting the product direction.

This kind of question is a great example of how the PMP exam tests order of thinking, not just Agile correctness. It is also why many candidates struggle despite knowing Agile well, because the exam rewards PMI’s decision logic over real-world shortcuts.

Scenarios like this are exactly what mindset-driven practice tools focus on. Platforms like PM Mindset Builder spend a lot of time breaking down these “why this first, not that” decisions, which helps resolve debates like this much faster.

Really strong analysis on your part, and this is the right kind of question to be asking if you are aiming to think the way the exam expects.

Please login or join to reply

Content ID:
ADVERTISEMENTS
ADVERTISEMENT

Sponsors







Vendor Events

See all Vendor Events

Newsletters

Jun 3: The Career Problem Facing New PMs
May 20: Your PM Career as a Project Life Cycle
May 13: The Big Lie After Layoffs

See all newsletters