September 8, 2026 · 8 min read
TL;DR: Sprint planning appears in nineteen options in this bank and is keyed six times. Almost every wrong placement does the same thing: it defers something to the planning meeting that either belonged before it or cannot wait for it. Refinement belongs before. A vendor outage cannot wait. A mid-sprint pivot does not get a hearing there at all. Sprint planning has a narrow job, turning a goal and an ordered backlog into a commitment, and options that load it with anything else are usually the trap.
The meeting is familiar enough that candidates treat it as a general-purpose container for agile decisions. The bank writes items on the assumption that you will, then keys the answer that keeps the container empty.
Two things, and neither is a report on the past.
The bank asks it directly. A team has finished the first sprint of an automated payroll system and the project manager has convened sprint planning with the product owner and the team. Which two inputs are needed for the session to be productive? Keyed are the sprint goal and the product backlog.
The explanation states the function of the meeting in one line, and it is the line to carry into every other question on this topic: sprint planning turns an objective into a committed set of work, so it needs the sprint goal to say what the team is trying to achieve and the prioritised product backlog to say which items are available to pull toward it.
Then it rules out the three distractors, each in a different way. The burndown chart from the first sprint reports progress already made rather than what to do next. The company mission and vision statement sits far above the level of a sprint. And a sprint charter does not exist as an artifact at all, which is worth noticing as a technique: an invented but plausible-sounding document is a distractor pattern this bank uses more than once.
Attendance is tested separately and keyed just as narrowly. Asked which statement about sprint planning is correct, the keyed option names the product owner, the scrum master and the cross-functional team. Three distractors each drop one of the three. Sprint planning involves the entire Scrum team.
Refinement, urgent decisions, and anything the stem needs answered now.
| Scenario in the bank | Sprint planning option offered | What is actually keyed |
|---|---|---|
| Backlog order bears no relation to what gets picked up | Refine jointly during sprint planning | Coach the PO to refine continuously, ahead of planning |
| Two developers want to pivot mid-sprint to refactoring | Let them pitch it at the next sprint planning | Hold to the sprint goal for this sprint |
| Third-party payments API slowing down, vendor silent | Wait until the next sprint planning to deal with it | Contact the vendor now and tackle it proactively |
| Scrum master tagged backlog items, PO wants them removed | Wait until sprint planning to change the tags | Remove the tags now |
| PO has not documented stories and planning is about to start | Postpone planning until documentation is ready | Prioritise and document just the stories needed to start |
| Business rep wants more features than velocity supports | Add more team members | Show velocity and points, ask them to prioritise at planning |
| Deliverables failing the stakeholder's quality specs | Dedicated sprint to finish outstanding specs | Reinforce the definition of done in sprint planning |
Two rows in that table key sprint planning and five reject it, which is the shape of the whole topic. Notice what separates them. The two keyed rows involve something that genuinely happens inside the meeting: prioritising against a visible velocity, and reinforcing the definition of done so the team shares one standard for complete. The five rejected rows all use the meeting as a place to postpone something.
The refinement record is the clearest. A project manager notices the product backlog is not being refined, and the order of stories bears no relation to the order they are picked up at release planning. Keyed is coaching the product owner to refine the backlog continuously and keep it ordered ahead of sprint planning. Three distractors offer refinement immediately before planning, once per release, or jointly during the planning session. The explanation rejects all three together: they leave the backlog out of date for long stretches and push the work into a meeting that should be spending its time on commitment.
Not as the answer to what you do now.
A team has committed this sprint to a payment-reconciliation feature. Partway through, two developers want to pivot to refactoring the data layer to head off future performance problems. One option gives the developers a slot to pitch the refactor at the next sprint planning meeting, which sounds like exactly the right process answer.
Keyed is reinforcing that the team should hold to the sprint goal of finishing the reconciliation feature. The explanation says the sprint is a timebox specifically so that the goal is protected from a good idea arriving mid-iteration, and adds the reason this option beats the planning-slot one: it is the answer to the immediate question, which is what the team does for the rest of this sprint.
That last clause is the exam skill. The pitch-it-later option is not wrong about process. It is wrong about the question. When two options are both defensible, the one that answers the stem's actual timeframe wins.
Common trap: using the next sprint planning as a parking space for anything urgent. Three separate records in this bank offer it that way and none is keyed. A third-party payments API is intermittently slowing down, users can notice it, and the vendor has not acknowledged the problem; waiting until the next sprint planning is offered and the keyed answer is contacting the vendor now, because doing so establishes whether they know, starts the clock on their investigation, and creates a record of when the problem was raised. A product owner asks for backlog tags to be removed; waiting until planning is offered and the keyed answer is to remove them, since the product owner owns their own backlog. The meeting has a cadence, and the cadence is not a reason to hold a decision that has already arrived. This bank names those deferral distractors and explains what they cost, rather than only marking them wrong.
To bind both sides, not just the team.
The bank has a record built around this. In sprint planning, the scrum master helps the product owner and the team settle what the coming two-week iteration will deliver. The team undertakes to complete those items inside the timebox, and the product owner undertakes not to change the requirements behind them while the iteration runs. Why does that matter?
Keyed is that it binds both sides, so neither the team's commitment nor the sprint goal can be undercut. The explanation adds the consequence of dropping the product owner's half: without it, scope creep inside the iteration can put the sprint goal beyond reach.
The three distractors are each a common misreading. That it guarantees the goal will be met, which no agreement can do. That it builds flexibility into planning, when freezing the requirements is the opposite of flexibility. That it ensures both sides get what they want, when the point is the mutual constraint rather than mutual satisfaction.
One related case is worth ending on, because it shows the meeting flexing without breaking. A product owner has been travelling and has not documented user stories, and planning is about to begin. Postponing until documentation is ready is offered, as is letting the team start on features they flagged themselves, as is having the team write the stories. Keyed is working with the product owner to quickly prioritise the most critical features and document just the stories needed to start the sprint. Only the product owner prioritises the backlog, so the fix keeps the authority where it belongs and does the minimum needed to let the meeting do its job.
What are the two inputs sprint planning actually needs? The sprint goal and the prioritised product backlog. The bank keys both together and explains that sprint planning turns an objective into a committed set of work, so it needs the goal to say what the team is trying to achieve and the backlog to say which items are available to pull toward it. The previous sprint's burndown is named as the near miss because it reports progress already made.
Who attends sprint planning? The whole Scrum team. The bank keys the option naming the product owner, the scrum master and the cross-functional team, and rejects the three options that leave one of them out. A separate record names sprint planning and the sprint review as the two meetings a busy product owner cannot drop, since the work is chosen against their ordering at one and accepted or rejected at the other.
Should backlog refinement happen during sprint planning? No. The bank keys coaching the product owner to refine the backlog continuously and keep it ordered ahead of sprint planning, and names refining jointly during the planning session as a distractor, because it pushes the work into a meeting that should be spending its time on commitment.
Can the product owner change requirements once the sprint has started? That is the point of the mutual agreement made in planning. The bank keys the reasoning that it binds both sides, so neither the team's commitment nor the sprint goal can be undercut, and notes that without the product owner committing not to move the target, scope creep inside the iteration can put the sprint goal out of reach.
PMP Practice's 2,141 questions are re-certified against PMBOK 8 and the July 2026 Exam Content Outline, with every wrong answer explained, not just marked wrong, which is how you learn to spot an option that is right about process and wrong about the question. Start the free 20-question sample — no card, no signup required to try it.
What are the two inputs sprint planning actually needs?
The sprint goal and the prioritised product backlog. The bank keys both together and explains that sprint planning turns an objective into a committed set of work, so it needs the goal to say what the team is trying to achieve and the backlog to say which items are available to pull toward it. The previous sprint's burndown is named as the near miss because it reports progress already made.
Who attends sprint planning?
The whole Scrum team. The bank keys the option naming the product owner, the scrum master and the cross-functional team, and rejects the three options that leave one of them out. A separate record names sprint planning and the sprint review as the two meetings a busy product owner cannot drop, since the work is chosen against their ordering at one and accepted or rejected at the other.
Should backlog refinement happen during sprint planning?
No. The bank keys coaching the product owner to refine the backlog continuously and keep it ordered ahead of sprint planning, and names refining jointly during the planning session as a distractor, because it pushes the work into a meeting that should be spending its time on commitment.
Can the product owner change requirements once the sprint has started?
That is the point of the mutual agreement made in planning. The bank keys the reasoning that it binds both sides, so neither the team's commitment nor the sprint goal can be undercut, and notes that without the product owner committing not to move the target, scope creep inside the iteration can put the sprint goal out of reach.