User Story Template (PMI Standard Word & PDF)

8 min read · Reviewed August 2026 by Dan Sunil Kumar

When to use it

• Requirements arrive as feature names with no stated user or outcome.
• "Done" is disputed at the sprint review because criteria were never written down.
• Stories keep carrying over because they are too big to finish in one sprint.
• A new team needs a shared format for refinement and story-writing workshops.
• You are converting a requirements document into a backlog the team can work from.

Every section, and what good looks like

1. Section 1

   Story card

   ID, title, the as-a / I-want / so-that sentence, parent epic, priority, estimate and owner.

   The "so that" is a genuine outcome, not a restatement of the capability. If it reads oddly, the value is unclear.

2. Section 2

   Acceptance criteria

   Three to seven testable conditions in Given (context) / When (action) / Then (observable result) form.

   Each line can be answered pass or fail by someone who was not in the conversation.

3. Section 3

   Negative and edge cases

   What happens on invalid input, timeout, permission denial or an expired state.

   At least one criterion covers the unhappy path — that is where most defects and most rework live.

4. Section 4

   Out of scope

   The adjacent things this story explicitly does not cover.

   Names the thing a stakeholder has already asked for, so it does not reappear as "but obviously" during review.

5. Section 5

   INVEST check

   Independent, Negotiable, Valuable, Estimable, Small, Testable.

   Run before estimating. A story failing Small or Testable is not ready, however keen the team is to start.

6. Section 6

   Notes, dependencies and open questions

   Designs, data, access, third-party work and the questions still unanswered, each with an owner and a needed-by date.

   Open questions have a name against them, so refinement produces answers rather than a list of unknowns.

7. Section 7

   Splitting patterns

   Workflow step, business rule, interface, data variation, CRUD operation, or a spike first.

   Each slice delivers something demonstrable on its own — never split into "back end" and "front end".

A filled-in example

A realistic user story card with Given/When/Then acceptance criteria, so you can see where the detail belongs.

Mistakes that make user stories unbuildable

• Writing acceptance criteria during development, so scope is negotiated while the work is half built.
• Criteria that describe implementation ("add a column to the users table") rather than observable behaviour.
• Only happy-path criteria, which is why the unhappy path becomes next sprint's defect list.
• Stories with fifteen criteria — that is an epic wearing a story's clothes.
• Splitting by technical layer, so nothing is demonstrable until every slice is finished.
• A "so that" clause that just repeats the capability, hiding the fact that nobody knows why it is being built.
• Treating the card as a contract instead of a conversation, then refusing to change it when the team learns something.

Questions people ask

What is a user story template?

A one-page format holding the story sentence (as a role, I want a capability, so that an outcome), testable acceptance criteria, priority and estimate, dependencies and open questions, plus an INVEST check before the story is accepted into a sprint.

How do you write acceptance criteria?

Use Given/When/Then: Given a context, When an action happens, Then an observable result follows. Write three to seven criteria, include at least one unhappy path, and make sure each can be answered pass or fail without further interpretation.

What is the INVEST acronym?

Independent, Negotiable, Valuable, Estimable, Small and Testable — a quick quality check for a story. Failing Small or Testable is the usual reason a story carries over into the next sprint.

How big should a user story be?

Small enough for the team to finish comfortably inside one sprint, and ideally a few days of work. If an item would take most of the sprint, split it by workflow step, business rule, interface, data variation or operation.

What is the difference between a user story and a requirement?

A requirement states what a system must do and is usually signed off before build. A user story states who needs what and why, and is deliberately open until the team and Product Owner agree acceptance criteria. The criteria are where a story becomes as precise as a requirement.

Do user stories need estimates?

They need enough sizing for the team to forecast a sprint — story points or a rough day count. The estimate is for planning, not for measuring individual performance, and it should come from the people doing the work.

Read next

• Scrum Ceremonies: Purpose, Timebox and Agenda
• Scrum Mechanics Without the Dogma
• Work Breakdown Structures and Scope Control
• Estimation That Survives Contact with Reality

Other PMI-standard templates

Every one has the same walkthrough, worked example and PMI mapping, and every file ships inside the PM Delivery Toolkit.

• Project charter templateWord & PDF · Integration Management
• Project plan pack templateWord, Excel & PDF · Integration & Schedule Management
• Project status report templateWord & PDF · Communications Management
• RACI matrix templateExcel, Word & PDF · Resource Management

Keep going on the site

The hubs and tools that pair with this user story.

• PM Delivery ToolkitEvery PMBOK-mapped template in one paid pack, with the walkthroughs.
• PM glossaryPlain-English definitions for the terms these registers use.