Teaching Guide¶
Instructor material
This page is for instructors and teaching assistants. Students should not need it.
Pacing¶
The course is designed as 16 weeks with two sessions per week — 32 sessions of about two hours each, plus independent study: roughly 85–95 hours of student work including the capstone. The session-by-session plan is in the Curriculum Roadmap.
| Schedule | Weeks | Per week | Notes |
|---|---|---|---|
| Design intent | 16 | Two sessions | The plan the material is written for |
| One module per week | 13 | One module | One module per week; capstone in the final weeks |
| Compressed | 8–10 | One to two modules | Drop the optional lessons; keep every lab |
The session order should not be reordered in Part I: Modules 01–03 establish vocabulary that every later module uses. Two placements are deliberate and worth defending if you change them: Module 04 (agile) follows predictive planning so students can see what agile responds to, and Module 11 (metrics and control) follows the plan it measures. Session 17 is a consolidation checkpoint, not slack — it is where gaps from the planning half can still be fixed cheaply.
Delivery models¶
Students read the module, do the lab, and take the quiz on their own. You hold office hours and a weekly question session. This is the model the material is designed for.
Students read the lesson before class. Class time is spent on the lab and on the case-study discussion questions. Highest-value use of contact hours, because the lab is where students get stuck.
The material works, but you will be repeating what students could have read. Use lecture time for the parts students consistently find hard (see below) and for the case discussions.
Common student difficulties¶
These are the points where students most often stumble, with a suggestion for each.
| Difficulty | Where it appears | Suggestion |
|---|---|---|
| Confusing effort with duration | Module 07 | Ask why two people on one task do not halve the calendar time |
| Treating the schedule as a promise | Modules 06, 11 | Discuss estimation uncertainty; insist on ranges |
| Confusing verification with validation | Modules 05, 09 | Use the "building the thing right" vs "right thing" framing |
| Writing unobservable success criteria | Modules 01, 02, 11 | Ask "how would we know?" until the answer is testable |
| Confusing risks with issues | Module 08 | Ask whether it has already happened |
| Treating agile as the absence of planning | Module 04 | Emphasise that agile changes what and when you plan |
| Reporting optimistic status | Module 11 | Reward early disclosure of bad news in class discussions |
| Confusing influence with authority | Module 02 | Introduce a stakeholder who can block without deciding |
Running the labs¶
- Reuse one scenario across labs so artefacts accumulate toward the capstone. The Campus Event Portal case and the Lab 01 scenario are written to be reused.
- Insist on the rubric. Students who skip self-marking repeat the same mistakes.
- Discuss, don't collect. In class, comparing two students' charters teaches more than marking twenty.
- Keep artefacts. The capstone expects the earlier artefacts to be extended.
Discussion questions that work¶
- "What would have to be true for this plan to fail?"
- "Who is not in this conversation but should be?"
- "If we had to cut half the scope, what would we keep?"
- "What is the earliest point at which we could have known this was going wrong?"
These surface reasoning rather than recall, and they work with almost any module.
Managing the capstone¶
The capstone is integrated, not bolted on: six milestones (M1–M6) are due at intervals across the term, each reusing an artefact the student already produced in a lab. The schedule is in the Curriculum Roadmap.
- Set the scope expectations early and low. A modest project that is genuinely managed beats an ambitious one that is not.
- Require progress reports at fixed intervals; the reporting is part of the assessment.
- Check milestone M1–M3 at the session 17 checkpoint, while inconsistencies are still cheap to fix.
- Grade coherence across artefacts, not the software. This is a management course.
See the Assessment Guide for weighting, and the Course Map for module-to-outcome alignment.