PMP · Question #720
A team is having a hard time completing work due to unclear requirements. They have not been able to complete an iteration successfully in several months. In order to help the team, what should the…
The correct answer is B. Recommend that the product owner reviews the backlog refinement processes. If an agile team struggles to complete iterations due to unclear requirements, the project leader should recommend that the product owner reviews and improves the backlog refinement processes.
Question
A team is having a hard time completing work due to unclear requirements. They have not been able to complete an iteration successfully in several months. In order to help the team, what should the project leader do?
Options
- ARecommend that the team reviews the length of the iteration with the stakeholders.
- BRecommend that the product owner reviews the backlog refinement processes.
- CRecommend limiting the work in progress to improve the team's focus.
- DRecommend a review of the team members' individual performances.
How the community answered
(48 responses)- A4% (2)
- B71% (34)
- C8% (4)
- D17% (8)
Why each option
If an agile team struggles to complete iterations due to unclear requirements, the project leader should recommend that the product owner reviews and improves the backlog refinement processes.
While iteration length can be adjusted, changing it will not resolve the fundamental issue of unclear requirements; it addresses capacity or timebox, not the quality of the work definition.
Unclear requirements are a direct indication of insufficient backlog refinement, which is a primary responsibility of the Product Owner. Improving this process ensures that user stories are well-defined, understood, and 'ready' for development before an iteration begins, enabling the team to complete work successfully.
Limiting Work in Progress (WIP) helps improve focus and flow, but it primarily optimizes throughput for *known* work. It does not address the root cause of 'unclear requirements' that prevent work from being completed in the first place.
Reviewing individual team member performance incorrectly assumes the issue lies with individual capabilities, whereas the problem is explicitly stated as 'unclear requirements,' which points to a process-level deficiency managed by the Product Owner.
Concept tested: Agile Methodologies, Product Owner Role
Source: https://scrumguides.org/scrum-guide.html#product-backlog-refinement
Topics
Community Discussion
10B is correct. The root cause here is unclear requirements, which points directly to a backlog refinement gap rather than a team execution problem. If the product owner is not providing well-defined, ready work items, the entire delivery pipeline suffers and no iteration will succeed regardless of team effort. A and C are useful tactical levers, but they do not address the benefits realization breakdown at the source. D is a trap because it shifts blame to individuals when the governance failure sits upstream with product ownership.
Agree on B but watch your clock here, this is a 30-second pick if you catch the "ready work items" keyword, not a question to overthink with root cause analysis paragraphs.
Think of it like a chef trying to cook from a recipe book where half the ingredients and steps are smudged out, so you fix the cookbook itself rather than just telling the cooks to work faster. In Scrum terms, unclear requirements point straight to backlog refinement with the product owner, which is why B is correct. Does anyone know if the exam expects you to assume the product owner is already refining the backlog poorly, or is it just testing whether you know the PO owns that process?
Good analogy Mateus, and to your question the exam is really testing whether you recognize that backlog refinement is an ongoing collaboration between the PO and the Developers, not a solo PO activity, so if items are smudged the fix is the team refining together rather than the PO working in isolation.
B is the right call here. When requirements keep coming in fuzzy, the backlog refinement step is usually where things break down. Has anyone tried simulating this in a practice sprint at home, where you intentionally skip refinement for one iteration and do it properly the next, just to feel the difference in team velocity?
Good call on backlog refinement, Ola B., but I would add one nitpick: the real damage shows up not in velocity but in sprint commitment failures, because velocity often looks fine early since people are heads-down spinning on unclear stories instead of flagging the fog.
B is the quick win here. When requirements are unclear and iterations keep failing, that points straight back to backlog refinement being broken, so have the PO fix that process. Option C is a classic time sink trap because WIP limits help with focus but will not magically clarify vague requirements. One thing I am still fuzzy on: in the real exam do they expect you to assume the PO owns refinement end to end, or is the Scrum Master also on the hook for facilitating those sessions?
Think of the PO as the farmer who decides which seeds get planted and in what order, while the Scrum Master is the farmhand who makes sure the soil is actually tilled and the rows are straight, so the PO owns what gets refined but the SM owns making sure the refinement session itself actually runs well.
Going with A. If the team has not successfully completed an iteration in months, the iteration length itself may be the problem and the conversation with stakeholders about whether the cadence is realistic is the right empirical first step before anything else.
B is correct here because a team that has not successfully completed an iteration in months is fundamentally struggling with scope and flow within the iteration boundary, so reducing the iteration length forces smaller increments, faster feedback loops, and earlier value realization rather than extending a cadence that is already failing to deliver.