User Stories: Template, Examples & Format [2026]
A. Togay Koralturk, Best-Selling PMP Author
Last updated on August 09, 2026
12 min read
The best user stories barely look like documentation — a single sentence on a card, written in plain language a customer would recognize. That's the point: a user story isn't meant to capture every detail of a feature, but to capture who wants it and why, and to start a conversation that fills in the rest. This guide explains user stories in full — the template, real examples, the 3 C's, the INVEST qualities, acceptance criteria, how to write good ones, and how they appear on the PMP and CAPM exams.
What is a user story?
A user story is a short, simple description of a feature told from the perspective of the person who wants it. Rather than a technical specification, it captures a need in plain language — who the user is, what they want to do, and why — so the team stays focused on delivering value to real people rather than just building components.
The crucial idea is that a user story is a placeholder for a conversation, not a contract. The card itself is deliberately brief; the shared understanding comes from the discussion it prompts between the team and the product owner. User stories originated in Extreme Programming and were popularized by Mike Cohn, and they replaced the heavy, write-everything-up-front requirements documents of traditional projects with something lighter and more human. A story says just enough to remember what needs building and to spark the conversation that will flesh it out when the time comes — detail added just in time, not all at once.
The user story template and format
Most user stories follow a simple, standard template that keeps the focus on the user and their goal:
> As a [type of user], I want [some goal], so that [some benefit].
Each part does a job. "As a [type of user]" names the role or persona, anchoring the story in a real person's needs. "I want [some goal]" states what they're trying to accomplish. And "so that [some benefit]" captures why it matters: the value the feature delivers. That final "so that" clause is the most important and the most frequently skipped: without it, the team knows what to build but not why, which makes it impossible to judge trade-offs or tell whether a simpler solution would serve the same need. A story missing its "so that" is a story missing its point. The template isn't mandatory — some teams vary it — but its discipline of always tying a feature to a user and a reason is what makes it endure.
Ready to take the next step in project management?
200,000+ Learners Trust Our Instructors
User story examples
The template is easiest to grasp through concrete examples. Here are a few well-formed user stories across different products:
- As a returning shopper, I want to save my payment details, so that I can check out faster on my next order.
- As a new user, I want to reset my password by email, so that I can regain access if I forget it.
- As a project manager, I want to export a report to PDF, so that I can share progress with stakeholders who don't use our tool.
- As a frequent traveler, I want to filter flights by number of stops, so that I can avoid long layovers.
Notice what these have in common: each names a specific user, states a clear goal, and — crucially — explains the benefit. None of them mention how the feature will be built; there's no database schema, no API, no UI framework. That's deliberate. The story describes the need from the outside, and the team decides the implementation through conversation. A good story reads like something the user themselves might say, not like a task from an engineer's to-do list.
The 3 C's of a user story
Ron Jeffries described a user story with a memorable model called the 3 C's — Card, Conversation, and Confirmation. Together they capture that a story is a process, not just a sentence.
- Card. The physical or digital card holding the short written story. It's intentionally small — just enough to identify the feature and act as a reminder. The card is a token, not the whole story.
- Conversation. The discussion between the team, the product owner, and stakeholders that fleshes out the details. This is where the real requirements emerge — the card exists to prompt this conversation, not to replace it.
- Confirmation. The acceptance criteria that confirm when the story is done. They turn the shared understanding from the conversation into concrete, testable conditions everyone agrees on.
The 3 C's are a useful corrective to the most common user-story mistake: treating the card as a complete specification. A team that writes detailed cards but skips the conversation ends up with all the rigidity of upfront requirements and none of the flexibility stories are meant to provide. The value is in the whole cycle, not the card alone.
What makes a good user story? INVEST
Not all user stories are good ones. The widely used INVEST checklist, coined by Bill Wake, describes the qualities of a well-formed story — a quick test to run before committing to one.
| Letter | Quality | What it means |
|---|---|---|
| I | Independent | The story can be developed and delivered on its own, without depending on other stories. |
| N | Negotiable | It's not a fixed contract — the details are open to discussion and can flex. |
| V | Valuable | It delivers clear value to a user or customer, not just internal or technical work. |
| E | Estimable | The team understands it well enough to size it. |
| S | Small | It's small enough to complete comfortably within a single sprint. |
| T | Testable | You can define acceptance criteria that confirm when it's done. |
INVEST is most useful as a diagnostic. A story that isn't estimable usually needs more conversation; one that isn't small is probably an epic that should be split; one that isn't valuable may be a technical task masquerading as a story. Running a story through INVEST during backlog refinement catches these problems before they reach a sprint, where they're far more expensive to fix.
Acceptance criteria for user stories
Acceptance criteria are the specific conditions a user story must satisfy to be considered done — the "Confirmation" in the 3 C's. They translate a story's intent into concrete, testable statements, so that everyone agrees in advance on what "finished" means and there's no argument about it mid-sprint.
A common way to write them is the Given / When / Then format, which frames each condition as a scenario. For the password-reset story above, the acceptance criteria might read:
> - Given I'm on the login page, when I select "Forgot password" and enter my registered email, then I receive a reset link within five minutes. > - Given a reset link older than 24 hours, when I click it, then I see a message prompting me to request a new one.
Others prefer a simple checklist of conditions — either works, as long as the criteria are clear and testable. It's worth distinguishing acceptance criteria from the definition of done: acceptance criteria are specific to one story (does this feature behave correctly?), while the definition of done is a team-wide standard applied to every item (is it tested, reviewed, documented, and deployable?). A story is only truly done when it meets both its own acceptance criteria and the team's definition of done.
Epics, stories, and tasks
User stories sit in the middle of a simple hierarchy that helps teams manage work at different sizes. Understanding it keeps stories at the right granularity.
An epic is a large body of work — too big to finish in a single sprint — that represents a broad capability, like "user account management." Epics are broken down into user stories, each small enough to complete within a sprint, like "reset password by email." Stories, in turn, may be broken into tasks: the concrete implementation steps the developers carry out, like "build the reset-email template" or "add the token-expiry check." The rule of thumb: if a story is too big to fit comfortably in a sprint, it's really an epic and should be split into smaller stories. Keeping stories appropriately small is one of the most important habits in agile, because small stories flow faster, are easier to estimate with story points, and deliver value sooner.
How to write good user stories
Writing good stories is a skill, and a few habits separate useful stories from box-ticking ones:
- Start from the user, not the solution. Describe what a real person needs and why, and let the team work out the how. If a story reads like a technical task, rewrite it from the user's perspective.
- Never skip the "so that." The benefit clause is what keeps the team focused on value and enables smart trade-offs. If you can't articulate the benefit, question whether the story is worth doing.
- Keep them small. Aim for stories that fit in a sprint. Split anything larger; a story you can't finish in a sprint is an epic in disguise.
- Add acceptance criteria. Define, before work starts, the conditions that confirm the story is done. This is what prevents the mid-sprint "but is it finished?" debates.
- Remember the conversation. The card is a starting point, not the whole requirement. Leave room for the discussion that turns a one-line story into shared understanding.
The overarching principle is just enough, just in time: write stories with enough clarity to plan and prioritize, but defer the fine detail to the conversation that happens as the work approaches. Over-specifying up front recreates the very problem stories were invented to solve.
User Stories on the PMP® and CAPM® Exams
Because the current PMP exam covers agile and hybrid delivery heavily, user stories appear as the agile way of capturing requirements — expressed as user value rather than exhaustive specifications. The facts worth locking in: a story follows the "as a… I want… so that…" form, it's a placeholder for a conversation, it should meet the INVEST qualities, and it's confirmed by acceptance criteria that are specific to that story.
Situational questions tend to reward the user-value, conversation-based nature of stories over heavy documentation: watch for scenarios where stories are too large, written as technical tasks, or missing acceptance criteria, and favor answers that make them small, user-focused, and testable. The distinction between story-level acceptance criteria and the team-wide definition of done is another common test point. Our PMP Complete Study Guide, the most complete on the market, covers agile requirements and user stories as the exam frames them. If you're learning the discipline rather than sitting an exam, our Complete Project Management Course teaches requirements and backlog practices from the ground up.
PMP Practice Question: User Stories
During a sprint on an agile e-commerce project, a developer implementing the story "As a returning customer, I want my saved payment methods available at checkout so I can pay faster" notices that the acceptance criteria say nothing about expired cards. Handling expiry would take roughly a day of the remaining capacity; ignoring it means some returning customers will see a failed payment. The sprint forecast is already tight.
What should the developer do next?
a) Build the story as its acceptance criteria are written, and add an expired-card story to the product backlog for a future sprint.
b) Raise the gap with the Product Owner, and agree together whether expired-card handling belongs in this story or in the backlog.
c) Implement the expired-card handling now, since the story's intent is clearly a working payment experience and the effort fits within a day.
d) Submit the addition to the change control process for approval before the acceptance criteria are modified.
Correct answer: B.
Rationale: A user story is deliberately negotiable: the card is a placeholder for a conversation, and its acceptance criteria are the Confirmation, agreed with the Product Owner rather than owned by either side alone. Discovering a gap mid-sprint is precisely the moment that conversation exists for, and it is the Product Owner who weighs the value — expiry handling may complete this story's promise to returning customers, or it may be sliced into its own backlog item. Choice c) self-authorizes scope, spending a day of tight capacity on the developer's judgment alone; choice a) makes the opposite unilateral call, and although it may match what the Product Owner ultimately decides, it decides for the Product Owner instead of with them; choice d) imports heavyweight change control into an artifact the Product Owner can reorder and rewrite at will, treating a backlog item like a baselined requirement. To face more questions that turn on ownership and sequence like this one, work through our PMP practice exams or, at the entry level, our CAPM practice exams.
Ready to take the next step in project management?
200,000+ Learners Trust Our Instructors
Frequently asked questions
What is a user story?
A user story is a short, simple description of a feature told from the perspective of the person who wants it — capturing who the user is, what they want to do, and why. It is a placeholder for a conversation rather than a detailed specification: the card says just enough to remember the need and prompt the discussion that fills in the details. User stories keep teams focused on delivering value to real users.
What is the user story template?
The standard user story template is "As a [type of user], I want [some goal], so that [some benefit]." The first part names the user, the second states their goal, and the third — the "so that" clause — explains the value or reason behind it. That benefit clause is the most important and the most commonly skipped part, because it's what tells the team why the feature matters.
What are some examples of user stories?
Examples include: "As a returning shopper, I want to save my payment details, so that I can check out faster next time"; "As a new user, I want to reset my password by email, so that I can regain access if I forget it"; and "As a project manager, I want to export a report to PDF, so that I can share progress with stakeholders." Each names a user, a goal, and a benefit, without specifying how it will be built.
What are the 3 C's of a user story?
The 3 C's, described by Ron Jeffries, are Card, Conversation, and Confirmation. The Card is the short written story, the Conversation is the discussion that fleshes out the details between the team and the product owner, and the Confirmation is the acceptance criteria that define when the story is done. Together they show that a story is a process, not just a sentence on a card.
What makes a good user story? (INVEST)
A good user story meets the INVEST criteria: Independent (can stand alone), Negotiable (details are open to discussion), Valuable (delivers clear user value), Estimable (the team can size it), Small (fits within a sprint), and Testable (has acceptance criteria that confirm it's done). Running a story through INVEST is a quick way to catch problems — such as a story that's really an epic, or a technical task with no user value — before it reaches a sprint.
What are acceptance criteria?
Acceptance criteria are the specific conditions a user story must satisfy to be considered done. They translate the story's intent into concrete, testable statements, often written in a "Given / When / Then" format, so everyone agrees in advance on what finished means. They differ from the definition of done: acceptance criteria are specific to one story, while the definition of done is a team-wide standard applied to every item.
Is the user story on the PMP exam?
Yes. The current PMP exam covers agile approaches heavily, and user stories appear as the agile way of capturing requirements as user value. You are expected to know the "as a… I want… so that…" format, that a story is a placeholder for a conversation, that good stories meet the INVEST qualities, and that acceptance criteria confirm when a story is done — as opposed to specifying everything up front.
Is the user story on the CAPM exam?
Yes. The CAPM covers agile artifacts including user stories, usually a little more directly than the PMP — often testing the template, the 3 C's, or the difference between acceptance criteria and the definition of done. Because the CAPM is scenario-based, you should also be ready to recognize a poorly written story, such as one written as a technical task or lacking acceptance criteria.
What Is Scrum? Roles, Events & Artifacts [2026]
Scrum is a lightweight agile framework for complex work. Its theory, the 3 roles, 5 events, and 3 artifacts, scrum vs. agile, benefits, and PMP exam tips.
Scrum Master: Role, Responsibilities & Skills [2026]
A scrum master is a servant leader who helps a team work effectively. Responsibilities, scrum master vs. project manager, skills, becoming one, and exam tips.
Product Owner: Role, Responsibilities & Skills [2026]
The product owner maximizes a product's value and owns the backlog. Responsibilities, product owner vs. scrum master, skills, how to become one, and exam tips.
