Milestone 2 — Idea Portfolio & Scoping Decision

“Unless the LORD builds the house, those who build it labor in vain.” — Psalm 127:1 (ESV)

Chapter: Chapter 2 — Finding an Idea Worth 240 Hours Week: 2 of 16 · Inception (final week of the phase) Hat: Product owner Due: End of Week 2 Submit: A link to your repository, at the commit that contains everything below. Nothing is emailed; nothing is a zip file. The repository is the submission, this week and every week. Where it lands in the final package: The memo lives permanently at docs/scoping-decision.md; the three candidate canvases at docs/ideas/candidate-a.md, -b.md, -c.md; the interview write-up at docs/interviews/<date>-<initials>.md. In Week 3 the requirements specification cites the memo in its opening section; in Week 16 the memo is the document a grader opens to check whether what you shipped is what you said you would ship. See Appendix C for the full final rubric. AI policy: Open, with disclosure. Use an assistant as a sparring partner, a feature-list expander, and a hostile skeptic. Do not let it choose your project, write your problem statement, invent your user, or produce your hour estimates — it does not know how fast you are and it has never met your roommate. Every prompt that shaped this milestone gets a line in docs/ai-usage.md: what you asked, what it returned, what you kept, what you changed.

The Setup

On a real team there is a product owner. Their job is to hold the line between what the business wants and what the engineers can actually build in the time that exists. They are the person who says no twenty times a week and can defend every one of them. The reason that job exists is that engineers, left alone with an idea they like, will build until the calendar runs out.

You do not have one. So this week you are one — and you are also the engineer who has to live with what the product owner decides.

Here is your scenario. A sponsor has given you 240 hours. Not money: hours, which are worse, because they cannot be borrowed. They have asked for one document before they release any of it. It must say what you are building, who for, what evidence you have that anyone needs it, what it will cost in hours, what you have deliberately decided not to build, and what would make you cut scope. They have also asked what else you considered and why you rejected it — because a decision without alternatives is not a decision, it is a preference with a budget.

That document is this milestone. Write it as if the sponsor is real, because in thirteen weeks a version of them will read it and compare it to what you shipped.

Learning Targets

You will demonstrate that you can:

• Generate candidate projects from problems rather than technologies, drawing from multiple sources.
• Elicit and record evidence that a user exists — a real conversation, in the past tense, with verbatim quotes.
• Screen for feasibility: novelty load, verified external dependencies, a named deployment target, a demonstrable path.
• Estimate a scope bottom-up in vertical slices and reconcile it against an independent model.
• Right-size a project to a fixed hour budget, and say what you cut to get there.
• Decide under alternatives — score three candidates against named criteria and kill two, in writing, for stated reasons.
• Bound the work in advance: an explicit out-of-scope list and a scope-cut trigger with a date on it.
• Document a decision so that a stranger can check every sentence in it.

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 6 and one who finds out in Week 14. 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 6 is a conversation and a scope cut. A red discovered in Week 15 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. Three candidate idea canvases, one per candidate, at docs/ideas/candidate-a.md, -b.md, -c.md, from code/idea-canvas.md. Every field filled. Each problem statement in the six-line frame, including a which costs line with a real number. Each candidate must be one you would genuinely accept — no decoys.

2. One user conversation, conducted and written up at docs/interviews/<YYYY-MM-DD>-<initials>.md: date, length, who they are, the five past-tense questions you asked, the workaround they already use, and three verbatim quotes. (If your project genuinely has no user but you, substitute a competitive scan of three existing tools and say plainly why there is no external user. Do not invent one.)

3. A dependency-verification table in the memo. Every external dependency of every candidate, 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. It should look like this — note that two of the four rows are bad news, which is exactly why the table is worth building in Week 2 rather than Week 9:

   Dependency	Candidate	Exercised	Result	Key?	Rate limit	Terms read
   Product-lookup API	A	curl GET one barcode	200, JSON, no expiry field	yes, 10 min to obtain	documented on the vendor’s limits page	2026-09-05
   Recipe dataset	A	downloaded, 8 MB	usable; licence permits non-commercial use	no	n/a	2026-09-05
   University catalog API	B	attempted	UNVERIFIED — no public endpoint found; email sent 2026-09-03, no reply	unknown	unknown	—
   SMS provider	C	signed up	works, but trial credits only; costs money after	yes	per-message	2026-09-04

   Two things fall out of that table immediately. Candidate A’s barcode integration will never return an expiry date, so the design must ask the user for it — a requirement discovered in Week 2 for free instead of in Week 10 for eight hours. And Candidate B’s central dependency does not demonstrably exist, which is not a risk. It is a disqualification.

