Milestone 1

Charter, Scoping Decision & Engineering System

Apologetic question: "What does it cost to finish what you start?"

Milestone 1 — Charter, Scoping Decision & Engineering System

“For which of you, desiring to build a tower, does not first sit down and count the cost, whether he has enough to complete it?” — Luke 14:28 (ESV)

Chapter: Chapter 1 — Commit to a Project by Friday Week: 1 of 8 · Phase: Inception (the whole phase, one week) · Hats: Project manager and product owner Due: End of Week 1. The commit history must show work on at least three distinct days — this deliverable cannot honestly be produced in one sitting, and the history is part of the evidence. Submit: A link to your repository, plus the Week-1 quiz. Nothing is submitted as an attachment; the repository is the submission, this week and every week. Where it lands in the final package: docs/charter.md, docs/scoping-decision.md, docs/hours-log.csv, docs/ai-usage.md, README.md v0, and the repository structure itself. These feed the Week-8 rubric lines for the hours log, the ai-usage log, the README, and repository hygiene — and every later document in docs/ slots into the tree you build this week. AI policy: Open, and governed by the policy you write in this milestone. Green-zone use is free. Any Amber-zone use — including asking an assistant to pressure-test a brief, draft your calendar, or write your .gitignore — gets a row in docs/ai-usage.md with all six columns filled. The charter’s §4 (definition of finished), §5 (non-goals) and §7 (working agreement), and the scoping decision’s §4 (adaptation record) and §8 (accepted tradeoffs) must be your own words about your own project. Generated text there is a Red-zone violation, and it is obvious to read.


The Setup

It is Monday of your first week at a small company. You are the only engineer. There is no product specification on your desk — but there is a folder of pre-scoped project briefs from the last planning cycle, each one written by somebody who is no longer here, each one describing a real customer problem with a first pass at requirements attached.

Your manager wants a commitment by Friday. Not a shortlist. A commitment: which one, what you are changing about it, what it will cost in hours, what you are deliberately not building, and what would make you cut scope.

That is the week. Notice what is not being asked of you: originality. Nobody is impressed that you invented the problem; they are relieved that somebody scoped it already. What they need to know is whether you can read somebody else’s work, find the places where it no longer fits reality, repair those places on purpose, and sign your name at the bottom.

It is also the least glamorous week of the term, and the one that most reliably separates the capstones that finish from the ones that get apologized for in Week 8. You are laying a foundation in public, with a timestamp on every commit, and you have eight weeks. Before you lay it — sit down and count.


Learning Targets

You will demonstrate that you can:

  • Stand up an engineering system — repository, board, and log — in the first two days, before the work arrives.
  • Choose under alternatives: shortlist three pre-scoped briefs, screen them, and reject two in writing for stated reasons.
  • Adapt inherited work responsibly — record every deviation from a brief and name the drafted requirements each one breaks.
  • Right-size to a fixed budget: three or four Must features, estimated bottom-up in vertical slices, reconciled against an independent model.
  • Bound the work in advance with an explicit out-of-scope list and a scope-cut trigger that has a date on it.
  • Count the cost honestly — audit your real capacity, name the week that is already broken, and decide now what you cut when you fall behind.
  • Set an AI policy in writing before the pressure arrives, and disclose use as evidence of judgment rather than as a confession.

The weekly status block — paste this into your submission comment

Every milestone submission carries these five lines. It takes two minutes, it is the same five lines every week, and it is the difference between an instructor who can help you in Week 3 and one who finds out in Week 7. Copy it into the Canvas submission comment when you submit — not into a document.

Shipped:     what actually works this week, in one line
Cut:         what I dropped or deferred, and where it went (backlog / change request / gone)
Hours:       planned N / actual N        (from docs/hours-log.csv)
Blocked on:  the one thing in my way, or "nothing"
Ship confidence: green | amber | red — if amber or red, the one thing that would move it

Say red when it is red. A red in Week 3 is a conversation and a scope cut. A red discovered in Week 7 is a grade. Nobody has ever been penalised in this course for an honest amber; the only expensive answer is the green that was not true.


Normal Tier

