This User Story template is used by business analysts to capture requirements at a small, testable scale, in plain language, from the perspective of the person who actually benefits.
What Is a User Story?
A User Story is a short, plain-language description of a piece of functionality, written from the perspective of the person who benefits from it — most commonly in the form “As a [role], I want [goal], so that [benefit].” Unlike a lengthy upfront specification, a User Story is deliberately lightweight: it’s a placeholder for a conversation, with the real detail captured through discussion with stakeholders and written down as acceptance criteria, not buried in the sentence itself.
What Should a User Story Include?
- Role — who this is for, specific enough to mean something (“a returning customer,” not just “a user”)
- Goal — what they want to do
- Benefit — why it matters to them, which is what actually helps with prioritisation later
- Acceptance criteria — the specific, testable conditions that must be true for the story to be considered done
- Estimate — story points or similar, sized relative to other stories
- Priority — where it sits in the backlog relative to other stories
- Dependencies — any other story or piece of work this one relies on
User Story vs Use Case — What’s the Difference?
A Use Case is a detailed, structured document describing a full interaction between an actor and a system — a main flow, alternate flows, preconditions, and postconditions — typically written upfront before development starts. A User Story is intentionally lighter: a short sentence capturing intent, with detail added later through conversation and acceptance criteria rather than documented in full in advance. Use Cases suit projects that need detailed upfront sign-off; User Stories suit iterative delivery where requirements are refined as the team learns more.
Common Mistakes When Writing User Stories
- No acceptance criteria. A story that’s just a sentence has nothing to test against — acceptance criteria are what turn intent into something a developer can build to and a tester can verify.
- Missing the “so that” benefit. Dropping the benefit clause makes prioritisation harder later, since nobody can weigh the story against competing priorities without knowing why it matters.
- Stories too large. “As a user, I want the whole checkout process to work” isn’t story-sized — it needs slicing into pieces small enough to estimate and deliver in one iteration.
- Written as a technical task. “As a developer, I want to refactor the database” isn’t a user story — if there’s no end-user role who benefits, it’s a technical task, not a story.
What’s Included in This Template
- Pre-structured sections with guidance notes
- Worked examples from real BA projects
- Guidance for Agile, waterfall, and hybrid approaches
- Easy to adapt to your organisation’s standards
How to Use This Template
Write the story with the actual end user in mind, then flesh out acceptance criteria in conversation with stakeholders rather than guessing at them alone — a story is meant to be a starting point for discussion, not a finished specification. Each section has guidance notes explaining what to include and why — based on real BA practice, not textbook theory. Remove sections that don’t apply and add organisation-specific fields.
On projects that also produce a Business Requirements Document, user stories are often how those higher-level requirements get broken down into deliverable, iteration-sized pieces of work.
Why Requirements Templates Matter
Consistent documentation is one of the most underrated BA skills. A well-structured document:
- Sets clear expectations from day one
- Reduces “we didn’t know that was in scope” conversations
- Creates an audit trail for decisions and changes
- Speeds up new team member onboarding
- Builds your credibility as a professional BA
Browse All Free Templates
Our free BA template library covers 15 core documents. For 175 practitioner-level templates covering the full BA lifecycle, see our BA Toolkit — Complete Pack. Free account required for the library, no payment.
Want to Master These Tools?
Templates are a starting point. Our BA training courses teach you how to apply them in real projects — with exercises, feedback, and examples from experienced BAs. Start with our free intro course.
Frequently Asked Questions
What is a User Story used for?
It captures a requirement at a small, testable scale, in plain language, from the perspective of the person who benefits — with detail added through conversation and acceptance criteria.
What is the difference between a User Story and a Use Case?
A Use Case is a detailed, structured document written upfront. A User Story is a short, lightweight placeholder for a conversation, suited to iterative delivery.
Does a User Story need acceptance criteria?
Yes — without them, a story is just a sentence with nothing to test against or confirm as done.
Free download
Get the Free BA Templates & Toolkit
14 ready-to-use templates: stakeholder register, requirements document, process map, RAID log, and more — built from real BA project experience.
No spam, ever. Unsubscribe any time.
NZ's #1 BA Certification
Become a Certified Better Business Analyst
6-week self-paced certification. Real case studies. Globally recognised credential. From $349 NZD — vs USD $3,000+ for comparable programmes.
30-day money-back guarantee
Benjamen Walsh
Founder, BBA Institute · Certified Business Analyst
Benjamen Walsh is the founder of the Better Business Analysis Institute (BBAI) and a practising business analyst with over a decade of experience delivering change across New Zealand and Australia. He has trained over 200+ business analysts through BBAI certification programmes and hosts The Better Business Analyst Podcast (138+ episodes). Benjamen works with organisations including Corporates, Consultancies, Non for Profits, Small Businesses and the New Zealand Government.
Connect on LinkedIn →