Lesson 04
How to write stories that drive development and manage a backlog that delivers value.
A user story is a short, simple description of a feature told from the perspective of the person who desires it. It follows a specific template that keeps the focus on who needs it, what they need, and why they need it.
As a [persona/role],
I want [goal/desire],
so that [benefit/value].Every story answers three questions: Who is the user? What do they want? Why does it matter?
# Good user stories
As a new customer,
I want to sign up with my Google account,
so that I don't have to create yet another password.
As a team lead,
I want to see a dashboard of sprint progress,
so that I can identify blockers before the daily standup.
As a mobile user,
I want to receive push notifications for order updates,
so that I don't have to keep checking the app.Avoid stories like: "As a developer, I want to refactor the database layer, so that the code is cleaner." This is a technical task, not a user story. If refactoring is needed, tie it to user value: "As a user, I want the search page to load in under 2 seconds, so that I can find products quickly." The refactoring becomes the how, not the what.
Good user stories follow the INVEST acronym. Use this as a checklist when writing or refining stories.
| Letter | Criterion | Meaning | Test Question |
|---|---|---|---|
| I | Independent | Stories should not depend on each other | Can this be built and delivered without waiting for another story? |
| N | Negotiable | Details are discussed, not dictated upfront | Is there room for the team to decide the best implementation? |
| V | Valuable | Delivers value to the user or business | Would a user or stakeholder care if this was done? |
| E | Estimable | The team can estimate its size | Does the team understand enough to give it a story point value? |
| S | Small | Fits within a single sprint | Can this be completed, tested, and reviewed within one sprint? |
| T | Testable | Has clear acceptance criteria to verify | Can we write a test or scenario that proves this is done? |
Acceptance criteria define the conditions that must be met for a story to be considered "done." They bridge the gap between the story's intent and the developer's implementation. We use the Given/When/Then format (from Behavior-Driven Development).
# Story: Sign up with Google account
## Acceptance Criteria
Scenario 1: Successful sign-up
Given I am on the registration page
When I click "Sign up with Google"
And I authorize the application in Google's OAuth screen
Then I should be redirected to the onboarding page
And my account should be created with my Google email
And I should receive a welcome email
Scenario 2: Existing account
Given I already have an account with my Google email
When I click "Sign up with Google"
Then I should be logged in to my existing account
And I should see a message "Welcome back!"
Scenario 3: Authorization denied
Given I am on the registration page
When I click "Sign up with Google"
And I deny authorization in Google's OAuth screen
Then I should be returned to the registration page
And I should see an error message explaining the issueThis format is powerful because it is precise enough to automate (these can become integration tests) but readable enough for non-technical stakeholders to review. The Product Owner can validate that the scenarios match their intent before any code is written.
Story points measure the relative effort of a story — not hours or days. They account for complexity, uncertainty, and volume of work. Teams use a modified Fibonacci sequence because the gaps between numbers grow as uncertainty increases.
| Points | Effort | Example |
|---|---|---|
| 1 | Tiny | Fix a typo |
| 2 | Small | Add a field to a form |
| 3 | Medium | New API endpoint |
| 5 | Large | New feature |
| 8 | XLarge | Multi-page flow |
| 13 | Huge | Major refactor |
| 21 | Epic | Needs splitting |
If a story is estimated at 13 or more points, it is almost certainly too large for a single sprint. Break it down into smaller, independently deliverable stories. A 13-point story often hides multiple concerns that will cause problems during implementation. Use /agile-story-split to decompose oversized stories into smaller, independent pieces that each meet the INVEST criteria.
The Product Backlog is a living document. It is never "done." The Product Owner continuously refines it — adding new stories, removing obsolete ones, re-prioritizing based on new information, and splitting stories that are too large.
| Factor | Question | Impact on Priority |
|---|---|---|
| Business Value | How much value does this deliver to users or the business? | High value = higher priority |
| Risk | Does this reduce technical or business risk? | High risk reduction = higher priority |
| Dependencies | Do other stories depend on this being done first? | Blocking dependencies = higher priority |
| Effort | How much effort relative to value? | Low effort + high value = highest priority |
| Time Sensitivity | Is there a deadline or market window? | Time-bound items may jump the queue |
Before a story can be pulled into a sprint, it must meet the Definition of Ready (DoR). This prevents the team from committing to work that isn't well-understood enough to estimate or implement.
Here is what a well-written, sprint-ready story looks like in practice.
Points: 5 • Priority: High • Sprint: 3
As a new customer,
I want to sign up with my Google account,
so that I don't have to create yet another password.
A user story describes what the user wants. Tasks describe how the team will build it. During sprint planning, the team breaks each story into technical tasks. Stories are estimated in points; tasks can optionally be estimated in hours for capacity planning.
What does the I in the INVEST criteria stand for?