Required deliverables

  1. A repository, on GitHub, with the canonical structure from §1.6 — every docs/ slot created with a placeholder, plus src/, tests/, script/, .github/workflows/, .gitignore, and a LICENSE file or a dated deferral note. Commit history spans at least three distinct days.

  2. docs/charter.md, from the provided template code/charter-template.md, with all eight sections completed — including §2, which in this edition is filled this week rather than next. In particular: §1 a purpose someone else could check; §3 a capacity audit with every row filled, including administrator rights, money, and the broken week; §4 three to six checkable bullets; §5 at least five specific non-goals; §6 at least three risks with early warning signs and responses; §7 a working agreement with a ranked cut order and a scope-cut trigger.

  3. docs/scoping-decision.md, from the provided template code/scoping-decision-memo.md, with all thirteen sections. The centerpiece is §4, the adaptation record: every deviation from the brief, why, and which drafted requirements it touches — including the word “none”, signed, if you adopted the brief as written.

  4. A Must list of three or four features, estimated bottom-up in vertical slices (interface, handler, data, validation, error path, test, documentation line), totalling inside the 30-hour plan / 40-hour ceiling, and reconciled against the Decision Engine’s independent number with the gap explained.

  5. Feasibility evidence. Every external dependency exercised once, for real, this week — what you called, the result, whether a key was needed, the rate limit and where it is documented, and the date you read the terms. Anything you could not exercise is marked UNVERIFIED. Novelty load counted, with a named swap for anything above two.

  6. Evidence a user exists — one conversation, dated, past-tense questions, three verbatim quotes. Or, if your project genuinely has no user but you, one sentence saying so plus a competitive scan of three existing tools. Do not invent a user.

  7. A project board, live, with five columns, an enforced work-in-progress limit, and at least six well-formed cards — each with an estimate, a hat, and a stopping condition.

  8. docs/hours-log.csv with at least five real session rows totalling at least twelve hours, each with estimate_hours filled in before the session began, plus code/week1_check.py copied into tools/ and runnable from a clean clone.

  9. docs/ai-usage.md, from the provided template code/ai-usage-template.md, with a completed policy header and at least two real entries with all six columns filled.

  10. README.md v0 — what this repository is, who owns it, its current status, which brief it came from, how to navigate docs/, and what is intentionally not here yet.

The bar, shown

You never have to guess what “good” means in this book. Here is the section graders find weakest in the accelerated edition, at two points and at full points.

Adaptation record — the version that earns 2 of 13

I adapted brief #1 to fit my situation and made a few changes to the requirements to match my scope.

Which changes? Which requirements? A grader cannot check a single word of that, and neither can you in Week 6, which is when it matters. Worse, the sentence is comfortable — it reads like work was done, which is exactly why it survives until it fails.

Adaptation record — the version that earns 13 of 13

#What I changedWhyDrafted requirements it touchesRepair due
1Withdrew barcode entry entirely; typing is the only way an item gets into the pantryThe brief prices it at 14 h. My Must list is already 27 h of a 30-hour plan, so adopting it lands me at 41 — past the 40-hour ceiling, with the overage coming out of testing and documentation. It is the brief’s own second cut and I am taking it in Week 1 rather than Week 4FR-SCAN-01 (withdraw), FR-SCAN-02 (withdraw — it was only a Must if FR-SCAN-01 was adopted, and a fallback with nothing to fall back from is dead code), NFR-PRIV-01 (repair — its product-lookup clause now governs a request this system will never make; the model-provider clause stays, still conditional on FR-REC-01)Week 2
2Expiry window fixed at three days rather than household-configurable”Household-configured” quietly bought a settings screen, a stored preference, and its validation — 3 h for a preference K.T. never asked for. Three days rather than the brief’s seven because we shop on Sundays: a seven-day window is the whole pantry, and a screen that lists everything says nothingFR-EXP-02 (repair — replace “a household-configured window” with “three days”; its first acceptance criterion was written for a seven-day window and now lists the 2-day item only)Week 2
3Editing an item drops from Should to Won’t (this release); a mistake is corrected by marking the item consumed and adding it again4 h I do not have, and a Should left standing in my own specification is a promise with no hours behind it. It is worse for the user than an edit form, and the specification will say so in that sentenceFR-INV-02 (withdraw)Week 2
4The user is K.T.’s two-person household, which I live in — not Dana’s four-person share houseThat is who I actually interviewed (K.T., 2026-09-09). The brief also says every drafted requirement is missing its Source: line, so each one I keep gets a real one or gets deletedFR-INV-01, FR-INV-03 (repair — their rationales argue from Dana’s whiteboard and from Marcus, neither of whom exists here; both are replaced by the 2026-09-09 conversation), plus the Source: line added to all thirteen requirements I keepWeek 2

