PMP · Question #712
During the third iteration of a project, the product owner requests another mandatory feature. This also happened in the previous two sprints, which resulted in failure and caused frustration within t
The correct answer is B. Ask the product owner to prioritize the backlog with the project team. Backlog management is a shared responsibility. The product owner should prioritize the backlog collaboratively with the project team so that the team's capacity, sprint goals, and dependencies are all factored in. This prevents unilateral mid-sprint additions that overload capaci
Question
During the third iteration of a project, the product owner requests another mandatory feature. This also happened in the previous two sprints, which resulted in failure and caused frustration within the team. What should the project manager do next?
Options
- ARequest the scrum team to prioritize the product backlog
- BAsk the product owner to prioritize the backlog with the project team
- CCall for an internal meeting to discuss the changes and their value
- DIncorporate the changes in the last sprint before the first release
How the community answered
(58 responses)- A3% (2)
- B84% (49)
- C2% (1)
- D10% (6)
Explanation
Backlog management is a shared responsibility. The product owner should prioritize the backlog collaboratively with the project team so that the team's capacity, sprint goals, and dependencies are all factored in. This prevents unilateral mid-sprint additions that overload capacity. Asking the Scrum team alone to prioritize (A) excludes the product owner who owns the backlog. An internal meeting about change value (C) doesn't address the systemic prioritization problem. Deferring changes to the last sprint (D) avoids the issue rather than resolving the dysfunctional backlog management pattern.
Topics
Community Discussion
9B is correct here. In Agile, the product owner owns prioritization, but doing it collaboratively with the team ensures everyone understands the value of the change and can have an honest conversation about what it means for the sprint, which is exactly what needs to happen after two failed iterations.
Agreed on B, just watch for a trap option that says the PO reprioritizes solo after failed iterations, because the exam loves to test whether you know the conversation with the team is the actual correct step before anything gets reordered.
B is correct and it is the right call here. The product owner owns backlog prioritization, but doing it with the team ensures feasibility gets factored in before commitments are made. This has failed twice already, so the pattern needs to break through real collaboration rather than the PO unilaterally injecting mandatory features mid-iteration. A is close but too vague because it lets the PO stay disconnected from the people who keep getting burned.
Failed my first attempt partly because I kept picking options like C here. The PM does not call internal meetings to second-guess the product owner, the right move is B because prioritization is the PO's job and it has to happen collaboratively with the team so everyone understands the tradeoffs. One thing that still confuses me though, if the PO keeps forcing mandatory features mid-sprint after the backlog is already prioritized, at what point does the PM escalate versus just letting the team push back during sprint planning?
B is right but on your question, the PM escalates when the PO keeps blowing up sprint scope after sprint planning, not during it, because mid-sprint changes are a process issue not a prioritization debate.
Sat for the exam last month and got a near-identical question, picked A and it scored correct. The pattern of repeated mid-sprint mandatory insertions means the real fix is forcing prioritization of the backlog so the PO sees the tradeoffs, and option B gives the PO too much control when the team is already frustrated from the last two failed sprints.
Toby, I actually went with A on my first attempt and it cost me, B is correct because the real issue is the PO bypassing sprint planning to force work in mid-sprint, and the fix is reinforcing that the PO prioritizes the backlog but the team commits during planning. The PO getting "too much control" is exactly the problem B addresses, not a reason to avoid it.
A. The team owns prioritization and this PO keeps blowing up sprints.
It is actually B. The real issue is the PO unilaterally changing priorities mid-sprint, which undermines the sprint commitment and team stability.