September 7, 2026 · 7 min read
TL;DR: User stories appear in 30 answer options across the bank and are keyed 9 times. The keyed nine treat the story as a unit of work: it enters the product backlog, it gets estimated relatively, it carries enough detail to start. The 21 distractors treat the story as an outcome, where writing one, checking one or splitting one is offered in place of the conversation or decision the situation needs.
The bank's own definition says why. A story is defined by whose point of view it takes, and it is deliberately brief because it is a placeholder for a conversation. Most of the wrong answers forget the second half.
When the question is where a requirement goes, how it gets sized, or what it needs before work starts.
Where it goes. An influential stakeholder catches the project manager in a corridor and urgently asks for a story to polish the interface. Keyed is adding it to the product backlog and letting the product owner decide its priority. Slotting it into the sprint backlog or the next sprint takes that decision from the product owner. Declining to write it down because refining the backlog is the product owner's job discards input that may be worth having.
How it gets sized. A sponsor asks how long the features will take. Keyed is breaking each feature into stories and tasks and estimating them with the development team. A feature is too large a unit to estimate reliably, and decomposition without the team gives you small items estimated by someone who will not do the work. When a stakeholder wants a quick read on a feature that mirrors one built in an earlier iteration, keyed is reviewing the earlier stories and velocity to estimate the new one. That is analogous estimating on the team's own data.
What it needs to start. On a project just getting under way, the keyed guideline is that stories in the sprint backlog carry enough detail for work to begin. The three distractors demand the same detail for every story in the product backlog, every story for the whole project, or enough detail to make all stories the same size. None of that is required, and the last one is not even desirable.
The delivery approach. A new insurance product needs to test market readiness fast. Keyed is an adaptive approach built on clearly defined user stories. Large loose epics cannot be delivered inside an iteration and delay the first release.
When writing, checking or splitting a story is offered in place of a conversation, a decision, or a step that should already have happened.
When a conversation is needed. Three sprint reviews running, the customer is dissatisfied with what has been built. Checking that every story meets its acceptance criteria is offered, and so is cross-checking the definition of done. Both lose to bringing the customer and the team together, because both measure the team against its own standard, which is plainly not the standard the customer is applying. A team deep in technical delivery has lost sight of the customer experience, and writing detailed stories that tie each task to a customer outcome loses to regular sessions that reconnect the work to the vision. The explanation is blunt: writing outcomes into every story documents the link without ever discussing it.
When a decision is needed. Velocity dropped after two sprints and the release will miss its deadline. Decomposing the stories to boost velocity is offered and loses to discussing the velocity issue with the product owner, because splitting stories changes how work is counted rather than how much gets done, and the trade between scope, date and a partial release belongs to the product owner. A head of operations says the company is not getting a return on a productive agile team. Reviewing the stories and prioritising the relevant backlog items loses to defining the minimum marketable features and ordering the backlog around them, because reordering in general terms does not guarantee anything reaches a customer sooner.
When the step has already happened. The next iteration is about to start and the question asks what to do before planning it. Decomposing features into stories is offered and loses, because that should already have happened during refinement; arriving at planning with undecomposed features is a symptom of preparation having been skipped. Keyed is working with the product owner to prioritise the highest-value items.
Common trap: counting stories as if they were the same size. To work out what fits in the coming iteration, tallying the number of stories the product owner would like done is offered and loses to comparing velocity with the point total of the candidate cards. Story counts are not comparable because the cards are not the same size. The same error surfaces when a board member asks for the cost of the minimum viable product: estimating story points and forecasting a budget from them loses to calculating the budget at completion, because points measure relative size and need a conversion the board cannot audit. The bank offers the story-as-a-countable-unit mistake in three separate items, and each explanation names why the unit does not carry.
The definitional items test whose point of view a story takes, what it carries, and who is entitled to write and approve it.
| Statement | True or false in the bank |
|---|---|
| A story is a unit of work small enough for one person to finish in a day or two | False; that describes a task |
| A story addresses both functional and non-functional requirements | True |
| A story includes acceptance criteria for the feature | True |
| A story should be estimable, small and testable | True; three of the six INVEST properties |
| The sponsor must sign off on every story in advance | False; that gate would destroy the backlog's responsiveness |
| Writing stories is a tool designed to surface and resolve problems | False; that is retrospectives, reviews and stand-ups |
Two more items round out the picture. The product owner is seen sizing stories at an estimation workshop, and the keyed correction is that the team should be estimating, because estimates belong to the people who will do the work; relative sizing itself is standard practice and not the problem. And when a product owner and the team keep interpreting a story differently, the keyed reason for creating personas is to help the team empathise with the people who will use the solution. The story still gets built through a conversation. The persona gives the conversation someone to talk about.
The through-line across all 30 options is the same one the bank's explanations keep returning to. A story is the smallest part of card, conversation and confirmation. Every keyed answer uses it as a card. Every distractor asks the card to do the other two jobs.
What is a user story on the PMP exam? A short description of a needed capability told from the point of view of the person who wants it. It is defined by whose view it takes, not by how long it takes, and it is deliberately brief because it is a placeholder for a conversation rather than a substitute for one.
When is writing or refining a user story the wrong answer? When the scenario needs a conversation or a decision that a story cannot supply: a customer dissatisfied three reviews running, a team that has lost sight of the vision, a release that velocity says will miss its date. Checking or rewriting stories in those cases measures the team against its own standard or reshuffles work that will not fit.
Who writes and approves user stories? The team writes them collaboratively with the product owner, who is accountable for the backlog's content and order. The sponsor does not sign off individual stories; a rule that they must is the one incorrect statement the bank offers about collaborative story creation.
How much detail should a story have before work starts? Enough for the stories entering the next iteration to begin. Stories deeper in the product backlog stay coarse until refinement brings them forward, and stories do not need to be the same size.
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 Acceptance Criteria: The Scope Answer Candidates Skip Past. Scope tasks are mapped on the Process domain study page.
What is a user story on the PMP exam?
A short description of a needed capability told from the point of view of the person who wants it. It is defined by whose view it takes, not by how long it takes, and it is deliberately brief because it is a placeholder for a conversation rather than a substitute for one.
When is writing or refining a user story the wrong answer?
When the scenario needs a conversation or a decision that a story cannot supply: a customer dissatisfied three reviews running, a team that has lost sight of the vision, a release that velocity says will miss its date. Checking or rewriting stories in those cases measures the team against its own standard or reshuffles work that will not fit.
Who writes and approves user stories?
The team writes them collaboratively with the product owner, who is accountable for the backlog's content and order. The sponsor does not sign off individual stories; a rule that they must is the one incorrect statement the bank offers about collaborative story creation.