User story
Unlike traditional specification documents, a user story is not a closed contract: it is a starting point for conversation. Ron Jeffries described this idea with the three Cs: Card, Conversation, and Confirmation. The card is the physical or digital medium; the conversation is the dialogue between the team and the Product Owner that provides the real context; and the confirmation is the acceptance criteria that determine when the story is done.
Structure
The structure of a user story includes:
- Name: short and descriptive. It is used as a reference in the Product Backlog and in team conversations.
- Description: usually expressed with the formula As a [type of user], I want [functionality], so that [benefit]. It describes who needs the functionality, what they need, and why.
- Acceptance criteria: conditions that must be met for the Product Owner to consider the story done and acceptable.
- Additional information: priority, risk, size estimate, or other fields the team needs to manage the backlog.
The As a / I want / So that format
The most widespread format for writing the description of a story follows this template:
'As a' [type of user], I want [action or functionality], so that [benefit or outcome].
Example: As a registered customer, I want to recover my password by email, so that I can access my account if I forget it.
The so that part is the most important and the most frequently omitted: stating the benefit forces whoever writes the story to think about the real value it delivers, not just the technical functionality.
The six INVEST characteristics
The INVEST method was formulated by Bill Wake in 2003 and popularized by Mike Cohn in User Stories Applied (2004). It is used to check the quality of a story by verifying that it meets six characteristics:
- I — Independent: can be planned and implemented in any order. Dependencies between stories should be reduced by combining or splitting them.
- N — Negotiable: it is an open description, not a closed contract. The details are agreed on in the conversation; the story should not impose the how.
- V — Valuable: it delivers value to the customer or user. A good practice is for them to be the ones who write or validate it.
- E — Estimable: the team can assign it a size with enough accuracy to prioritize it. If it cannot be estimated, this usually indicates that it is poorly defined or that the team lacks the necessary knowledge.
- S — Small: can be completed in a few weeks by one person, ideally in days. A short description helps keep its size in check.
- T — Testable: it has clear acceptance criteria. If it cannot be tested, either it is not clear enough or it is not valuable enough.
From Themes and Epics to Tasks
User stories are organized into levels of granularity:
- Theme: a grouping of related epics or stories by business objective or functional area.
- Epic: a story too large to be completed in a single sprint. It must be split into smaller stories before being added to an iteration.
- User story: the working level of the sprint. Can be completed in days or a few weeks.
- Task: the internal breakdown of a story to make daily tracking easier.
AI as a Tool for User Stories
Generative AI tools can be used as support in some phases of working with user stories:
- Generating variants: starting from a need identified in a user interview, a language model can generate draft stories in the As a/I want/So that format to serve as a starting point for the team's conversation.
- Detecting ambiguities: AI can analyze stories that have already been written and identify acceptance criteria that might be missing, inconsistencies between related stories, or terms open to multiple interpretations.
- Suggesting splits: for large epics, AI can propose ways to split them by applying strategies such as SPIDR (Spike, Path, Interface, Data, Rules).
AI does not understand real users. Language models generate stories that sound right because they have seen thousands of similar examples, but they have no direct experience with your product's users. A backlog full of perfectly formatted stories with detailed AI-generated acceptance criteria can look complete and still solve no real problem. AI can help process and organize information, but it cannot replace conversations with real users. Every story generated with AI support requires human validation before it is brought into the sprint.
Best practice tips
- Always write the what, avoid the how.
- Don't write an exhaustive description: just enough to recall the conversation.
- Write the acceptance criteria explicitly enough.
- Size the stories. It helps to know whether a story fits within the team's work cycle, and to do so it is enough to compare it with what has already been delivered (sizing against the service level expectation) or to estimate it, depending on what the team has agreed. What creates false expectations is treating the estimate as a date commitment.
- Don't entrust all the information to the cards: supplement with external documentation when necessary.
- Never consider a story done before all the acceptance criteria are met.
Common mistake
Writing the story as a technical task instead of as value for the user. "Create the users table in the database" is not a user story: it does not describe any benefit for anyone. Stories talk about outcomes for whoever uses the system, not about technical implementation. If the story cannot be naturally expressed in the As a/I want/So that format, it is probably a technical task that belongs inside another story.
Resources
🏦 Skill User storiesState of the art and development guide · Skill Arena
📄 Historias de usuario v.5.0 [User Stories v.5.0, in Spanish]Free download · Scrum Manager · Jan 2026
📄 Product Owner v.2.0 [in Spanish]Free download · Scrum Manager
📄 Scrum Master en equipos con IA v.1.0 [Scrum Master in Teams with AI v.1.0, in Spanish]Free download · Scrum Manager
📄 Cómo se crea una historia de usuario [How to Create a User Story, in Spanish]Scrum Manager Blog · Jan 2023
References
- Cohn, Mike. (2004). User Stories Applied: For Agile Software Development. Addison-Wesley.
- Jeffries, Ron. (2001). "Essential XP: Card, Conversation, Confirmation". XProgramming.com.
- Wake, Bill. (2003). "INVEST in Good Stories, and SMART Tasks". XP123.
See also
Want to advance in agility? You can search for course and exam calls or go at your own pace by becoming a member of the Agile Club. This membership includes exclusive resources, e-learning classrooms, and access to Skill Arena: a space to practice and measure your agile skills at your own pace.