User Stories

Why it matters

A story is short on purpose, so what it leaves out is decided in conversations. When the tester is not part of them, the gaps show up late: during testing, as defects or as arguments about what the story meant. A story that is too big has another cost: it is finished in the last days of the iteration, and its testing is squeezed or moved to the next one.

For a tester, stories are the earliest point of influence. Asking "how will we know this works?" while the story is still a card is static testing at its cheapest: a vague benefit or a missing rule costs one question now, and a reopened story and a reworked feature later. Small, testable stories also make test design easier: each one has clear acceptance criteria, known test data and a clear moment when it is done.

The story format and the 3 Cs

The ISTQB Foundation syllabus describes the most common format: As a [role], I want [goal], so that [benefit], followed by acceptance criteria. It also uses Ron Jeffries’ 3 Cs, three aspects that together make a story: the Card, the Conversation and the Confirmation. The Card is the medium that holds the story, a paper index card or an entry on an electronic board or tracker, and it carries the one sentence with its role, goal and benefit. Each part gives a tester something to work with:

• Card, role: who uses the feature. It tells you which user, and which permissions, to test with.
• Card, goal: what the user wants to achieve, not how the screen should look. It becomes the main path you test.
• Card, benefit: why the user wants it, so that you can judge whether the feature meets the need. In the example below: is an SMS sent at the moment the order leaves the depot early enough for the customer to get home?
• Conversation: the discussion in which the details are agreed, spoken or written. The card is short on purpose, and decisions that are not written back onto it are lost by the time the story reaches testing.
• Confirmation: the acceptance criteria that say when the story is done. They are the starting point of your test cases; the next lesson covers how to write them.

STORY-214  Delivery SMS
As a customer waiting for a delivery,
I want an SMS when my order is out for delivery,
so that I can be there to receive it.

Conversation (decisions written back after refinement)
- Send the SMS to the phone number on the order, not the one on the account.
- Send it in the language the order was placed in (Arabic or English).
- If the status is set twice, send one SMS only.

Confirmation (acceptance criteria)
AC1  When the order status changes to "Out for delivery", one SMS is sent
     to the phone number on the order within 2 minutes.
AC2  The SMS contains the order number and the delivery time window.
AC3  Orders collected from a store get no delivery SMS.

Try it: User Story → Test Scenarios

INVEST: six questions for a good story

INVEST is an acronym from Bill Wake, also used in the ISTQB syllabus, for six qualities of a good story. Use the letters as questions in refinement, not as a form to fill in. Each of them matters for testing.

Testable is the quality a tester is best placed to judge. The syllabus notes that when stakeholders do not know how to test a story, the story may be unclear, may not reflect something valuable to them, or they may simply need help with testing. Each of these is worth finding out before the story is built.

• Independent: can it be built, tested and released without waiting for another story? Dependencies decide the order of testing and the test data you need.
• Negotiable: it states a need, not a fixed design. The details are agreed in conversation, so ask before you assume.
• Valuable: a user or customer gets something from it. A "story" that delivers nothing on its own, such as a database table, cannot be tested from the user’s side.
• Estimable: the team can size it, testing included. If nobody can say how it will be tested, it usually cannot be estimated either.
• Small: it fits comfortably into one iteration together with its testing. Big stories push testing into the last days.
• Testable: there is a way to decide that it is done. Words such as "fast", "easy" or "better" need a measurable meaning before work starts.

Try it: AI Requirement Ambiguity Detector

Splitting a story that is too big

A story too big to finish in one iteration is often called an epic. Split it so that each smaller story is still a vertical slice: it passes through every layer the feature needs, from the screen through the API to the database, and gives a user something they can try.

Take the epic "As a customer, I want to return items online, so that I get my money back without calling support." Split by layer, it becomes a returns table, a returns API and a returns screen: no user can try any of them, nothing can be tested end to end until all three are done, and integration defects appear at the end. Split into slices, the first story is "return a whole delivered order and refund the original payment method": small but complete, so it can be tested as soon as it is done, and the layers meet in the first story. Useful ways to split:

• By workflow step: deliver the simplest end-to-end path first and add the other steps later, for example request a return now and book a courier pickup in a later story.
• By business rule: one rule, or one variation of a rule, per story, for example a whole order first, then selected items, then the refusals for late returns and gift cards.
• By path: the main success path first, then each error or exception path as its own story with its own acceptance criteria, planned rather than left for "later, if there is time".
• By data or channel: one payment method, file type or platform first, and the others in follow-up stories.
• By operation: create, view, change and delete as separate stories when each one is useful on its own.
• Spike: when the team cannot estimate because something is unknown, such as an external API, a short time-boxed investigation finds the answer, and the real story is written afterwards. A spike produces knowledge, not a feature to test.

Worked example: the tester in refinement

The product owner brings the returns epic to refinement. Beforehand, the tester has read it together with the returns rule BR-03 from the lesson on business rules (returns within 14 days of delivery, never for gift cards) and the courier company’s API notes. In the meeting the tester checks the epic against INVEST and raises the points listed below.

The team then agrees the split shown after the list. The tester checks that each new story can be tested on its own, that RET-3 keeps the "otherwise" outcome of BR-03, and that the test data is known: orders delivered 14 and 15 days ago, and an order that contains a gift card. The answers are written into the stories, and each story gets acceptance criteria before it counts as ready.

• Not Small, not Estimable: the epic hides item selection, partial refunds, two refund methods, courier pickup and refusals.
• Not Testable as written: "get my money back" says neither how much nor by when. Is the delivery fee refunded?
• Not Independent: pickup depends on a courier API that nobody on the team has used.
• Open questions: from which moment do the 14 days start, and in which time zone? Can a customer cancel a return? What does the customer see while the refund is pending?

Epic: Online returns
RET-1  Return a whole delivered order; refund to the original payment method
RET-2  Return selected items from an order; refund only those items
RET-3  Refuse returns after 14 days or for gift cards, and show the reason
RET-4  Spike, 2 days: can the courier API book pickups? Write RET-5 from the answer
RET-5  Book a courier pickup for a return
RET-6  Refund to the in-app wallet instead of the card

Decisions recorded in the stories:
- The delivery fee is refunded only when the whole order is returned.
- The 14 days start at the delivery scan, in Saudi Arabia time (UTC+3).

Try it: Acceptance Criteria Generator Try it: User Story → Test Cases

Frequently asked questions

References

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• Certified Tester Foundation Level Agile Tester (CTFL-AT)ISTQBISTQB's foundation-level extension on testing within agile teams; ISTQB is retiring it (English exams until 6 May 2027) in favour of CTFL v4.0 and CTAL-AT.
• Agile Testing: A Practical Guide for Testers and Agile Teams (Lisa Crispin, Janet Gregory)Addison-Wesley (Pearson) · 2009The agile testing quadrants and how testers work inside a delivery team — the basis of "testing at the right layer".
• ISTQB GlossaryISTQBThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.