> **DRAFT** — under teacher review. # User Stories and MoSCoW The Hamilton and Alexandra College · Year 12 · 2026 Every requirement you write, every question you ask in data collection, and every scope decision in your SRS traces back to one source: what your users actually need. User stories give that need a concrete written form. MoSCoW tells you which ones to act on first. Together they are the foundation the entire C02 pipeline rests on. > [!TIP] > If you can't write a user story for a feature, you don't know whose problem it solves or why. Stop and ask your client before coding anything. --- ## Watch first (≈3 min) {{Video|src=https://www.youtube.com/watch?v=LGeDZmrWwsw}} *Agile Academy (AU) — *StoryCards / User Stories*. 3-min agile-practitioner take on the role / goal / benefit format. Watch for: why each part matters and what a good story looks like on a card.* --- ## The three-part formula Every user story follows the same structure: > **As a [role], I want [goal] so that [benefit].** Each part does a specific job: | Part | What it captures | Common question it answers | |---|---|---| | **As a [role]** | *Who* has this need — a specific user type, not "the system" | Who are my stakeholders? | | **I want [goal]** | *What* they want to accomplish — one concrete action | What does this user need to do? | | **so that [benefit]** | *Why* they want it — the underlying motivation | What value does this deliver? | **Example — well-formed story:** > "As a **teacher**, I want to **mark student attendance** so that I can **track who attended class and report to administration**." - Role: `teacher` — a specific human user role - Goal: `mark student attendance` — one discrete action - Benefit: `track who attended class and report to administration` — a genuine motivation tied to real workflow --- ## Breaking down each part ### The role The role must be **specific enough to imply context**. "User" is almost never enough — a student using a school timetable app has completely different needs from a teacher or an administrator using the same system. ::: info **Picking the right role** For each user story, ask: *"If two different people read this, would they imagine the same person?"* If not, your role is too vague. - Too vague: `As a user...` - Better: `As a Year 9 student...` - Best (when you know your data): `As a Year 9 student who accesses the system on a school iPad...` ::: Roles map directly to entities on your context diagram. Every role in your user stories should appear as an entity — work through this list before you finalise your diagram. (See [What Is an Entity](/sd/C02/What%20Is%20an%20Entity) for the full method.) ### The goal The goal is **one concrete action**. Keep it atomic — if the story requires more than one verb to describe, split it. ::: warning **Conflating multiple goals in one story** A story like *"As a student, I want to log in and view my timetable and download it as a PDF"* contains three separate features. When you apply MoSCoW, you may find login is Must Have but PDF download is Could Have — you cannot separate them if they are written as one story. One goal per story. Always. ::: ### The benefit The benefit is the part students most often skip — and it is the part the rubric cares about most. Without the benefit, a user story is just a feature list with a persona stapled on. The benefit: - Ties the feature to a real user need - Drives your **non-functional requirements** (the "so that" often implies a performance or reliability constraint) - Gives you a way to decide whether a proposed solution *actually solves the problem* **Example:** *"so that I can access my timetable wherever I am"* implies a portability requirement. Your SRS non-functional requirement would read something like: *"The system shall function on desktop, tablet, and mobile devices."* --- ## Common mistakes ::: danger **These stories will cost you marks — fix them before submitting** | Mistake | Weak example | What's wrong | Improved version | |---|---|---|---| | Vague role | *"As a user..."* | No context; could mean anyone | *"As a teacher..."* | | Missing benefit | *"As a student, I want to log in."* | No "so that" — we can't verify this solves a real need | *"As a student, I want to log in so that my data is private and personalised."* | | Multiple goals | *"As a teacher, I want to create questions and manage a question bank and export to PDF."* | Three stories crammed into one; MoSCoW becomes impossible | Write three separate stories | | Technical implementation, not user goal | *"As a student, I want the system to use JWT authentication."* | Students don't care about JWT; this is a design decision, not a user need | *"As a student, I want to log in securely so that my data is protected."* | | Every story is Must Have | All five stories marked M | You haven't thought about scope; the rubric explicitly looks for a range | Apply MoSCoW honestly — see below | ::: --- ## Acceptance criteria Acceptance criteria turn a user story into something **testable**. The standard format is: > **Given** [some precondition], **when** [the user does something], **then** [the expected outcome]. **Example:** > **User story:** *"As a teacher, I want to mark student attendance so that I can track who attended class."* > > Acceptance criteria: > - Given I am viewing my class list, when I click a student's name, then their status toggles between "Present" and "Absent". > - Given I have marked attendance, when I click "Save", then the records are stored and I see a confirmation message. > - Given I have saved attendance, when I navigate away and return, then the saved records are still there. Each acceptance criterion becomes a **validation** in your SRS — a concrete, observable check that the requirement has been met. ::: info **Gherkin and test scenarios** This Given / When / Then format comes from a testing practice called Gherkin. It is not required by VCAA, but it is worth understanding because it connects user stories directly to system testing. See [What Is an Entity](/sd/C02/What%20Is%20an%20Entity) for a worked Gherkin example and how it surfaces entities you would otherwise miss. ::: --- ## MoSCoW priority matrix Once you have a list of user stories, you need to decide which ones are in scope for *this version* of your software. MoSCoW is the tool for that decision. {{Video|src=https://www.youtube.com/watch?v=QfZo9cxnQgY}} *Agile Academy (AU) — *Prioritisation using MoSCoW*. 4-min companion to the user-story video above. Watch for: when to push something from Should to Could, and why *Won't Have* is a feature of the method, not a failure.* | Priority | Definition | Scope meaning | Examples | |---|---|---|---| | **M — Must Have** | Non-negotiable. The software cannot function without this. | In scope; must be delivered | Login, core data entry, basic view of records | | **S — Should Have** | Important and expected, but not critical to launch. | In scope; deliver if possible | Notifications, filtering, basic reporting | | **C — Could Have** | Desirable but genuinely optional; a "nice to have". | In scope but deprioritised; deliver only if time permits | Calendar export, dark mode, advanced search | | **W — Won't Have** | Acknowledged and deliberately excluded from this version. | **Out of scope** — written down so everyone agrees | Parent portal, external LMS integration, analytics | ### Must Have Must Haves define your **minimum viable product (MVP)** — the smallest version of your software that is actually useful to your client. If you removed a Must Have, the software would fail to solve the core problem. A disciplined test: *"If I deliver without this feature, would my client consider the project a failure?"* If yes, it is Must Have. ### Should Have Should Haves are important but not critical. If you run out of time, your client will be disappointed but the core product still works. In practice, most well-managed projects deliver most of their Should Haves. ### Could Have Could Haves are features that would be pleasant to include but have low impact if dropped. They are the first things cut when time is short. If you find yourself with a long list of Could Haves, that is a sign your Must Have scope is well-controlled — that is good. ### Won't Have ::: warning **Won't Have is not "I didn't bother"** This is the most misunderstood category. Won't Have is a **deliberate, documented scope exclusion**. It means: - You considered the feature. - You discussed it with your client (or thought through the implications). - You agreed it will **not** be in this version. - You wrote it down so no-one can later claim it was forgotten. Won't Have protects you from scope creep. When a stakeholder asks *"but what about parent access?"*, you can point to the Won't Have list and say *"we agreed that was out of scope for Version 1."* Writing *"I couldn't be bothered"* as the reason for a Won't Have will not score well. Write the actual reason: time constraints, out of scope for this user group, planned for Version 2. ::: --- ## A worked example **Project:** School canteen pre-order app for The Hamilton and Alexandra College students. | # | User story | MoSCoW | Why | |---|---|---|---| | US1 | As a **student**, I want to **browse the canteen menu** so that I know what is available before ordering. | **Must Have** | Core feature — without it, the system cannot function | | US2 | As a **student**, I want to **place an order in advance** so that I can avoid the lunchtime queue. | **Must Have** | Primary user goal; the reason the system exists | | US3 | As a **canteen staff member**, I want to **view the day's orders** so that I can prepare the right quantities in advance. | **Must Have** | Staff-facing core feature; without it the system is one-sided | | US4 | As a **student**, I want to **receive a notification when my order is ready** so that I know when to collect it. | **Should Have** | Valuable but the system works without it; students can check manually | | US5 | As a **student**, I want to **see my order history** so that I can quickly reorder my usual items. | **Could Have** | Convenience feature; no impact on core functionality | | US6 | As a **parent**, I want to **top up my child's canteen account online** so that I do not need to send cash to school. | **Won't Have** | Out of scope for Version 1; requires payment gateway integration and parent authentication — acknowledged for Version 2 | This range — at least one story in each MoSCoW category — is what the rubric expects. If every story is Must Have, you haven't thought critically about scope. --- ## From user stories to data collection User stories are hypotheses. Before C02 is finished, your data collection must **test** those hypotheses — confirming, refining, or replacing them with what you actually learn. Each user story drives specific questions you need to answer, which drives method choice: | User story element | Questions it raises | Method best suited | |---|---|---| | **Role** (who are they?) | What are their characteristics, skill level, context of use? | Interview, observation | | **Goal** (what do they do?) | What does the current workflow look like? Where are the pain points? | Observation, interview | | **Benefit** (why do they want it?) | Is this a real need or an assumed one? Do others share it? | Survey, interview | | **Acceptance criteria** | What does "done" look like to the user? | Interview with client | | **Technical preconditions** (Given…) | What devices, accounts, network access do users have? | Reports (IT device list), observation | **Example:** For US1 in the canteen app (*"As a student, I want to browse the canteen menu so that I know what is available before ordering"*): - *Who are your students?* → Survey: "Which device do you use at school?" → shapes technical environment in SRS - *Do students currently look at the menu?* → Observation: do students read the noticeboard menu, or do they just queue and decide at the counter? - *What information do they need?* → Interview: "What would you want to see on a digital menu that the noticeboard doesn't show?" The data collection plan's Section 4 (user stories and MoSCoW) and Section 2 (methods) must align — for each story, at least one method should directly address a question that story raises. --- ## User stories in your SRS Once data is collected and analysed, your user stories feed into two parts of the SRS: **Functional requirements** — derived from the *"I want [goal]"* part: - User story: *"As a teacher, I want to mark student attendance..."* - Functional requirement: *"The system shall allow teachers to select a class and mark each student as present or absent."* **Non-functional requirements** — derived from the *"so that [benefit]"* part and acceptance criteria: - Benefit: *"...so that I can report to administration."* - Non-functional requirement: *"Attendance records shall be retrievable within 2 seconds of a teacher's request."* ::: success **Tracing requirements back to user stories** In your SRS, label each requirement with the user story it came from (e.g. *"[US3]"*). This traceability shows examiners that your requirements came from real data collection, not guesswork — and it is exactly the kind of evidence that separates 9–10 responses from 7–8. ::: --- ## MoSCoW and your SRS scope statement The Won't Have list becomes the **exclusions** section of your SRS scope. A well-formed scope statement: ``` The [Project Name] will provide [Must Have features] (Must Have). The system will aim to include [Should Have features] (Should Have). [Could Have features] may be included if time permits (Could Have). The following are explicitly out of scope for Version 1: - [Won't Have feature 1] — reason - [Won't Have feature 2] — reason ``` This structure prevents scope creep and gives your client a clear record of what was agreed. --- ## Check Your Understanding Answer in your head first, then click the spoiler to check. **1.** A student writes: *"As a user, I want to log in so that I can access the system."* What is the **biggest** problem with this story? *(a) it is too long · (b) the role is too vague · (c) there is no acceptance criteria · (d) "log in" is a technical term* >! **(b) the role is too vague.** "User" tells us nothing about who this person is, what context they work in, or whether their login needs are different from other roles. Every other issue (no acceptance criteria, technical language) is secondary — a vague role means you cannot derive meaningful requirements. Fix: replace "user" with the specific role (student, teacher, administrator). **2.** A student assigns **Must Have** to all eight of their user stories. What does this tell you about their scope planning? *(a) they have a very focused project · (b) they probably haven't thought critically about what is truly essential · (c) this is correct — every story matters · (d) they need more user stories* >! **(b) they probably haven't thought critically about what is truly essential.** If everything is Must Have, MoSCoW is doing no work. A genuine Must Have is something the project *fails without*. Most projects have 3–5 true Must Haves. The rubric explicitly expects a mix of all four MoSCoW categories — students with all Must Haves are likely to lose marks for scope planning. **3.** A student writes: *"Won't Have: Parent portal — I couldn't find time to build it."* What is wrong with this Won't Have? *(a) parent portals are always Must Have · (b) Won't Have should only be used for technical impossibilities · (c) the reason doesn't show deliberate scope planning · (d) nothing — this is fine* >! **(c) the reason doesn't show deliberate scope planning.** Won't Have is a *deliberate* scope exclusion, not a de-facto one. The reason should explain a *decision*: "out of scope for this user group", "requires payment integration planned for Version 2", "agreed with client as future enhancement". "I couldn't find time" reads as oversight, not planning. **4.** Which part of a user story most directly generates **non-functional requirements** in your SRS? *(a) the role · (b) the goal · (c) the benefit · (d) the acceptance criteria* >! **(c) the benefit.** The "so that [benefit]" clause captures *why* the user wants the feature — and the qualities that make that benefit possible (speed, reliability, portability, usability) are exactly what non-functional requirements describe. The goal generates functional requirements; the benefit generates non-functional ones. --- ## See also - [Data Collection Methods](/sd/C02/Data%20Collection%20Methods) — the four methods and how to choose your mix; connects to the "from user stories to data collection" section above - [What Is an Entity](/sd/C02/What%20Is%20an%20Entity) — how to use user story roles to find every entity for your context diagram; includes Gherkin acceptance criteria worked example - [Explaining vs Describing Your Data Collection](/sd/C02/Explaining%20vs%20Describing%20Your%20Data%20Collection) — the rubric difference between 7–8 and 9–10 for Indicator 1; directly relevant once you have your user stories and methods aligned - [Essential Terms](/sd/C02/Essential%20Terms) — definitions of functional/non-functional requirements, scope, constraints, and other SRS terms --- ← Back to [C02 Home](/sd/C02/C02-home) · [VCE Software Development Hub](/sd/VCE%20Software%20Development%20Hub)