User Story Training
Writing Great User Stories for Agile Teams
User Stories
3 Cs
INVEST
Acceptance Criteria
S.P.I.D.R.
CRUD
A tool and technique for capturing software features
A User Story is a tool/technique used in Agile software development to capture a description of a software feature from the end user's perspective. It is more than just documentation — it is a trigger for conversation between the Product Owner and the Development Team.
A user story creates a simplified description of a software requirement that starts a conversation between the Product Owner and the Development Team — and sometimes the Stakeholders. The conversation is where the real detail lives, not the card.
The three-part sentence that drives everything
As a logged in user, I need to be able to update my contact information, so that your organization can successfully contact me.
💡 A user story is written as a single sentence. If it takes multiple sentences to describe, the story may be too large and should be split into smaller stories.
Agile vs Waterfall documentation
| Waterfall Works When… | Agile Works Best When… |
|---|---|
| What we know far exceeds what we don't know | What we DON'T know far exceeds what we know |
| Processes are well established and well defined | Processes are not well established or defined — or non-existent! |
| Everyone already has the needed domain knowledge | We are seeking continuous improvement of our processes |
| We are NOT trying to learn through validated experimentation | No one has ALL the needed domain knowledge |
| We are actively trying to learn through validated experimentation |
How to use user stories effectively
A user story should be small — small enough to fit onto a single index card. Keep it concise and focused.
A user story is a pointer to a conversation needed between the Product Owner and the developers. The card starts the discussion.
A user story is testable — it is independently confirmable. The acceptance criteria provide this confirmation.
| I | Independent | Of all the other stories — can be developed without depending on another unfinished story |
| N | Negotiable | Not an immutable contract — the details and approach can evolve through conversation |
| V | Valuable | Delivers clear value to the intended user — not just technical work |
| E | Estimable | Capable of being sized — the team has enough information to estimate it |
| S | Small | Small enough to complete in a single Sprint — if not, split it |
| T | Testable | Independently verifiable — has clear acceptance criteria that can be confirmed |
The formula behind every great user story
| Part | What It Means | Example |
|---|---|---|
| Who… | The user having the problem or need | As a registered user, |
| What… | The action the user needs to take | I need to reset my password, |
| Why… | The value or goal they want to achieve | So that I can regain access to my account. |
🎯 Who + What + Why = Value!
"As a registered user, I need to reset my password, so that I can regain access to my account in your software."
Defining the 'Who' before you write stories
Before writing the "who," make a list of every type of user that will interact with the software. You will likely only need to do this once — then reference these personas in all future stories.
Full system access — manages other administrators and all top-level settings across the platform.
Elevated access — manages users, content, and operational settings within their defined scope.
Authenticated user with a profile — can access personalized features and saved preferences.
Anonymous visitor — limited access, no saved state. Often the target for onboarding stories.
Step by step from a real customer problem
📧 "Help! I forgot my password to your software and now I can't log in! Please help! I've got work I need to do and I wanted to go online and do it, but I can't get in and my boss really needs this and I don't know what to do. Please help. PLEASE. HALP!"
| Step | What to Do | Result |
|---|---|---|
| 1. Start with Who | Start with the user having the problem | As a registered user, |
| 2. Continue with What | Define the problem in terms of the action the user needs to take | I need to reset my password, |
| 3. Finish with Why | Define the goal or desired outcome | So that I can regain access to my account. |
"As a registered user, I need to reset my password, so that I can regain access to my account in your software."
Turning questions into testable conditions
Acceptance Criteria are all of the things that need to be true for the story to be considered complete. They are listed as bullet points under the user story and answer all the questions the story doesn't spell out.
From epics down to tasks — and the CRUD shortcut
Use this hierarchy: Epic › Feature › Story › Task. Bigger stories are broken down until they are actionable. The acceptance criteria of the parent story (the feature) can become independent, but related, child stories!
Whenever you see the word "manage" in an epic, that's almost always 4 stories: Create · Read · Update · Delete.
As a super administrator, I need to be able to create administrator accounts, so that I can ensure only authorized employees have administrator access.
As a super administrator, I need to be able to read (view) administrator accounts, so that I can ensure only authorized employees have administrator access.
As a super administrator, I need to be able to update administrator accounts, so that I can ensure only authorized employees have administrator access.
As a super administrator, I need to be able to delete administrator accounts, so that I can ensure only authorized employees have administrator access.
Five proven ways to break up large stories
When stories are simply too big to complete in a Sprint, Product Owners need to split them up. Use S.P.I.D.R. as your guide for how to split them effectively.
Practical Agile Mentoring · mickymarvels.info · +1 (213) 440-2770