One project, two ways to organize the same work

This app's backlog, as GitHub records it

$ gh api repos/gxolivei/nor/milestones --jq '.[] | {title, closed_issues, due_on}'
{"title":"Phase 1 — Authentication","closed_issues":7,"due_on":null}
{"title":"Phase 2 — Catalog","closed_issues":13,"due_on":null}
{"title":"Phase 3 — Enrollment & Progress","closed_issues":4,"due_on":null}
{"title":"Phase 4 — IRB Terminal","closed_issues":4,"due_on":null}
{"title":"Phase 5 — Polish & Testing","closed_issues":5,"due_on":null}

This project, the one every course in this catalog lives in, was built this way. There are five named phases, each a GitHub milestone. Issues carry a domain label (domain: catalog, domain: enrollment) and a type label (type: backend, type: frontend). None of the milestones has a due date. That's what the repository holds today, not a hypothetical.

What isn't here

There's no sprint and no story point. Nothing in this working project's planning structure matches either word in this course's title. That isn't a flaw. Phases with no fixed deadline suit a project with no delivery date to hit: the work finishes when it finishes. It is a different model from the one this course teaches, though, and knowing the difference is the point.

A different, named model

Agile, and Scrum in particular, its most common concrete form, organizes work into fixed-length cycles instead of open-ended phases. It sizes work in an unusual unit instead of hours or done/not-done. Both choices solve a problem phases don't: forecasting how much a team of several people can finish by a given date, and adjusting that forecast every cycle instead of finding out at the end.

What this course covers

Lesson 2 defines a Sprint, quoted from the Scrum Guide. Lesson 3 covers story points, and a surprising fact about where they do and don't come from. Lesson 4 is planning poker, the estimation technique, checked against the source most associated with it. Lesson 5 covers velocity, the number that turns points back into a calendar forecast. Lesson 6 looks at this app's planning shape again, with sharper questions now that the vocabulary exists. Lesson 7 runs the whole cycle once, from estimate to forecast.

Where this leaves you

The question isn't which model is correct; phases fit this project, and they aren't a shortcut around Agile. The skill is recognizing which problem a team has. One is predictable delivery across many contributors on a recurring cadence. The other is steady progress with no fixed deadline. Pick the planning model built for the problem you have, not the one that happens to be famous.