Theory in Practice

Every session in this module applies established theory. This page names the frameworks so you can connect the practice to the academic literature.

---

What you have been doing — and what it is called

What you did in session	Framework	Key concept
Three-question standup, 2 min per person	Scrum (Schwaber & Sutherland, 2020)	Daily Scrum — synchronise the team, surface blockers, nothing else
Sprint goals, tasks, Done/Doing/To Do board	Scrum	Sprint + Kanban board — time-boxed iteration with visible work
Must/Should/Could/Won’t prioritisation	MoSCoW (DSDM framework)	Explicit priority tiers force trade-off decisions before building starts
User story: As a [role], I want [action], so that [outcome]	Extreme Programming (XP) / Agile	Requirement from the user’s perspective — connects feature to value
Acceptance criteria: How do you know it is done?	Behaviour-Driven Development (BDD)	Testable conditions that define the boundary of a feature
Show prototype to user — do not explain — watch	Design Thinking (IDEO / Stanford d.school)	Prototype + Test stage — observation before interpretation
Problem interviews: Tell me about the last time this happened	Jobs-to-be-Done (Christensen) + Design Thinking	Backward-looking questions reveal real behaviour, not hypothetical intent
Find → change → test again, documented with before/after	Lean UX (Gothelf & Seiden)	Validated learning loop — evidence-based iteration
Build it → test with users → measure → learn → repeat	Lean Startup (Eric Ries)	Build-Measure-Learn cycle — reduce waste by testing assumptions early
Architecture decision: why this stack, why this database	Architecture Decision Records (ADR)	Capturing the reasoning behind technical choices, not just the choice
AI agent + user story + acceptance criteria as structured input	Specification-Driven Development	Formal input spec reduces ambiguity and improves AI output quality

---

Why process is assessed, not just the product

ENT208TC assesses process over technology because the module is about Industry Readiness — not software skills.

Employers consistently report that new graduates can code but struggle to:

• Break ambiguous problems into testable requirements
• Work in structured teams with shared visibility
• Make and document decisions under uncertainty
• Test assumptions before building at scale

The frameworks above are the professional response to those challenges. You have been practising them since Week 3.

---

Where to read more

Framework	Accessible starting point
Scrum	The Scrum Guide (free at scrum.org) — 13 pages
Design Thinking	Stanford d.school Bootcamp Bootleg (free PDF)
Lean Startup	Eric Ries, The Lean Startup — Chapter 3 covers Build-Measure-Learn
MoSCoW	DSDM Consortium — any Agile Project Management textbook
Jobs-to-be-Done	Clayton Christensen, Competing Against Luck — Chapter 2
Lean UX	Jeff Gothelf & Josh Seiden, Lean UX — Chapter 1

---

For your Dev Log

If your Dev Log or Technical Documentation mentions “we ran a user test” or “we did a sprint”, you can now name the framework precisely. Assessors reward specific language: “We applied the Build-Measure-Learn cycle from Lean Startup — we tested assumption X, found Y, changed Z.”