At any point during the school year, you can use the rubrics below to self-or-peer-assess a user story and its related acceptance criteria.
These are the same rubrics Mr. Gordon will use to evaluate your writing related to user stories and acceptance criteria.
Here is the original description of the user story concept, with more tips and examples.
NOTE
Mr. Gordon co-developed the rubric below with ChatGPT. He then reviewed and revised the output as necessary to create what you see below.
Rubric
The act of writing and assessing user stories and acceptance criteria falls within the Communication evaluation category.
TIP
If you prefer, here is a printable version of the rubrics below.
User Story
| Clear user need (who / what / why) | One or more parts (who/what/why) are missing or unclear; the benefit is hard to see. | Uses “As a… I want… so that…” with a clear user and benefit. | Very focused on a real user; the purpose is clear and convincing in one short sentence. |
| Clear order and layout | Story and acceptance criteria are mixed together or hard to follow. | Story appears first and is easy to find/read. | Tidy headings/bullets; everything is in a predictable spot and quick to scan. |
| Short and easy to read | Wordy or unclear; grammar issues get in the way. | Plain, concise sentence with few extra words. | Clear, tight wording; easy to understand; specific. |
Acceptance Criteria
| Given/When/Then, testability | Vague steps; not in Given/When/Then; hard to test. | 3–8 clear scenarios using Given (start), When (action), Then (result), including the main path and at least one edge case. | Lean but complete set; each scenario is observable and maps cleanly to tests. |
| Specific and measurable details | Uses fuzzy words like “fast” or “easy.” | States concrete inputs/outputs and expected messages/results. | Gives exact numbers, ranges, or times (e.g., “≤ 2 seconds”) with clear pass/fail conditions. |
| Right for the audience and purpose | Scenarios feel generic or off-target. | Scenarios match the intended user and purpose. | Scenarios anticipate different user roles or needs and stay focused on user-visible behaviour. |
| Correct terms and format | Misuses or skips key terms/formats. | Uses the right terms (acceptance criteria, Given/When/Then) correctly. | Consistent, accurate terminology and formatting; avoids design/implementation details. |
Exemplars
Developing
TIP
If you prefer, here is a printable version of this exemplar.
Acceptance criteria
-
From a podcast page, the user can tap a heart to mark it as a favourite quickly and easily.
-
Favourited podcasts show up in a favourites area so they are easier to find later.
-
If there’s no internet, it should still work somehow or try again soon.
-
Pressing the heart again should remove it from favourites.
-
The app should look normal while this happens and not be confusing.
User story
As a Spotify podcast listener who uses the app in many situations, I want the ability to mark any podcast as a favourite in the app so that I can find it again later without hunting around or searching all the time across different parts of the app, especially when I have lots of shows saved already.
User Story – Rubric Match
| Clear user need (who / what / why) | Uses “As a… I want… so that…” with a clear user and benefit. | ||
| Clear order and layout | Story and acceptance criteria are mixed together or hard to follow. | ||
| Short and easy to read | Wordy or unclear; grammar issues get in the way. |
Acceptance Criteria – Rubric Match
| Given/When/Then, testability | Vague steps; not in Given/When/Then; hard to test. | ||
| Specific and measurable details | Uses fuzzy words like “fast” or “easy.” | ||
| Right for the audience and purpose | Scenarios match the intended user and purpose. | ||
| Correct terms and format | Misuses or skips key terms/formats. |
NOTE
This exemplar mixes order (criteria given first), avoids Given/When/Then, and uses vague wording—so it lands as Developing overall while still showing a few Proficient elements.
Proficient
TIP
If you prefer, here is a printable version of this exemplar.
User story
As a podcast listener, I want to mark a show as a favourite, so that I can find it in the app.
Acceptance criteria
-
Given I’m on a podcast’s show page, when I tap the Favourite (heart), then the show is added to my Favourites list and the heart appears filled, with visual feedback in ≤ 300 ms and the saved state within ≤ 2 s.
-
Given a show is already favourited, when I tap the heart again, then it’s removed from my Favourites and the heart un-fills; the list updates within ≤ 2 s.
-
Given I have favourited shows, when I open my Favourites view, then I see them listed and sorted by most recently favourited and I can see the total count.
-
Given the device is offline, when I favourite or unfavourite a show, then the UI shows the new state right away and queues the change; when the connection returns, then the change syncs within ≤ 10 s or I see a clear message if it fails.
-
Given I’m not signed in, when I try to favourite a show, then I’m asked to sign in and the action completes after I do.
-
Given a show is favourited, when I see it in search results or lists, then its heart appears filled so I can see that it’s already a favourite.
User Story – Rubric Match
| Clear user need (who / what / why) | Uses “As a… I want… so that…” with a clear user and benefit. | ||
| Clear order and layout | Tidy headings/bullets; everything is in a predictable spot and quick to scan. | ||
| Short and easy to read | Plain, concise sentence with few extra words. |
Acceptance Criteria – Rubric Match
| Given/When/Then, testability | 3–8 clear scenarios using Given/When/Then, including main path and at least one edge case. | ||
| Specific and measurable details | Exact numbers/times with clear pass/fail (e.g., “≤ 2 s”, “≤ 300 ms”). | ||
| Right for the audience and purpose | Scenarios match the intended user and purpose. | ||
| Correct terms and format | Uses the right terms and consistent format. |
NOTE
There are more matches in Proficient than Advanced, so this exemplar lands at Proficient.
Advanced
TIP
If you prefer, here is a printable version of this exemplar.
User story
As a podcast listener, I want to mark a show as a favourite, so that find and listen to it quickly in one place.
Acceptance criteria
-
Given I’m on a show’s page, when I tap the Favourite (heart), then the heart fills immediately (≤ 300 ms) and the show appears in Favourites within ≤ 2 s.
-
Given a show is already favourited, when I tap the heart again, then it’s removed from Favourites and the heart un-fills; the list updates within ≤ 2 s and persists after app relaunch.
-
Given I have favourited shows, when I open Favourites, then I see them sorted by most recently favourited and I can see the total count.
-
Given the device is offline, when I favourite or unfavourite a show, then the UI reflects the change right away and queues the change; when the connection returns, then the change syncs within ≤ 10 s or I see a clear message if it fails.
-
Given I’m not signed in, when I try to favourite a show, then I’m asked to sign in and the action completes after I do.
-
Given a favourite/unfavourite is in progress, when I tap repeatedly, then only one action is applied (no duplicates); transient errors auto-retry up to 3 times.
-
Given assistive tech is enabled, when I navigate to the control, then it has an accessible name (“Favourite/Unfavourite show”), keeps focus after activation, and announces the new state.
User Story – Rubric Match
| Clear user need (who / what / why) | Very focused on a real user; the purpose is clear and convincing in one short sentence. | ||
| Clear order and layout | Tidy headings/bullets; everything is in a predictable spot and quick to scan. | ||
| Short and easy to read | Clear, tight wording; easy to understand; specific. |
Acceptance Criteria – Rubric Match
| Given/When/Then, testability | Lean but complete set; each scenario is observable and maps cleanly to tests. | ||
| Specific and measurable details | Exact numbers/times with clear pass/fail (e.g., “≤ 2 s”, “≤ 300 ms”, retry count). | ||
| Right for the audience and purpose | Scenarios match the intended user and purpose. | ||
| Correct terms and format | Consistent terminology and formatting; behaviour-focused (no implementation details). |
NOTE
There are more matches in Advanced than Proficient, so this exemplar lands at Advanced.