Carried: FR-ACC-01, FR-INV-04, FR-REC-01 (left a Could at the brief’s priority — 18 h, an evaluation set and a spend cap, and it is not built unless Week 6 ends with the Musts done, tested and deployed), FR-EXP-05 (already Won’t; there is still no address to notify), NFR-PERF-01, NFR-SEC-01, NFR-SEC-02, NFR-REL-01, NFR-ACC-01 — nine of the brief’s sixteen, unchanged apart from the Source: line in row 4. Withdrawn: FR-SCAN-01, FR-SCAN-02, FR-INV-02. Recorded here so they cannot reappear in docs/requirements.md in Week 2 without a decision.

Every row is checkable. All sixteen drafted requirements — ten functional, six non-functional — have been read and given a verdict: seven touched, nine carried, none skipped. And the last line is what stops eighteen hours of withdrawn work from wandering back into the specification in Week 2 because it still sounded like a good idea.

Scope-cut trigger — the version that earns 1 of 6

If I get behind I will reduce scope and focus on the core features first.

No condition, no date, no order, no way to be wrong. It commits its author to nothing, so in Week 5 it will protect them from nothing.

Scope-cut trigger — the version that earns 6 of 6

Checked at the Week-4 design review (2026-10-02). Condition: if the walking skeleton is not deployed and green in continuous integration by that date, I cut in this order — (1) the undo path on mark-consumed, replaced by a confirm dialog, and FR-INV-04’s second acceptance criterion is withdrawn in docs/requirements.md the same day; (2) the expiring-soon page, which becomes a sort order and an “expires in n days” badge on the pantry list, with FR-EXP-02 repaired rather than quietly reinterpreted. I took the brief’s own cuts in Week 1, so from here every cut comes out of a Must — which is exactly why this is checked in Week 4 and not in Week 6. I will record either cut in CHANGELOG.md rather than quietly not building things.

What this milestone feeds

Artifact you build this weekConsumed byWeek-8 rubric line it feeds
Repository structureevery later milestonerepository hygiene, submission completeness
docs/scoping-decision.md §4–§7Week 2’s requirements repair pass; Week 4’s baselinerequirements quality, scope discipline
docs/charter.md §3–§7Week 3’s plan and risk registerplanning realism
docs/hours-log.csvWeek 3 estimates, Week 4 pace audit, Week 8 retrospectivethe hours log
docs/ai-usage.mdevery week you use a toolthe ai-usage log, academic integrity
README.md v0Week 7’s documentation set and clean-machine testthe README

Nothing here is a warm-up. Every row is a line item you are graded on in Week 8, opened early.

Normal-tier rubric (out of 100)

CriterionPoints
Repository with the canonical structure; history spans ≥3 distinct working days6
README.md v0 orients a stranger: what, who, status, which brief, navigation, what is deliberately absent5
Charter §1/§3/§4: purpose, capacity audit against 20 hours a week, definition of finished a stranger could check9
Charter §5/§6/§7: ≥5 specific non-goals, ≥3 risks with warning signs, working agreement with a ranked cut order8
Adaptation record: every deviation named, with the drafted requirements it touches and a verdict on every requirement in the brief13
Must list of 3–4 features, bottom-up vertical-slice estimate inside 30/40 h, reconciled against the Decision Engine13
Out-of-scope list: ≥8 named items, including two you want to build8
The one hard part named and justified in two sentences — exactly one4
Feasibility: every external dependency exercised for real with dated evidence; novelty load counted, swaps named6
Evidence a user exists: one dated conversation with three verbatim quotes, or a stated competitive scan6
Two briefs rejected in writing, each with the gate it failed; scope-cut trigger with a checkable condition and a real date6
Project board: five columns, enforced WIP limit, ≥6 cards with estimate, hat, stopping condition4
docs/hours-log.csv: ≥5 rows, ≥12 hours, estimate_hours plausibly pre-written; the check script runs from a clean clone7
docs/ai-usage.md: complete policy header plus ≥2 entries with all six columns filled5
Total100

Medium Tier (+ up to 25% extra credit)

