September 7, 2026 · 6 min read
TL;DR: Reordering or reprioritising the backlog appears in 21 of the bank's answer options, keyed 11 times and wrong 10. Keyed when new scope or new information arrives on an adaptive project and the question is what to build next. Wrong when it is offered as a way to fund something, to recover capacity, or to re-decide something already decided.
This is one of the few near-even splits in the bank where both sides are easy to state, which makes it good exam value: get the discriminator right and you convert a coin flip into a rule.
The clearest case is new scope on an agile project. A product owner sees a competitor launch an appealing feature. Four options: add it to the product backlog and reprioritise, add it to the current sprint backlog and reprioritise, raise a change request, or update the work breakdown structure.
Keyed is the first. The explanation covers both of the near misses: the team has already committed to the current sprint's scope, so the feature does not go there, and adaptive approaches generally avoid a formal change control procedure because it would slow the team down, with the product owner empowered to approve the change instead.
The second case is a mid-project realisation that the product will not deliver its promised benefits. Contingency and management reserves are both available, which is bait. Keyed is to reprioritise the backlog to include the new scope and start the highest-priority item right away, over taking the change to the change control board, using the contingency reserve, or reviewing the change management plan. On an adaptive project, adapting is the process.
The third is compliance arriving mid-flight: collaborate with the compliance specialist to review the requirement and re-prioritise the delivery. Same shape.
When reordering is offered as a way to fund something, recover lost capacity, or re-open a decision that has already been made.
| Stem | Reprioritise option | Why it loses |
|---|---|---|
| Sponsor approves scope, no money left in the baseline | Ask the PO to reprioritise to see if the work will fit | The decision is made; the open question is funding, so management reserve is keyed |
| CCB approved two changes, rejected two, deferred one | Review and re-prioritise scope to fit the must-haves | Every decision has to be recorded in the change log and communicated |
| Operational issues plus the technical lead resigning | Stop the sprint, replan and reprioritise to reduce resource levels | Cuts capacity that is already short |
| Long tail of unpredictable admin tasks | Re-prioritise the backlog daily | Churns the backlog; build the tasks into the definition of done instead |
The funding item is the one that catches strong candidates. The sponsor has already approved adding the scope, so asking the product owner whether it fits is answering a question nobody asked. Management reserve exists for unforeseen work still within scope, released at senior management's discretion, and that is where the answer goes.
Common trap: treating "this is an agile project" as a signal that backlog reprioritisation is always available. In the release-recovery item, a team has lost its technical lead and hit repeated operational issues, and "stop the sprint, then replan and reprioritise the backlog to reduce resource levels" is offered. The bank rejects it for reducing capacity that is already short, and keys taking the new constraints into the team's own sprint planning to work out what the release plan can realistically contain. Reprioritising decides what to build. It does not create the ability to build it.
In the keyed items, yes. Treat it as a real boundary rather than a formality: reprioritisation is where the product owner's authority actually bites.
Several distractors elsewhere in the bank fail precisely because a project manager reaches into it. The corresponding limit is that the product owner does not decide how the work is done or what the team commits to inside a sprint.
The bank flags this by name in its explanations rather than leaving you to infer it, which is how a near-even 11-to-10 split turns into something you can actually apply under time pressure.
When is reprioritising the backlog the keyed PMP answer? When new scope or new information arrives on an adaptive project and the question is what the team works on next. The bank keys reordering the backlog over raising a change request in that situation, because adaptive projects absorb change through the backlog rather than through baseline change control.
Can new work go straight into the current sprint? No. The bank offers adding the feature to the current sprint backlog as a distractor alongside adding it to the product backlog, because the team has already committed to the sprint's scope.
Does reprioritising replace change control entirely? On the adaptive side of the work, largely yes for scope ordering. It does not replace funding decisions, and it does not undo an approved change that still has to be recorded in the change log.
Where do these questions sit in the 2026 ECO? Mostly Process, and mostly under helping ensure value-based delivery, with a smaller Business Environment group under managing and controlling changes, mapped on the Business Environment study page.
PMP Practice's 2,141 questions are certified against PMBOK 8 and the July 2026 ECO, with every wrong answer explained rather than just marked wrong. Start the free 20-question sample — no card, no signup required to try it.
Related reading: The Product Owner on the PMP Exam: What They Decide, and What They Never Get to Decide and The Change Control Board: 7 Keyed, 32 Distractors, and 0 on an Agile Project. Process tasks are mapped on the Process domain study page.
When is reprioritising the backlog the keyed PMP answer?
When new scope or new information arrives on an adaptive project and the question is what the team works on next. The bank keys reordering the backlog over raising a change request in that situation, because adaptive projects absorb change through the backlog rather than through baseline change control.
Can new work go straight into the current sprint?
No. The bank offers adding the feature to the current sprint backlog as a distractor alongside adding it to the product backlog, because the team has already committed to the sprint's scope.
Does reprioritising replace change control entirely?
On the adaptive side of the work, largely yes for scope ordering. It does not replace funding decisions, and it does not undo an approved change that still has to be recorded in the change log.