4. A bottom-up hour estimate for the chosen candidate, feature by feature, in vertical slices, with the walking-skeleton, CI, and deployment lines included, reconciled against the independent estimate from the 240-Hour Scope Sizer on the Chapter 2 page — run it on all three candidates, not just your favourite — and a stated gap.

5. The scoping decision memo at docs/scoping-decision.md, from code/scoping-decision-memo.md, containing all ten sections — including the out-of-scope list of at least eight named items, the two written rejections, the one hard part, and a scope-cut trigger with a real date.

6. The cut order, pre-committed. In the same memo, name the first three features that die, in order, if you arrive at the Week-8 halfway audit behind schedule — plus the evidence that will tell you it is time. Write it now, while you are calm and nothing is built; in Week 8 you will be asked to produce this list and say whether its trigger fired. This is the single cheapest insurance policy in the course. A student who has already decided what to cut cuts in twenty minutes; a student deciding under pressure in Week 12 usually cuts nothing and ships seven things at eighty percent.

7. Board and log current. Every Must feature is a card on the project board. The hours log has this week’s real numbers. docs/ai-usage.md has an entry for every session that shaped this milestone.

What counts as a genuine candidate

A candidate is not a sentence. It is a filled canvas: a costed problem statement, a named user, a Must-feature list with hours, a completed feasibility screen, and a rejection paragraph written in advance. Three of those is roughly four hours of work, and it is the four hours that make the decision defensible.

Two candidates you would never build do not count, and a grader can tell in about ninety seconds — decoys always have vague problem statements and unverified dependencies, because nobody does real screening work on an idea they have already discarded. If you find yourself unable to write an honest canvas for candidates B and C, that is the tell: go back and generate two you would actually accept.

Normal-tier rubric (out of 100)

Medium Tier (+up to 25% extra credit)

Deeper evidence and a second opinion on your own numbers. Pick what fits your project:

• Two more conversations, with people in different roles or segments, plus a half-page affinity summary: what all three agreed on, what only one person said, and which of your planned features nobody mentioned. That last list is your first scope cut.
• A competitive scan. Three existing tools that address your problem. For each: what it does well, what it does badly, and the specific gap yours fills. If there is no gap, write that sentence honestly — it is a finding, not a failure, and it changes your positioning rather than killing the project.
• A timeboxed spike. Two to four hours, hard stop, spent proving the single riskiest technical assumption in your chosen candidate — the one that would hurt most if it turned out to be false. Write up the result either way. A spike that disproves your assumption in Week 2 is worth more than one that confirms it.
• A three-point estimate. Re-estimate your chosen scope with optimistic / most-likely / pessimistic figures per feature, compute the expected value, and reconcile it against your bottom-up number and the sizer. Three independent estimates that agree are a plan; three that disagree tell you where your uncertainty actually lives.
• The four-week-loss plan. One page: the smallest version of this project that would still be worth doing and still be defensible, if you lost four weeks to illness, a job, or a dead dependency. Name which features survive and in what order the rest die.

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

Judgment, in writing, that no assistant can produce for you — because it requires owning a decision, and ownership is the one thing a tool cannot do.

Write a two-to-three page Cost Memo, addressed to your sponsor, that does four things:

