User Stories and Acceptance Criteria

Given I am recording a run and the timer shows 12:30
When I tap "Pause"
Then the timer stops at 12:30
And the distance stops increasing

Anatomy of a user story

A user storyUser storyA short description of a feature from the user's point of view.Open in glossary → describes a small piece of value from the user’s point of view. It deliberately leaves out how it’s built. Here’s a real-looking ticket from a fitness app called FitTrack:

FIT-482StoryPause a workout3 points

The story (the conversation starter)

As a… runner using the FitTrack app

WHO: a real type of user, not "the system" or "the developer".

I want… to pause my workout

WHAT: the goal in the user’s words. No buttons, screens or tech yet.

so that… a red traffic light doesn’t ruin my pace and time

WHY: the value. It tells you what “working” really means to the user.

Acceptance criteria (the rules)

1. AC1Tapping Pause stops the timer and the distance within 1 second.
2. AC2Paused time is not counted in moving time or average pace.
3. AC3Resume continues from the exact time and distance where I paused.
4. AC4A workout paused for 60 minutes is saved and ended automatically.

Each rule can only pass or fail. That is what makes it testable, and it is exactly what you turn into test cases.

The format is a template, not a law. Some teams write “In order to … as a … I want …”, others drop “so that” for obvious stories. What matters is that everyone can answer who, what and why.

Is it a good story? INVEST in one minute

Teams often check stories against INVEST. You don’t need to memorize it, but each letter hints at a testing problem:

Letter	Means	Why a tester cares
Independent	Can be built and released on its own	You can test it without waiting for three other stories
Negotiable	Details are agreed together	You’re allowed to ask questions and suggest rules
Valuable	Gives value to a user	The “so that” tells you what really matters
Estimable	The team can size it	If nobody can estimate it, nobody can test it either
Small	Fits in one sprintSprintA short, fixed period (often two weeks) in which a team builds and tests a set of work.Open in glossary →	Huge stories hide huge, untested corners
Testable	You can tell when it’s done	This one is your letter

If a story fails T, it isn’t ready. That’s not you being difficult; it’s you saving the team from building the wrong thing.

Acceptance criteria: the rules of the story

Acceptance criteriaAcceptance criteriaConditions a user story must meet to be considered done and accepted.Open in glossary → (often shortened to AC) are the conditions a story must meet to be accepted by the product owner. Good criteria are:

• Testable: each one can clearly pass or fail.
• Specific: real numbers, real messages, real states. “Within 1 second”, not “fast”.
• About behavior, not implementation: what the user sees, not which database table changes.
• Complete enough: they cover the unhappy paths too, not only the happy path.
• Agreed before development starts, so the developer and tester aim at the same target.

Rule-based vs scenario-based criteria

There are two common styles, and many teams mix them.

Style	Looks like	Best for
Rule-based (a checklist)	“Paused time isn’t counted in average pace.”	Simple rules, limits, UI details
Scenario-based (Given/When/Then)	A short story with a start, an action and a result	Flows, state changes, anything with “if this, then that”

Rule-based criteria are quick to write and read. Scenario-based criteria take longer but force you to state the starting situation and the exact result, which is where most gaps hide.

Given / When / Then (Gherkin)

Gherkin is a simple, structured language for writing scenarios. It’s also what tools like Cucumber use to run automated tests, but you don’t need any tool to use it. It’s just a clear way to write criteria.

Keyword	Meaning	Tip
Scenario	A short name for the example	One behavior per scenario
Given	The starting state (the precondition)	Make it concrete: real data, real screen
When	The action the user (or the system) takes	Usually exactly one action
Then	The observable result	Something you can see or measure
And / But	Add more of the step above	Keep it short; many Ands = split the scenario

Example: resuming a workout

Scenario: Resume a paused run
  Given I paused my run at 12:30 and 2.10 km
  And the run has been paused for 2 minutes
  When I tap "Resume"
  Then the timer continues from 12:30
  And the distance continues from 2.10 km
  But the 2 paused minutes are not counted in my average pace

Example: one rule, many inputs

When the same scenario needs several values, use a Scenario Outline with an Examples table. This is boundary value analysisBoundary value analysisTesting values at and just around the edges of valid ranges, where bugs love to hide.Open in glossary → written straight into the criteria:

Scenario Outline: Auto-save a long pause
  Given my run has been paused for <minutes> minutes
  Then the workout is <result>

  Examples:
    | minutes | result                         |
    | 59      | still paused                   |
    | 60      | saved and ended automatically  |

Definition of Ready vs Definition of Done

Two team agreements decide when a story can start and when it can finish. Teams word them differently, but this is the tester’s view:

	Definition of Ready (before work starts)	Definition of Done (before it’s called finished)
Purpose	The story is clear enough to build and test	The story is truly finished, not “done except testing”
Tester checks	AC exist and are testable; designs attached; open questions answered; test data known	All AC pass; bugs fixed or agreed; regressionRegression testingRe-running tests to check that new changes didn't break things that used to work.Open in glossary → checked; tests written or updated
If missing	Raise it in refinement, don’t start	The story stays open

The acceptance criteria are specific to one story. The Definition of Done is the same for every story (for example “code reviewed, tests pass, works on iOS and Android, analytics events added”). A story is finished only when it meets both. The Definition of Ready plays a similar role to entry and exit criteriaEntry and exit criteriaConditions that must be met before a test activity can start (entry) or before it counts as done (exit).Open in glossary → in more formal test processes.

The three amigos and refinement

Refinement (sometimes called backlog grooming) is the meeting where the team discusses upcoming stories. A small version of it is called the three amigos: one person each for business (the product owner), development and testing look at a story together, usually for 15 to 30 minutes.

