User Story
- In Turkish
- kullanıcı hikâyesi
In short
A user story is a short, plain-language description of a feature told from the user's point of view, explaining who wants it, what they want, and why.
What is a user story?
A user story is a small unit of work written from the perspective of the person who will benefit from it. Instead of a technical specification, it describes a need in everyday language, usually with the template: As a [type of user], I want [some goal] so that [some reason]. User stories came from Extreme Programming (XP) and are now used by most Agile teams, including those using Scrum and Kanban.
A story is intentionally brief; it is a placeholder for a conversation between the team and the people who understand the need. Ron Jeffries described this as the three Cs: the Card (the short written story), the Conversation (discussing the details), and the Confirmation (acceptance criteria that show when the story is complete). Acceptance criteria are often written in a Given/When/Then format, which also makes them easy to turn into automated tests.
Good stories are commonly checked against the INVEST checklist: Independent, Negotiable, Valuable, Estimable, Small, and Testable. A story too large to finish in one sprint is called an epic and is split into smaller stories. Think of stories as orders at a restaurant: asking for a nut-free vegetarian meal for your child tells the kitchen what matters without dictating the recipe.
A user story is often confused with a task or a requirement. A task describes technical work, such as creating a database table, while a story describes value to a user and may need several tasks to deliver. A use case, another common format, is more detailed and describes step-by-step interactions between a user and a system.
Key takeaways
- A user story describes a need from the user's point of view, not a technical design.
- The common template is: As a [user], I want [goal] so that [reason].
- Acceptance criteria define when a story is complete.
- Large stories are called epics and are split into smaller ones.
- The INVEST checklist helps teams write good stories.
Example
Title: Reset password by email
As a registered customer,
I want to reset my password using my email address,
so that I can get back into my account if I forget it.
Acceptance criteria:
- Given I am on the login page,
when I click "Forgot password" and enter my email,
then I receive a reset link within 5 minutes.
- Given I open a reset link older than 1 hour,
then I see a message that the link has expired.Readers ask
What is the difference between a user story and an epic?
An epic is a large body of work that is too big to finish in a single sprint. It is broken down into several smaller user stories that can each be completed and delivered on their own.
Who writes user stories?
Anyone on the team can write them, but the Product Owner or product manager is usually responsible for making sure the most valuable stories are in the backlog and clearly understood.
What are acceptance criteria?
Acceptance criteria are specific conditions a story must meet to be accepted as complete, such as expected behavior or edge cases. They belong to one story, unlike the definition of done, which applies to all work.
See also
- AgileTeams & Process, p. 2Agile is an approach to software development that delivers working software in small, frequent increments and adjusts plans based on regular feedback.
- ScrumTeams & Process, p. 21Scrum is an Agile framework in which a small team delivers a product in fixed-length cycles called sprints, using defined roles, events, and artifacts.
- Story PointsTeams & Process, p. 28Story points are a unit Agile teams use to estimate the relative size of work items, combining complexity, amount of work, and uncertainty rather than hours.
- Definition of DoneTeams & Process, p. 7The Definition of Done is a shared checklist of quality standards that every piece of work must meet before a team can consider it complete.
- SprintTeams & Process, p. 26A sprint is a fixed-length period of one month or less, often two weeks, in which a Scrum team works toward one goal and produces a usable product increment.
- MVPTeams & Process, p. 13An MVP is the simplest version of a product that real users can use, built to test a key assumption and learn as much as possible with the least effort.
Spotted a mistake or something missing on this page?Suggest an edit