• Argue against your own choice. Make the strongest honest case that you picked the wrong one of the three. Use the evidence you gathered, not straw. Then explain why you are proceeding anyway — the tradeoff, named, with your eyes open. A memo that cannot argue the other side has not considered it.
• Name the feature you most want to build and are cutting. Then 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.
• Stress-test your own cut order. You already pre-committed one in the Normal tier. Here, argue against it: which of those three cuts would hurt the user most, and what would have to be true for you to cut something else instead? Then state the one feature you would never cut, and what you would sacrifice to protect it. Sign it. In Week 8 you will be asked to produce this and say whether the trigger fired.
• Make the AI call. State whether your project will contain an AI feature, and judge it against the five tests in §2.8 — necessity, evaluation, fallback, cost cap, data. If it is a garnish, say so and cut it here. If it is honest, write its acceptance criterion, its fallback, and its spend cap now. Then state what you will and will not use an assistant for during the build, and how you will log it.

Graded on honesty, specificity, and self-awareness. Vague hedging scores zero; a memo that admits a real weakness and commits to a real trigger scores full marks.

Submission

Commit everything and submit the repository link.

your-capstone/
├── README.md
├── docs/
│   ├── charter.md                        # from Week 1
│   ├── scoping-decision.md               # THE artifact this week
│   ├── ai-usage.md                       # a line per session
│   ├── hours-log.csv                     # Week 2 hours, honestly
│   ├── ideas/
│   │   ├── candidate-a.md
│   │   ├── candidate-b.md
│   │   └── candidate-c.md
│   ├── interviews/
│   │   └── 2026-09-04-rm.md
│   └── evidence/
│       └── dependency-checks/            # saved responses, screenshots, dates
└── cost-memo.md                          # Hard tier only

Commit message: milestone-2: scoping decision, three candidates, two rejected.

Hints

• Do Rep 4 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.
• Write the rejections while you still like the ideas. A rejection composed after you have committed is a rationalization, and it reads like one.
• Fill the out-of-scope list before the in-scope list. It is easier, it is more honest, and it makes the in-scope list shorter, which is the actual goal.
• Make the API call before you write the sentence. Every “I will use X” in your memo should already be a saved response with a date next to it.
• When the 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 is still better than an adjective. Write “roughly 12 hours, low confidence” rather than “a fair amount of work.” The first can be corrected in Week 7; the second cannot be anything.
• If you cannot bring yourself to kill two, you did not generate three real candidates. Go back to Rep 1 and Rep 2.
• Name the hard part before you name the stack. If you cannot say what the hard part is, the project may not have one, and a capstone with no hard part is a semester of typing.
• Do not let the assistant write the problem statement. Generated problem statements are fluent, plausible, and describe nobody. Write yours from your own interview notes, then ask the assistant what is missing.
• Keep the memo under two pages. Length is not rigor. A two-page memo where every sentence is checkable beats a six-page one padded with context nobody asked for.

If You Are Stuck

Four specific unsticking moves, in the order to try them.

1. No ideas at all? Do Rep 1 with the technology ban enforced, then open Appendix D and read the entries in two domains you would not normally pick. You are not looking for a project to adopt; you are looking for the shape of a problem that reminds you of one you already know about.
2. Three ideas, all too big? Run every one through the Scope Sizer and take the two cuts it names for each. If all three still fail, the pattern is almost certainly novelty load or integration count, not features — and both of those are choices you can reverse today.
3. One idea you love and cannot find two others? That is the most dangerous position in this milestone, because it produces decoys. Force the search: generate the second candidate from the client well and the third from the campus well, which are the two most likely to surface a problem somebody has already asked for help with.
4. Cannot find anyone to interview? Widen the definition of the user before you abandon it. The person who has the problem is not always the person you imagined — for a departmental tool it may be the office administrator rather than a student; for a developer tool it may be a maintainer in an issue thread. And if it genuinely is nobody, say so in the memo and do the competitive scan instead. Honesty here costs you two points. A fabricated interview costs you the course.

Two Sections, Written Badly and Well

The two sections graders find weakest are the out-of-scope list and the scope-cut trigger. Here is each, at zero points and at full points.

Out of scope — the version that earns 2 of 10:

Out of scope: extra features, anything too complicated, stretch goals, stuff that isn’t essential, advanced functionality, nice-to-haves, future versions, anything not in the MVP.

Read those eight items and try to tell whether “a barcode scanner using the phone camera” is in or out. You cannot, and neither can you in Week 10, which is when you will “just add” it. Every one of those phrases is a category, not a feature. A boundary you cannot check is not a boundary.