Each amigo brings a different question:

• Product: what problem are we solving?
• Development: how could we build it, and what’s hard?
• Testing: what could go wrong, and how will we know it works?

The tester’s question list

Area	Example questions
Empty states	What does the screen show with no workouts yet? No GPS signal? (See empty stateEmpty stateThe screen a user sees when there is no content yet, like an empty cart or no search results.Open in glossary →.)
Errors	What if saving fails? What exact error messageError messageText that tells the user something went wrong and, ideally, how to fix it.Open in glossary → appears? Is the user’s data kept?
Limits	Minimum, maximum, how long, how many? What happens at exactly the limit?
Permissions	Who can do this? What if location permission is denied? Free vs premium users?
Offline and interruptions	No network? A phone call? The app killed by the system? (See offline modeOffline modeHow an app behaves without a connection: showing cached content, queuing actions, or explaining what's unavailable.Open in glossary → and interruptionInterruptionAnything that takes the user away from the app mid-task: a call, an alarm, a notification, low battery.Open in glossary →.)
Accessibility	Does a screen readerScreen readerSoftware that reads the screen aloud for blind and low-vision users, like VoiceOver or TalkBack.Open in glossary → announce it? Big enough touch targetsTouch targetThe area of the screen that responds to a tap, which should be large enough for a finger.Open in glossary →? Large text?
Other platforms	iOS and Android? Tablet, web, smartwatch? Lock screen controls?
Analytics	Which events should fire, with which data? How will we know people use it?

Worked example: “Pause a workout”

Let’s refine the FitTrack story from the start of the lesson.

Every line here is fog. “Handled correctly” how? “Work well” means what? Here are the questions the tester brought, and the answers from the product owner:

Question	Answer
Is paused time counted in moving time and pace?	No. Total time includes it, moving time and pace don’t.
How long can a run stay paused?	60 minutes, then it’s saved and ended with a notification.
What if the system closes the app while paused?	Reopening restores the paused workout exactly.
Can I pause from the lock screen or watch?	Lock screen: yes (iOS Live Activity, Android notification). Watch: separate story.
Does GPS keep running while paused?	No, to save battery. It restarts on Resume.
What does VoiceOver/TalkBack say?	“Pause workout” / “Resume workout”; state change is announced.
Analytics?	workout_paused and workout_resumed, with elapsed time.

The refined criteria

Rules

• Total time includes paused time; moving time and average pace don’t.
• GPS tracking stops while paused and restarts on Resume.
• The Pause button has the accessible label “Pause workout” and is at least 44×44 pt on iOS and 48×48 dp on Android.
• workout_paused and workout_resumed events are sent with the elapsed time.

Scenarios

Scenario: Pause a running workout
  Given I am recording a run and the timer shows 12:30
  When I tap "Pause"
  Then the timer stops at 12:30 within 1 second
  And the distance stops increasing
  And I see the buttons "Resume" and "End"

Scenario: Resume after a pause
  Given I paused my run at 12:30 and 2.10 km two minutes ago
  When I tap "Resume"
  Then the timer continues from 12:30
  And moving time and average pace do not include the 2 paused minutes

Scenario: Paused for too long
  Given my run has been paused for 60 minutes
  Then the workout is saved and ended automatically
  And I get the notification "Workout saved after 60 minutes paused"

Scenario: App closed by the system while paused
  Given my run is paused at 12:30 and 2.10 km
  When the system closes FitTrack in the background and I open it again
  Then I see my paused run at 12:30 and 2.10 km with "Resume" and "End"

Scenario: Pause from the lock screen
  Given I am recording a run and my phone is locked
  When I tap "Pause" on the lock screen controls
  Then the workout pauses
  And the app shows the paused state when I unlock the phone

Notice what happened: the watch question became a separate story, not a bigger one. Splitting is a perfectly good outcome of refinement.

From criteria to test cases

Each scenario becomes at least one test caseTest caseA written set of steps, data and an expected result used to check one specific behavior.Open in glossary → (see How to Write Test Cases); limits become two (one on each side). Rules often become extra checks or a checklistChecklistA simple list of things to check, lighter and faster to use than full test cases.Open in glossary →. Here are four of them:

The fifth case, exactly 60 minutes, completes the boundary pair with TC-PAUSE-003. Linking each case back to FIT-482 and its AC is what builds a traceability matrixTraceability matrixA table linking each requirement to the test cases that cover it.Open in glossary →.

Spotting and fixing untestable criteria

Untestable criteria nearly always hide behind a few fog words. When you see one, ask “how would we know?” and replace it with a number, a message or a state.

Fog word	Ask	Measurable rewrite
fast, quickly	How fast, on what network?	“Results appear within 2 s on 4G”
user-friendly, easy	Easy for whom, compared to what?	“Checkout has at most 3 screens; each field has a visible label”
gracefully, properly	What should the user see?	“Shows ‘Upload failed. Try again.’ and keeps the photo”
all, every, any	Which ones, exactly?	“iOS 17+ and Android 10+”
modern, nice	Compared to what?	“Matches the approved design v3”
etc., and so on	What else, exactly?	List the remaining items

Some qualities really are hard to pin down, like “the onboarding feels welcoming”. That’s fine: test them with people (usability sessions) and say so, instead of pretending a checklist covers it.

Common mistakes

Templates you can copy

STORY
As a <type of user>
I want <goal>
so that <value>

RULES
- <rule with a number, message or state>

SCENARIOS
Scenario: <one behavior>
  Given <starting situation with real data>
  When <one action>
  Then <observable result>
  And <another observable result>

OPEN QUESTIONS
- <question> (owner, date)