What a story is
In short: A story says who wants something, what they want and why, in one sentence. It is not a specification: the details come in the conversation, and the confirmation says how we will know it is done. A developer task and a layer are not stories, because nobody can try them on their own.
Problem
The request in one line
The team's task list has a line: "Promo codes". The developer builds a code field that takes 10 % off the whole order. The tester checks that 10 % comes off. Everything passes.
At release, marketing asks why the code also works on discounted products. Accounting asks where they can see how much discount was given this month. Nobody did their part wrong. The line "Promo codes" never said who it was for or why.
The idea
Who, what, why
A user story states one need in one sentence with three parts:
As a [role] I want [goal] so that [benefit].
As a regular customer I want to enter a promo code in the cart so that I pay less for the order.
- The role is the person who has the need. Not "the user" in general, but a customer, a warehouse worker, an accountant. These are the stakeholders from the previous module.
- The goal is what they want to do, in their words, with no buttons or tables.
- The benefit is why. It is the most valuable part, because the solution is validated against it: if the code field works but the customer still does not pay less, the story is not met.
A story is a small requirement, written so that it starts a conversation. In this course we say story.
More precisely, if you are curious
The template "As a …, I want …, so that …" is linked to a team at the British company Connextra around 2001, and became well known through Mike Cohn's book "User Stories Applied" (2004). ISTQB CTFL v4.0.1 (section 4.5, collaboration-based test approaches) gives the same template: a role, a goal, and the business value for the role.
The template is not mandatory. Some teams write "In order to …, as a …, I want …" to put the benefit first. What matters is that all three parts are there.
Try it
A story or not?
The idea
The three Cs
One sentence cannot carry everything about promo codes. And it should not. Ron Jeffries, one of the creators of Extreme Programming, describes a story with three words that start with C. They are called the three Cs:
- Card. The story is short enough to fit on a small card. The card is not the requirement; it is a reminder that a conversation is needed.
- Conversation. The details are worked out in a conversation between the people who know: the business, QA and the developer. That is where the questions "what about discounted products?" and "what if the code is used twice?" come up.
- Confirmation. How will we know the story is done? With concrete rules and examples that can be checked. They are written before the work.
The promo code story had a card. It had no conversation, so it had no confirmation either. That is why "done" meant "the developer stopped".
More precisely, if you are curious
Jeffries described the three Cs in an article in 2001. ISTQB CTFL v4.0.1 lists them in the section on collaborative user story writing and ties the confirmation to the acceptance criteria. The criteria are the topic of the lesson "Acceptance criteria" in this module.
The idea
What a story is not
Three things are most often mistaken for a story:
- A specification. A story does not list everything. If the card becomes a page with every case, the conversation will not happen, and what is written will still be incomplete. The details are written down after the conversation, as rules and examples.
- A task for the developer. "Add a code field to the payment page" says what to do, but not for whom or why. Tasks are fine, but they come after the story, when the team decides how to build it.
- A layer of the system. "The promo code backend" or "the cart screen" are parts of the solution. Nobody can try them on their own and say "yes, this is what I wanted".
And one more: "As the system I want…" is not a story. The system has no needs. Behind every "as the system" there is a person we have not found yet.
Try it
Which “so that” is a benefit?
In each question, pick the end of the story that states the real benefit.
The idea
Why the benefit matters
The benefit does two things.
First, the story is validated against it. "So that I can decide whether to add something more to reach 50.00 €" says that showing the delivery after payment is not enough. It has to be visible in the cart, while the customer is still choosing.
Second, it opens better solutions. The accountant asks for an Excel button. The benefit is "so that I can reconcile with the bank". Maybe the better solution is a ready report that arrives on its own. This is the same habit as in the lesson on elicitation: the need behind the requested solution.
If you cannot write the benefit, that is a sign. Either you do not know why the story is being built, or it is not needed. In both cases the next step is a question, not work.
Exercise
From request to story
1. Which story states the need? Three requests from stakeholders, each with three attempts to write it down.
Test