User stories are the currency of an Agile backlog. They describe a piece of value from the perspective of the person who needs it — not the system that delivers it. Written well, they keep the team focused on outcomes rather than outputs.
The story format
The standard user story template is: As a [type of user], I want [some goal] so that [some reason]. This structure forces three things: it names who benefits, what they need, and why it matters. All three parts do real work.
A weak story ignores the 'so that' clause: 'As a user, I want a dashboard.' A stronger story names the outcome: 'As a sales manager, I want a dashboard showing my team's open pipeline so that I can identify deals at risk before our weekly meeting.' The second version tells the developer what success actually looks like.
User stories are not requirements documents. They're a placeholder for a conversation. The real value is in the discussion between the Product Owner, the developers, and any other relevant people — the story is a prompt for that discussion, not a substitute for it.
Acceptance criteria
Acceptance criteria define the conditions that must be true for the story to be considered done. They make 'done' concrete and shared, so there's no ambiguity at the end of the sprint about whether the story was completed.
Good acceptance criteria are written in plain language and testable. 'The dashboard loads in under two seconds' is testable. 'The dashboard is fast' is not. 'The user receives an email confirmation within five minutes of submitting a form' is testable. 'The confirmation is sent promptly' is not.
A common format is Given/When/Then: Given [some context], When [some action], Then [some outcome]. For example: Given I am a logged-in sales manager, When I open the dashboard, Then I see my team's open deals grouped by stage with the total value for each stage displayed.
What makes a good story: INVEST
The INVEST acronym is a useful checklist for story quality. Independent: the story can be built and delivered without depending on another incomplete story. Negotiable: the details are open for discussion — it's not a contract. Valuable: it delivers something a real user cares about. Estimable: the team can size it. Small: it fits comfortably within a sprint. Testable: there's a clear way to confirm it's done.
Stories that fail the Independent test create scheduling headaches — two stories that must be done together are really one story. Stories that fail the Small test are often called epics and need to be broken down before they enter a sprint. Splitting a large story into smaller independent ones is a skill that develops with practice.
When you're looking at a backlog full of vague, enormous, or untestable stories, the product isn't ready for sprint planning. Backlog refinement — the ongoing work of getting stories to a ready state — is what prevents planning sessions from grinding to a halt.
Summary & next steps
User stories describe work from the user's perspective using the As a / I want / So that format. Acceptance criteria make done concrete and testable. The INVEST checklist — Independent, Negotiable, Valuable, Estimable, Small, Testable — is your quality filter for backlog items.
The final lesson in this course looks at the Agile mindset — the values and principles that sit underneath all the frameworks and practices, and that separate teams that are truly Agile from those that are just following a process.