We’ll start by taking a look at this short video together:
Below is a written summary of what a user story is in the context of Agile software development methodologies.
NOTE
Mr. Gordon discussed this concept with the ChatGPT 5 Thinking large language model, which produced the summary below in a format suitable for our use in class. Mr. Gordon then edited the content for clarity.
What is a user story?
A one-sentence description of a real person’s need.
Template
“As a [who], I want [what], so that [why].”
How to write user stories
- Stay user-centred and outcome-focused
- Slice work into small, testable chunks
- Make “done” clear for everyone
What are acceptance criteria?
This is how we know that the feature a story describes has been implemented.
Template
“Given [context or pre-condition], when [some action is carried out], then [observable outcome].”
How to write acceptance criteria
- Write short bullets in a Given / When / Then style.
- Include typical behaviour (sometimes called the “happy path”).
- Then proceed to consider edge cases – when users might do something unexpected.
Quality check (INVEST, simplified)
- Independent — can be built on its own
- Negotiable — details can change during dev
- Valuable — a real user benefits
- Estimable — you can roughly size the effort
- Small — fits in a short sprint
- Testable — you can verify it objectively
Examples
The following examples are provided within the context of an attendance taking app being written for use within a school.
Teacher takes attendance
User story
As a teacher, I want to mark each student Present/Absent/Late quickly at the start of class, so that I can begin teaching on time and records are accurate.
Acceptance criteria (Given / When / Then)
-
Given I select today’s class and section, when the attendance screen opens, then the full roster loads in ≤ 2 seconds.
-
Given the roster is visible, when I tap a student, then their status cycles: Unmarked → Present → Absent → Late.
-
Given I set “Late,” when prompted, then I can enter minutes late (0–60) and an optional note.
-
Given I’m mid-class with spotty Wi-Fi, when I mark statuses, then changes save locally and then auto-sync when the network returns.
-
Given I’ve submitted, when I view the summary, then I see counts for Present/Absent/Late and the timestamp of submission.
-
Edge case: Given a student isn’t on the roster, when I search their name/ID, then I can add a temporary entry flagged for office review.
-
Edge case: Given I already submitted for this period, when I reopen the screen, then I can still edit and re-submit, with a change log stored.
Student self-check-in (late)
User story
As a student arriving late, I want to scan my ID at a hallway kiosk to record that I’m late, so that my teacher and the office are notified automatically.
Acceptance criteria (Given / When / Then)
-
Given the kiosk is on the school network, when I scan my ID card or type my student number, then my name and current course/period appear.
-
Given I confirm it’s me, when I choose a reason (bus delay, appointment, other) and tap submit, then the system records Late with a timestamp.
-
Given my entry is saved, when processing completes, then my teacher and attendance office receive a notification within 10 seconds.
-
Edge case: Given an invalid/unknown ID, when scanned, then the kiosk shows a clear error and offers “Try again” or “Call office.”
-
Edge case: Given I already checked in for this period, when I scan again, then I see “Already recorded at HH:MM” and no duplicate is created.
-
Privacy: Given I finish, when 5 seconds pass, then the kiosk clears my info and returns to the idle screen.
TIP
How many acceptance criteria should a story have?
- Multiple criteria per story are expected—each one captures a behaviour or scenario (happy path, error, edge case, performance, accessibility).
- A common range is 3–8. If you’re heading past ~10, the story is probably too big—split it.
- Make each criterion observable and testable; it should map to at least one test.
- Keep acceptance criteria separate from your definition of “done” (code reviewed, merged, docs updated). In other words, don’t refer to software development workflows or mechanics.
- Write the happy path first, then add likely edge cases and any non-functional constraints
Final notes
- Keep the story free of UI details; put those in the acceptance criteria.
- Aim small: if implementing a story won’t fit in a sprint, split it.
- Make criteria measurable (times, counts, messages).
- Include at least one edge case per story.