Pick what fits. Each buys you something real in a later week.

  • A structure-check workflow. A minimal GitHub Actions job that fails if any canonical docs/ path is missing — call tools/week1_check.py and let its exit status do the work. Nine lines of YAML, and it means Week 3’s continuous integration is not the first time you have seen the tool.
  • Issue and card templates. A repository issue template that forces a requirement identifier, an estimate, and a stopping condition on every card you will ever create. Making bad cards harder to create is worth more than remembering not to.
  • A three-point estimate. Re-estimate your Must list optimistic / most-likely / pessimistic per feature, compute the expected value, and reconcile it against your bottom-up number and the Decision Engine. Three independent estimates that agree are a plan; three that disagree tell you where your uncertainty lives.
  • A timeboxed spike. Two to three hours, hard stop, spent proving the single riskiest technical assumption in your chosen brief — usually the hard part. Write up the result either way. A spike that disproves an assumption in Week 1 is worth more than one that confirms it.
  • The two-week-loss plan. One page: the smallest version of this project that would still be worth doing and still defensible if you lost two of the eight weeks. Name which features survive and in what order the rest die. Two weeks is a quarter of this term, and somebody in your section is going to lose them.

Hard Tier (+ up to 25% additional extra credit)

Write the Cost Memo — two to three pages, addressed to your instructor. Every sentence in it requires knowing your own life and being willing to say something unflattering about it, which is exactly why no assistant can produce it for you. Cover all five:

  1. Argue against your own choice. Make the strongest honest case that you shortlisted the wrong brief, using the evidence you gathered rather than straw. Then explain why you are proceeding anyway — the tradeoff, named, eyes open. A memo that cannot argue the other side has not considered it.

  2. The honest capacity audit. Not “I have twenty hours.” Where do they come from? What are you giving up to get them? Name the specific commitment — a shift, a club, a relationship’s regular evening — that will contest those hours in Week 5, and say what you will actually do when it does.

  3. The feature you most want to build and are cutting. State its cost to the user, not to you. “I really wanted to build it” is not a cost. “The household will still have to check expiry dates by hand” is.

  4. Your personal failure mode, with a tripwire. Of the four in §1.1 — the late start, the oversized idea, the undocumented pile, the invisible process — which is yours? You know. Say why, with evidence from a past project. Then design a tripwire: a specific, observable, dated signal that would tell you it is happening again, and name the person you will tell when it trips.

  5. The AI line, in advance. Describe the specific moment this term when you expect to be tempted past the line you drew in §1.8 — the actual week, the actual pressure, the actual shortcut. Then write the answer you commit to now. A policy that has not imagined its own violation is not a policy.

Graded on honesty, specificity, and self-knowledge. A polished memo that could describe any student earns nothing. A plain memo that could only describe you earns full credit.


Submission

Push everything, then submit the repository link and take the Week-1 quiz.

capstone/
├── README.md                 # v0 — what, who, status, which brief, navigation
├── LICENSE                   # chosen, or a dated deferral note inside
├── .gitignore
├── docs/
│   ├── charter.md            # all eight sections, including §2
│   ├── scoping-decision.md   # the centerpiece: §4 is the adaptation record
│   ├── hours-log.csv         # ≥5 real rows, ≥12 hours
│   ├── ai-usage.md           # policy header + ≥2 entries
│   ├── evidence/             # saved dependency responses, dated
│   ├── interviews/           # the Week-1 conversation write-up
│   ├── adr/                  # empty, with .gitkeep
│   └── …                     # placeholders for every later week
├── src/  tests/  script/     # empty, with .gitkeep
├── tools/
│   └── week1_check.py
└── .github/workflows/        # empty this week; Medium tier adds one

Commit message: M1: charter, scoping decision, engineering system. Plus, if you attempted it, docs/cost-memo.md (Hard tier).


Hints

  • Do Rep 7 first, not last. The user conversation is the only deliverable that depends on somebody else’s calendar. Everything else you can do at midnight; that one you cannot.
  • Do the charter’s §5 before §1. Non-goals are easier to write than purposes, and writing them first tells you what your purpose actually is. This trick works on every specification you will ever write.
  • Read every drafted requirement in your brief, even the ones you are keeping. The point of the carry/repair/withdraw pass is not the changes; it is the reading. A requirement you never read is a requirement you cannot defend.
  • Fill the capacity table with a calendar open. Not from memory. Memory is optimistic about Tuesdays.
  • When your two estimates disagree, do not average them. Find the assumption that differs. Averaging hides the thing you needed to learn.
  • A number you are unsure of beats an adjective. “Roughly 12 hours, low confidence” can be corrected in Week 3. “A fair amount of work” can never be anything.
  • Do not choose your license by asking an assistant. Read the actual text at spdx.org/licenses or choosealicense.com, and check whether your institution has a policy about student work. If you are not ready, write LICENSE with a dated line saying the decision is deferred to Week 3 and why. A dated deferral is a decision; an empty file is not.
  • If you cannot bring yourself to reject two briefs, you did not shortlist three you would genuinely accept. Go back to Rep 5. Decoys are visible from orbit.

