September 7, 2026 · 9 min read
TL;DR: Options naming the product owner appear 146 times in this bank and are keyed in 55 of them, which sounds like a coin flip until you look at what separates the two groups. The product owner decides what gets built and in what order. The team decides what it costs and how it gets built. The scrum master owns the process. Nearly every product owner distractor in this bank breaks one of those three lines, most often by handing the product owner the team's estimating job.
Candidates learn the three agile roles as a list of responsibilities and then meet a scenario where four options all sound like something a reasonable product owner might do. The list does not settle it. What settles it is a boundary question: is this a decision about what the product should be, or a decision about the work?
One thing, stated two ways: the product backlog, and the order of it. Everything the keyed answers in this bank ask a product owner to do traces back to that.
When a product owner is not refining the backlog, and the story order bears no relation to what the team actually picks up at release planning, the keyed answer coaches them to refine continuously and keep it ordered ahead of planning. When a hybrid team demonstrates a hard-won increment at the sprint review and the product owner returns with a long list of changes, the keyed answer takes those changes into backlog refinement, because a batch of feedback has to be weighed against everything else waiting before any of it is built. When the team works out a solution that would substantially change the product's features, the keyed answer stops and asks the product owner to review it and give a recommendation, before more effort is spent.
Notice what those have in common. None of them is about how the work gets done. All of them are about what is worth doing next.
Three places, over and over.
| The distractor | Whose job it really is | Why the exam keys against it |
|---|---|---|
| The product owner sizes the cards or gives initial estimates | The team, mainly developers and testers | An estimate produced by someone else is a target handed down, not an estimate |
| The product owner enforces how the team works, or names a lead developer | The scrum master, and the team itself | The team self-organises; process is not the product owner's remit |
| The product owner validates the final deliverables | Not this role | This is acceptance against criteria, a different job from guiding the product |
| Push the new work into the current sprint, or extend the sprint to fit it | The backlog, then the next sprint | Sprint scope is protected; new work is ordered, not inserted |
| Escalate the product owner's behaviour to the sponsor | The scrum master, with the product owner | Escalating something two people in the room can settle |
The estimating line is the one worth over-learning, because this bank tests it from three different angles. There is a question where the scrum master notices the product owner sizing user stories at a release estimation workshop, and the keyed answer is to explain that the team should be estimating. There is a plain one asking who does story-card sizing, where the product owner, the scrum master and the customer are all offered and the team is keyed. And there is a sprint planning question where "have the product owner give initial estimates for the team to refine" sits in the option list and loses to adding acceptance criteria to the definition of ready before any estimating starts.
Common trap: treating the product owner as the person who decides everything on an agile project, because they represent the business. This bank puts that belief in an option and keys against it. Asked how a directive project manager can move toward servant leadership, one option is to defer to the product owner and the business to make every decision; the keyed answer has the stakeholders collectively agree and share the decisions. Deferring everything to one person is the same failure as deciding everything yourself, just pointed at a different chair. The bank's wrong answers name that distractor rather than leaving you to guess why you lost the mark.
New scope on an adaptive project enters through the product backlog, and the product owner orders it. That is the highest-frequency shape in this slice, and it holds whether the new scope came from a stakeholder, a regulator, a compliance team, or the product owner themselves.
A worked example. A product owner asks for a new data-privacy feature mid-sprint, not in the original requirements, and it will take considerable effort. The team is already committed. Four options: submit it through formal change control, work with the product owner to add it to the product backlog for prioritization, drop it into the current sprint immediately because privacy is serious, or turn it down because it was not in the original scope. The keyed answer is the backlog. Change control is the wrong mechanism for product scope on an adaptive project. Dropping it into the sprint breaks the commitment the team already made. Refusing it treats an agile backlog like a signed specification.
The same shape appears when the product owner is the one pushing. Partway through a sprint with only a few stories left and nearly finished, the product owner asks for new features. The keyed answer asks them to put the work in the next sprint, and if it truly cannot wait, to cancel the current sprint, which is their decision to take. Extending the sprint is offered. Taking the work on because agile is about embracing change is offered. Both lose.
What does the product owner decide on the PMP exam? What gets built and in what order. The keyed answers cluster around ordering the backlog, refining it continuously, deciding whether work enters now or next, and settling what the product should do. A substantial design change goes in front of the product owner before more effort is spent, because the value call is theirs.
Can the product owner estimate the team's work? No, and this bank tests it three separate ways. A product owner sizing stories at a workshop keys to the scrum master explaining that the team should estimate. A direct question on who sizes cards keys the team over the product owner, the scrum master and the customer. Estimates belong to the people doing the work.
What should happen when new scope arrives mid-sprint? It goes to the product backlog for the product owner to order, not into the running sprint. Cancelling the current sprint is the only in-sprint option the exam allows, and it is the product owner's call.
Is a change request the right answer on an agile project? Usually not for product scope. A mid-sprint privacy feature keys to the backlog with change control offered as a distractor, and a batch of sprint review feedback keys to refinement with the change control board offered and not keyed.
PMP Practice's 2,141 questions are re-certified against PMBOK 8 and the July 2026 exam content outline, and every wrong answer is explained rather than just marked wrong, which is how role-boundary patterns like this one become visible at all. Start the free 20-question sample with no card and no signup.
Related: Value-Based Delivery: Why On Time and On Budget Is Not the Answer and Change Requests: Who Approves What, and When You Need One At All. Study the domain: Process.
Sources: PMI, PMP Exam Content Outline (2026) · The Scrum Guide
What does the product owner decide on the PMP exam?
What gets built and in what order. In this bank the keyed product owner answers cluster tightly around ordering the backlog, refining it continuously, deciding whether new work enters now or next, and settling questions about what the product should do. When a substantial design change is proposed, the keyed answer is to put it in front of the product owner before any more effort goes into it, because the value call is theirs.
Can the product owner estimate the team's work?
No, and this bank tests it directly more than once. One question has the product owner sizing the stories at an estimation workshop and the keyed answer has the scrum master explain that the team should be estimating. Another asks who does story-card sizing and keys the team, mainly developers and testers, over the product owner, the scrum master and the customer. A third offers the product owner giving initial estimates for the team to refine, and keys something else entirely. Estimates belong to the people doing the work.
What should happen when new scope arrives mid-sprint?
It goes to the product backlog for the product owner to order, not into the running sprint. When a product owner asks for new features partway through a sprint that is nearly finished, the keyed answer asks them to put the work into the next sprint, and to cancel the current one only if it genuinely cannot wait, because cancelling is the product owner's call. Extending the sprint to fit the work and escalating the product owner's behaviour to the sponsor are both offered, and both are wrong.
Is a change request the right answer on an agile project?
Usually not, when the change is about product scope. In this bank a new privacy feature the product owner wants mid-sprint keys to adding it to the product backlog for prioritization, with the formal change control route offered as a distractor. A batch of feedback from a sprint review keys to backlog refinement, again with the change control board offered and not keyed. On an adaptive project the backlog is the mechanism for absorbing new scope, so reaching for a change control board signals the wrong delivery approach.