Deliverables

This page holds all six phase deliveries: the exact date each is due, its weight, what the delivery must contain, the rubric it is read against, and the templates it uses. This is the only page on the course site where delivery dates appear — every slide that mentions one points here.

The six phases

What each delivery contains

Phase 1 — team, environment, and an accepted proposal

• A formed team, with roles recorded on the roster workbook.
• A verified environment — the tools installed and signed in.
• The team agreement, docs/team-agreement.md, signed in class by every member twice — once by hand and once through Antigravity, each one a commit from that member's own account.
• A proposal the instructor accepts, in the required shape — as docs/proposal.md, and published as a page from the team's repository.
• Rejected proposals come back within three calendar days.
• The first resubmission carries no penalty; a second caps that component at half.

Phase 2 — design sprint: personas, stories, schema, work split, token plan

Due Wed 7 Oct 2026, before class. 10 marks. What is graded is your repository at the tag phase-2. Delivered to the whole class, from the repository, with questions from the room.

The order things are decided in, and the order they are read in: the personas; the stories and their acceptance criteria; the schema; then screens and code. A team that has an app and no personas has done the last step first.

Every deliverable, where it lives, who owns it, and what done means.

The backlog floor. Two stories per member per sprint, across four sprints.

It is a floor, not a scope target. Below it the individual mark has nothing to attach to.

The token plan. It says five things.

• Where each kind of work happens — planned in the browser, built on the machine.
• Which model for which task, and why that one.
• The tactics the team will use to keep a run narrow.
• What you will watch, and what you have no way of seeing.
• What you do when the quota runs out, decided before it does.

It lives in the first section of docs/finops-ledger.md, committed like everything else. Short and specific beats long and general. The first ledger entry follows it: one row per story that used an assistant in Phase 2.

The delivery note. docs/delivery-notes/phase-2.md, written by the Phase Lead during the phase. Five headings, in this order:

1. What was decided — the design in plain language: who the users are, the handful of things they can do, the tables that hold it. Five to eight lines. (From Phase 3 this heading reads “what works now that did not work before”; the file in your repository carries that wording. Write the Phase 2 version under it.)
2. Who did what — one line per member: name, the stories they wrote, the ones they are assigned to build. Everybody appears.
3. Where everything is — a link for each deliverable in the checklist above.
4. The tag — phase-2, created after the last merge.
5. Not finished, and where it went — what was planned and is not there: moved to Phase 3, dropped, or replaced. Say which.

A worked example is below. On delivery day you present from the note; the session format is below as well.

How Phase 2 is read.

• The ledger is binary: present, current and plausible against the git log, or zero.
• Every other row of the checklist is read at one of three levels — not there, there with gaps, meets — and “meets” is the done column above. Nothing above it earns extra. The full rubric is below.
• Whoever approves a pull request merges it. The reviewer can be anyone on the team and is never the author.
• Workflow slips — approving without reading, merging your own work, signing for a teammate — are warnings, recorded privately. Repeats cost later.
• The cutoff is the tag. Work that arrives after it is recorded, not marked, and still required.

Your own part is read from two things: your named stories and their criteria, written and assigned under your own account; and Quiz 3 on Mon 5 Oct.

Phase 3 — sprint 1: the first working increment

The most guided sprint.

• A working increment off the backlog.
• Reviewed merges — no one merges their own work unread; the reviewer who approved is the one who merges.
• The board matching the git log.
• A current ledger.
• The phase tag in the repository.

Phase 4 — sprint 2: the second working increment

As Phase 3. Nothing new is introduced.

Phase 5 — sprint 3: the third increment

As Phase 3, plus the analytics feature specified in week 9, run on the team's own data.

Phase 6 — final sprint and the demo

Two parts, two dates.

• The final sprint, due Wed 9 Dec 2026: the frozen scope shipped, analytics included, delivered exactly like phases 3 to 5.
• The demo, Mon 14 and Wed 16 Dec 2026: the system shown working, with oral questions to individuals. It is scored by the instructor and by peer assessment, and the detailed rubric is issued before the demo.

The repository tag and the FinOps ledger

Two rules. They start at different phases.

• Every phase is tagged in the repository at its due date, and the tag is what gets graded. All six, phase-1 through phase-6, from Phase 1 onward. Not a submitted document, not a slide deck — the repository at that tag. See the repository page for the tag names and the rest of the repository rules.
• The FinOps ledger is part of every delivery from Phase 2 onward. It is graded binary: present, current, and plausible against the git log, or zero. There is no accuracy target and no arithmetic to do.

How a delivery session works

A delivery session is not a queue of private meetings. All teams are in the room. Each team presents, and the rest of the class is the audience and the question pool. Teams arrive with their own questions prepared — questions for the teams presenting, about what they decided and the choices behind it, never about marks. Arriving without them is itself a failure of the session. Every delivery is presented from the team's public repository at the phase tag, not from a slide deck and not from a laptop folder.

Phase 2, Wed 7 Oct 2026. 75 minutes: 15 for the merge-conflict clinic, then five teams, twelve minutes each: eight presenting, four of questions from the room. Order is team 1 to team 5 unless drawn at the start. The instructor keeps time; a team that runs over loses its question time, not the next team's. The delivery note is the script:

Every member speaks at least once; a team of four spreads the rows. Each team asks at least one question during the session; the instructor asks last. What is recorded for each team: presented from the note or not; every member spoke or not; asked a question or not. The same format, with “what works now” in place of “what was decided” and the running system on the screen, is used at every later delivery.

The Phase 2 delivery note — a worked example

Fictional team and system. Every line is a place or a name.

Rubrics

One rubric for every team. Each row is read at one of three levels from the repository at the tag: not there, there with gaps, meets. “Meets” is written so that you can check it yourself before the tag. The ledger row is binary. Workflow slips are warnings, recorded privately, not deductions in this phase. Marks are private: a team channel gets the team's levels and its warnings count; your own rows reach you directly.

Phase 2 — the design sprint

Phases 3, 4, 5 and the Phase 6 sprint — every coding sprint

The same rubric after every coding sprint: Wed 21 Oct, Wed 4 Nov, Wed 18 Nov and Wed 9 Dec 2026.

Templates a delivery uses

• The project proposal — the required shape.
• Your repository — the rules and the layout.
• Publishing from your repository.
• Team roles.
• The team roster workbook (.xlsx).