What Mastery Looks Like

A mastered Milestone 1 is boring to read and impossible to argue with.

The scoping decision names a brief, a date, and a list of changes with requirement identifiers beside them. The Must list has three or four things on it and an hour figure on every line, and the total is uncomfortable rather than comfortable. The out-of-scope list contains two features the author clearly wanted. The capacity table admits an inconvenient truth — that Thursdays are gone, that the laptop has no administrator rights, that eight of the twenty hours in Week 5 are already spoken for by another course. The risk table names a risk about the student, not about technology. The hours log has an odd number in it — 2.25, not 3 — because it was written from a clock rather than a memory. And somewhere near the bottom sits a sentence like “if the walking skeleton is not green in CI by October 2, undo comes out first and the expiring-soon page collapses into a sort order” — a decision made calmly, in advance, by someone who knows that the version of themselves who will need it will not be calm.

The tell is always the same. A mastered charter contains at least one sentence that was uncomfortable to write. A weak one contains none, because it was written to be read rather than to be true.

Coach’s Note — Nobody will audit your hours log. No grader can prove that a 2.5 was really a 2.0. That is precisely what makes it a measurement of you rather than of your project. Eight weeks from now the log will either be a record you can point at in an interview — “here is how long a system like this actually takes me” — or a small fiction you had to keep consistent. One of those is worth having.

When You’re Done

  • Repository created; canonical tree committed; history spans ≥3 distinct days
  • README.md v0 answers what, who, status, which brief, navigation, and what is deliberately absent
  • Charter complete, §1 through §8, including §2 (the project itself)
  • At least five non-goals, each specific enough to point at in Week 5
  • At least three risks with early warning signs and responses; ranked cut order written down
  • Three briefs shortlisted and run through the Decision Engine; two rejected in writing
  • Adaptation record complete; every drafted requirement marked carry / repair / withdraw
  • Must list is three or four features, estimated bottom-up, inside 30/40 hours
  • Two estimates reconciled; the gap explained rather than averaged away
  • Out-of-scope list: at least eight items by name, two of them ones you want
  • Exactly one hard part named and justified
  • Every external dependency exercised for real; evidence saved and dated; novelty load counted
  • One user conversation written up with three verbatim quotes (or the competitive scan, with the reason stated)
  • Scope-cut trigger with a checkable condition and a real date
  • Board live: five columns, WIP limit enforced, ≥6 cards with estimates and stopping conditions
  • docs/hours-log.csv has ≥5 real rows, ≥12 hours, with pre-written estimates
  • tools/week1_check.py runs from a clean clone; the structure audit is clean
  • docs/ai-usage.md policy header complete; ≥2 entries with all six columns
  • Eight weeks blocked on a real calendar; the broken week’s hours moved forward
  • Week-1 quiz taken

A theological footnote. “For which of you, desiring to build a tower, does not first sit down and count the cost, whether he has enough to complete it?” (Luke 14:28, ESV). Jesus asks that on the way to a much larger point — that following him costs everything, and that the crowd trailing after him should know it before they sign. He is not giving project advice. But he builds the point on something he assumes every listener already understands: that a half-built tower is a public grief, that the wise builder sits down first, and that the shame is not in being unable but in beginning without knowing. Counting the cost is therefore a humble act, not a timid one. It requires looking squarely at your own limits — which is exactly what the capacity table in §3 of your charter makes you do, and exactly what an optimistic student avoids. This edition asks it of you in a sharper form than the long one does, because eight weeks will not forgive a scope you did not measure: the fifth feature comes off the list on Wednesday, or it comes off in Week 7 with your documentation attached to it. Do it now, while the cost of an honest answer is only a smaller project. And take the comfort that belongs to it: the tower we could never finish, the debt we could never count, was paid by someone who did finish — “It is finished” (John 19:30, ESV). That is why we can afford to be honest about the small things we cannot do. Our standing was never resting on our estimates being right.