Also: story, acceptance criteria, story format, as a user I want, INVEST
A user story is a short description of a piece of functionality from the perspective of the person who needs it, stating who they are, what they want and why, and carrying acceptance criteria that say when it is done.
Our take. A story is a promise to have a conversation, not a specification, and the template is the least important part of it. Teams that fill in the three-clause sentence and stop have written a requirement in a funny voice. Teams that use the sentence to start an argument about who actually needs this and what they will do with it have understood the practice.
The format most teams use has three clauses: as a kind of user, I want some capability, so that some benefit follows. The first clause forces the writer to name a real person rather than the system; the third forces them to say why, which is the clause most often left blank and most often the one that reveals the story is not worth building. Underneath sit acceptance criteria: the specific, checkable conditions that will be true when the story is done, written ahead of the work, not after it. The story itself stays short because it is meant to be discussed, estimated and built within an iteration, and a story that takes a page to describe is several stories or a specification.
Stories are a practice, not a rule: they appear nowhere in the Scrum guide and originated in an earlier method. They spread because they solve a real problem, which is that specifications written in the system's voice describe what the software does and lose what the person needed, and because a short card is easier to reorder than a chapter. The failure modes are equally real. Stories written by one person and handed over without conversation are specifications with worse grammar. Stories whose acceptance criteria are written after the work are tests of what was built rather than of what was needed. Stories too large to finish in an iteration are epics that were never split, and a backlog full of them cannot be planned.
Letter
Quality
The question to ask
I
Independent
Can this be built and released without waiting for another story?
N
Negotiable
Is there room to discuss how, or has the solution been baked in?
V
Valuable
Does the so-that clause name a benefit somebody would pay for?
E
Estimable
Does the team know enough to say roughly how big it is?
S
Small
Does it fit inside one iteration with room to spare?
T
Testable
Do the acceptance criteria let anyone say yes or no?
In practice
A team receives the story: as an administrator, I want a reporting screen, so that I can see the data. It passes the template and fails everything else. In refinement the team asks who the administrator is and learns it is the finance manager; asks what data and learns it is overdue invoices; asks what she will do with it and learns she phones the customers on the list every Monday. The story becomes: as the finance manager, I want a list of invoices more than thirty days overdue with the customer's phone number, so that I can make Monday's calls without exporting a spreadsheet. The acceptance criteria write themselves, the story is a day's work instead of a month's, and the reporting screen nobody needed is never built.
Stories are one common form for backlog items; the backlog is the ordered list they sit in. Backlog items can also be defects, technical tasks or experiments, and none of those need the story format.
Acceptance criteria are specific to one story and say when that story's need is met. The definition of done applies to every item and says what quality every increment must reach. A story can meet its criteria and still not be done.
A brief describes a whole piece of work a client wants, at the level of purpose and constraints. A story describes one small capability from one user's viewpoint; a brief might decompose into dozens of them.
Key takeaways
→Who, what, why, plus checkable acceptance criteria written before the work.
→The template starts a conversation; a story handed over without one is a specification in disguise.
→Independent, negotiable, valuable, estimable, small, testable: fail one and refine it.
Certifications that test this
Vendor exams whose syllabus covers this concept — facts, cost and a preparation path on each page.
A rotating selection from the course directory, drawn from the subcategories where this concept is taught rather than picked for it. Details, price and the provider link are on the course page.
The course caters for students who wish to add an international dimension to their business education and who are aimin…
Udemy
FAQ
Are user stories part of Scrum?
No. They come from Extreme Programming and are used by most Scrum teams as their backlog item format, but the guide does not mention them. A Scrum team may express its backlog however it likes.
Who writes user stories?
Anyone, and ideally the conversation writes them: the product owner brings the need, the team asks what it means, and the story that survives refinement is the one both understand. Stories written by one person and delivered are the commonest way the practice fails.
How big should a story be?
Small enough to finish comfortably within one iteration, and ideally in a few days. A story that takes the whole sprint is a risk; one that cannot be finished in a sprint is an epic and must be split before it is planned.
Sources
The primary text this definition rests on. Read it before you trust ours.
Cohn, M., User Stories Applied: For Agile Software Development (2004)
Beck, K., Extreme Programming Explained: Embrace Change (1999)
Wake, B., INVEST in Good Stories, and SMART Tasks (2003)