Out of scope — the version that earns 10 of 10:

Out of scope, and will not be built. Camera-based barcode scanning (the user types the number) · nutrition data · a shopping-list generator · waste analytics or charts · recipe import from a URL · email or push notifications · more than one household per install · offline use · password-based accounts · a native mobile client. Two of these I want to build: camera scanning and the shopping list. They stay out because together they cost roughly 23 hours against a construction budget with four hours of slack.

Every item is a thing, not a category. A stranger can hold any feature up against the list and get a yes or a no. And the author has named the two they wanted — which is how you can tell the list was written honestly rather than composed of things nobody would have built anyway.

The scope-cut trigger — the version that earns 1 of 6:

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

There is no condition, no date, no order, and no way to be wrong. It commits the author to nothing, so in Week 10 it will protect them from nothing.

The scope-cut trigger — the version that earns 6 of 6:

Scope-cut trigger. Checked at the Week-8 design review (2026-10-20) and again at the end of Week 9 (2026-10-27). Condition: if the walking skeleton is not deployed and green in CI by 2026-10-27, I cut in this order — (1) household sharing, reverting to a single local pantry; (2) barcode lookup, reverting to manual entry with the integration removed from the requirements specification; (3) the configurable expiry window, fixed at seven days. I will record the cut in CHANGELOG.md and update docs/requirements.md the same day, rather than quietly not building things.

A checkable condition. Two real dates. A named order. And a commitment about documentation as well as code, which is the part students forget: a feature that silently disappears from an unedited specification reads, in Week 16, as a feature that failed.

What Mastery Looks Like

A master’s scoping memo is boring to read and impossible to argue with. Every claim in it has a number, a date, a quote, or a named condition attached. The problem is somebody else’s problem, described in their words. The scope is small enough to be embarrassing and large enough to be defensible, and the author says exactly what they cut to make it fit and what that costs the user. The rejected candidates are rejected for reasons a stranger would accept, and one of them is rejected on judgment rather than arithmetic. And somewhere near the bottom there is a sentence like “if the walking skeleton is not running in CI by October 27, household sharing is cut first” — a decision made calmly, in advance, by someone who knows that the version of themselves who will need it will not be calm.

That last sentence is what separates an engineer from a student with a good idea.

Coach’s Note — You will be tempted to make the scope a little bigger than the arithmetic allows, because the honest version feels too small to be proud of. Resist it, and remember where the points are: nobody has ever lost marks for shipping five features that all worked, were tested, were documented, and ran on somebody else’s machine. Plenty of people have lost a semester to eleven features that did not.

When You’re Done

• Three complete candidate canvases committed, no decoys
• which costs line filled with a real number on all three
• One user conversation conducted, written up, dated, three verbatim quotes
• Every external dependency exercised for real; evidence saved with dates
• Novelty load counted for each candidate; anything above 2 has a swap named
• Bottom-up estimate done by hand, feature by feature, in vertical slices
• Sizer run on all three; the gap between the two estimates explained
• Two candidates killed in writing, each with the gate it failed
• Out-of-scope list: at least eight items, by name
• The one hard part named — exactly one
• Scope-cut trigger written with a checkable condition and a real date
• Board updated, hours logged honestly, docs/ai-usage.md current
• Everything committed; repository link submitted

A theological footnote. “Unless the LORD builds the house, those who build it labor in vain” (Psalm 127:1, ESV). Notice that the psalm does not tell the builders to stop building. It assumes them — the labor is real, the fatigue is real, the house goes up. What it denies is that effort alone founds anything. That is a strange comfort to hand a student in Week 2, and it cuts two ways. It cuts against the tower: the project scoped to impress, sized to the reputation its builder wants rather than the need it serves, is the one Genesis 11 warns about, and it is also the one that consumes eleven weeks and ships nothing. And it cuts against despair: you are going to estimate something wrong this week, and the answer is not to grip the plan harder. Count the cost honestly, as Luke 14:28 says — sitting down to count is humility, not pessimism — draw the boundary, and then work faithfully inside it. A small tool that keeps four people from throwing out food is not a modest project pretending to be grand. It is real work, at its real size, serving a real neighbor. That is what work is for, and it is enough.