Milestone 15 — Presentation Deck, Demo Script & Rehearsal

“Let another praise you, and not your own mouth; a stranger, and not your own lips.” — Proverbs 27:2 (ESV)

Chapter: Chapter 15 — The Thirty-Minute Case Week: 15 of 16 · roughly 15 hours · feature freeze is in effect Due: End of Week 15, before your Week-16 delivery slot Submit: Commit everything under docs/presentation/ in your repository, push, and paste the commit URL into the Canvas milestone dropbox Where it lands in the final package: docs/presentation/ — deck.pdf, run-sheet.md, demo-script.md, demo-fallback.mp4 (or a link to it), qa-prep.md, rehearsal-log.csv, not-done.md. These artifacts are graded twice: they are the talk that carries 10 percent of the course grade next week, and they feed the documentation-completeness line of the Week-16 rubric (the 50 percent). AI policy: Open for preparation, closed at the podium. An assistant may generate hostile questions, tighten a wordy slide, run a demo pre-mortem, and read your one-liner as a stranger. It may not write a slide you cannot source, produce a claim you cannot defend, or be consulted live during the talk or the Q&A. Log every substantive use in docs/ai-usage.md — you will be asked about it next week, on the record.

The Setup

Your software works. It runs on a machine that is not yours, from a tagged release, with a runbook and a handoff guide. That was last week.

Next week you get thirty minutes and a room.

The room contains people who have not read your code, did not attend your design review, and will form their entire impression of fifteen weeks of engineering from what happens in those thirty minutes. Some of them will be faculty. Some may be industry guests. All of them have sat through capstone talks before, and all of them can tell within ninety seconds whether they are watching someone who owns their project or someone who is describing a thing that happened to them.

This is not an artificial exercise. It is the most-transferred skill in the entire course. You will do this at a sprint review in March, at a design review in your second year, in front of a customer, in front of a VP whose budget you need. The shape never changes: fixed time, non-expert audience, decision riding on comprehension. The engineers who can do this get to build what they think should be built. The ones who cannot get overruled by someone who can, and the better system loses.

So this week you build the case. Not the software — that is frozen. The case. A run sheet that fits thirty minutes, a deck built from artifacts you already own, a demo script that survives a bad network, a recording that plays with the wifi off, ten questions you have already answered, and three rehearsals with the timing written down.

Here is what the first ninety seconds sounds like in each version, because those ninety seconds set everything that follows.

BAD — ninety seconds, zero information transferred:

"Hi, um, so my name is — you probably know — anyway, my capstone project is called
PantryPilot. So, agenda: first I'll talk about background, then the technologies I used,
then a demo if it works, then future work. So, background. Food waste is a big problem
globally, there are a lot of statistics about it — I read that a third of food is wasted?
Something like that. And there are some apps out there but I felt like none of them
really did what I wanted, so I decided to build my own..."

Ninety seconds spent on an agenda the room can read, a global statistic the presenter is not sure of, and a motive (“what I wanted”) that is not a user. Nobody yet knows what the software does. The word “if” has already appeared next to “demo.”

GOOD — same ninety seconds:

"PantryPilot tells a household what food is about to spoil and what they can cook from
what's already in the kitchen.

The users are my four roommates. Over one logged month we threw out thirty-eight dollars
of food, and every single item was something somebody had bought twice or forgotten about.

I committed to twenty-two functional requirements, fourteen of them MUSTs. I shipped
thirteen of the fourteen. The one I didn't ship is on slide 17, with the reason.

Here's how it's built."

One sentence for the what. One number for the problem, from a real month with real people. A scope claim with counts, and the shortfall named before anyone has to go looking for it. Ninety seconds, four facts, and a room that is now paying attention because it has been told the truth about the ending.

Learning Targets

You will demonstrate that you can:

• Compress a semester of engineering into a 30-minute structure with an explicit, defensible time budget.
• Build a deck from evidence — every slide traceable to a real artifact in your repository, every number carrying its source and date.
• Script and de-risk a live demo: seeded data, deterministic steps, requirement IDs, a time budget, and a written failure protocol.
• Produce a fallback that works when the network does not.
• State shortfalls accurately — what did not get done, the real cause, and the cost to finish.
• Anticipate hostile questions and answer them in one sentence, including the honest “I don’t know.”
• Rehearse as measurement, not as ritual: timed passes, logged actuals, and cuts driven by data.
• Present AI-assisted work honestly, ready to say exactly what you wrote and what you verified.

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. docs/presentation/run-sheet.md — ten sections, minutes and cumulative times, slide numbers, a key line per section, and a KEEP/CUT marker. Total ≤ 30:00. Questions ≥ 3:00. Demo ≤ 7:00. Start from the provided template, code/talk-run-sheet.md.
2. docs/presentation/deck.pdf — the finished deck, exported to PDF, ≤ 22 slides, one idea per slide, 24 pt minimum body text, no animations. Build it against the provided skeleton in code/slide-outline.md. Keep the editable source alongside it.
3. Problem, users, and scope in the first three content slides, including the one-sentence description (≤ 25 words) and the MUST-requirement count from your specification.
4. Architecture and two decisions — one diagram from docs/architecture.md, plus two slides each naming a real choice, the alternative you rejected, the constraint that decided it, and what it cost you. Cite the ADR by number.
5. docs/presentation/demo-script.md — six or seven numbered steps from the provided template, code/demo-script.md: exact action, exact expected result, seconds budget, requirement ID, and failure fallback per step, plus the header block (target, placeholder account, seed command, reset command, network needed) and the written failure protocol.
6. A recorded fallback demo at docs/presentation/demo-fallback.mp4 (or a link, if the file is too large to commit), trimmed to the demo’s time budget, with per-step timestamps written into the script’s failure column — and verified to play with the network disabled.
7. Three evidence slides built from your own artifacts: verification (test counts and what is not tested), defects (opened / closed / open by severity, plus the worst open one), and your top non-functional requirement with a measured number, a method, and a date.
8. docs/presentation/not-done.md and the matching slide — up to three items, each with the requirement ID, a cause that is not “time,” and an hour estimate to finish.
9. docs/presentation/qa-prep.md — ten anticipated questions, a one-sentence answer to each, and the back-pocket slide number where one exists.
10. docs/presentation/rehearsal-log.csv — three timed passes, columns pass,section,planned_min,actual_min,note, plus a short rehearsal-notes.md recording what you cut between passes. Analyze it with the provided script, code/pace.py.
11. Hours logged in docs/hours-log.csv for every one of the above, honestly.

Normal-tier rubric (out of 100)

Medium Tier (+up to 25% extra credit)

Pick what genuinely fits your project. Quantity is not the point.

• A fourth and fifth timed rehearsal in front of two different humans, with their comprehension answers recorded: what is this for, what was the hardest part, what did not get done. Log which slide you changed because of each answer.
• A second demo path for a different audience — the two-minute version you would give a recruiter at a career fair, scripted and timed to 2:00 exactly.
• A measured non-functional result you did not previously have. Run the load or latency test at a level you never tried, record the command and the date, and put the honest number on the slide even if it is worse than you hoped.
• A traceability slide mapping your demo steps to requirement IDs to test IDs — the one slide that proves the whole spec-to-verification chain in a single picture.
• Accessibility pass on the deck: contrast checked, no information carried by color alone, a readable sans-serif at size, and alt text in the exported source. Note what you changed. (W3C accessibility guidance: https://www.w3.org/WAI/)
• A live-captioned or recorded full run of the entire thirty minutes posted with your milestone, so your future self can watch the pacing.

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

A two-page Credibility Memo, addressed to your committee, submitted with the milestone. No assistant can write this for you, because every paragraph requires you to own a judgment about your own work.

Answer all five, in prose, with evidence:

1. The claim you are least able to defend. Find the single sentence in your deck that has the weakest evidence behind it. Quote it. Say what evidence would be required to make it solid, why you do not have that evidence, and what you will say if someone asks about it next week.
2. The self-flattering framing you removed. Every deck has one — a phrasing that made a compromise sound like a design, or a partial feature sound complete. Show the before and after, and explain what made the first version untrue rather than merely generous.
3. The question you are most afraid of. Write it out. Write your ninety-second answer. Then say plainly whether that answer is a real answer or a deflection, and if it is a deflection, what you would need to do to earn a real one.
4. The AI accounting. State exactly where an assistant contributed to this project, what you changed about its output, what you verified and how, and — the part that matters — what you deliberately refused to delegate, with your reason. Reconcile this against docs/ai-usage.md; if they disagree, fix the log, not the memo.
5. The honest grade. Score your own project against the Week-16 rubric in Appendix C and justify each line in one clause. Then name the gap between that score and the one you want, and say what the gap is made of.

Graded on judgment, self-knowledge, and accuracy — not on how favorable it is. A memo that finds nothing wrong scores lower than one that finds something real, because the first one is not a memo, it is a press release.

Submission

Commit under docs/presentation/, push, tag nothing (the release tag is Week 16), and paste the commit URL into Canvas:

docs/presentation/
├── run-sheet.md            # ten sections, timed, ≤ 30:00
├── deck.pdf                # exported; keep the editable source beside it
├── deck-outline.md         # slide-by-slide plan with sources
├── one-liner.md            # ≤ 25 words, tested on a human
├── demo-script.md          # steps, seeded data, requirement IDs, failure protocol
├── demo-fallback.mp4       # or fallback-link.txt if too large to commit
├── evidence.md             # the three numbers and where each came from
├── not-done.md             # up to three items: ID, cause, cost
├── qa-prep.md              # ten questions, ten one-sentence answers
├── rehearsal-log.csv       # pass,section,planned_min,actual_min,note
├── rehearsal-notes.md      # what you cut between passes
└── credibility-memo.pdf    # Hard tier only

Update docs/hours-log.csv and CHANGELOG.md in the same commit. Suggested message: milestone-15: presentation deck, demo script, three rehearsals logged.

Note on weighting. Like every milestone in this course, Milestone 15 carries its own points in the 25% milestone bucket — and these artifacts are then graded twice more: as the talk that carries 10 percent next week, and as part of the documentation line of the Week-16 submission that carries 50 percent. Skipping the milestone does not save points. It forfeits them once and relocates the rest to the one week that has no slack left in it.

Read the assessment before you build. The full brief for the graded talk — format, timing, exactly what must be covered, delivery logistics, the recorded-fallback requirement, and the 100-point presentation rubric — is The Capstone Presentation assessment that ships with this chapter, and it is restated alongside the whole grading contract in Appendix C. Build the deck that rubric asks for. Students lose points every year for a beautiful talk that answers a different set of questions than the one being scored.

Hints

• Build the deck with your repository open on the other monitor. Every slide gets a source artifact. If a slide has no source, either the artifact is missing (fix that — it is worth 50 percent) or the slide should not exist.
• Write the run sheet before the deck. Slides expand to fill whatever time you have not yet allocated. Allocate first.
• Seed everything. The single most common demo failure is typing on stage. It is slow, it is error-prone, and the room watches you do it.
• Record the fallback early in the week, while the demo path is fresh and while there is still time to re-record. Students who leave it for Sunday end up with an unusable one-take recording of a demo that failed.
• Rehearse out loud. Silent rehearsal runs roughly 30 percent fast. That gap is exactly how a 27-minute plan becomes a 34-minute talk.
• When you are over time, cut content — never speed up. A rushed thirty-minute talk is worse than a calm twenty-six-minute one, and the committee will remember the rushing, not the content.
• Practice the sentence “I don’t know” out loud at least once. It is a skill, it is short, and it earns more credibility than any bluff you could construct.
• Bring your own hardware. Your laptop, your charger, your display adapter, your hotspot if you have one, and the deck on a USB drive as a PDF. Assume the room provides a projector and nothing else.
• Put the demo on a black slide. Do not present through the deck into the browser; switch cleanly. Fumbling between windows is the most-noticed thirty seconds in any student talk.
• Do not touch a feature. You are frozen. Defect fixes only, small, tested, and committed separately with a message that says so.

The five ways this milestone usually goes wrong, so you can steer around them:

What Mastery Looks Like

A master’s capstone talk does not feel like a presentation. It feels like a competent engineer walking you through a system they know completely, in the exact order you needed to hear it.

You can tell within two minutes. The one-sentence description lands and everybody knows what the software does. The problem has a number attached to it, not an adjective. The scope slide names what was cut before anyone asks. The architecture diagram gets talked through slowly, in plain language, with the presenter pointing at the box they mean. The two decision slides each name a rejected alternative and a real cost — the mark of someone who chose rather than defaulted.

Then the demo runs, on seeded data, in seven minutes, doing exactly what was promised — and when a step misbehaves, the presenter says “that’s DEF-041, here’s the recording,” and keeps moving without breaking stride. The evidence slides carry numbers with dates and file paths. The “what did not get done” slide arrives without apology and with hour estimates. And in the Q&A, the hard question gets either a specific answer or a clean, bounded “I don’t know — here’s what I do know, and here’s how I’d find out.”

Nobody in that room is thinking about slide design. They are thinking: this person could be handed a real project on Monday.

Coach’s Note — The talk you will be tempted to give is the one that makes you look good. The talk that actually makes you look good is the one that makes your work legible — where you get out of the way and let the demo, the tests, and the defect log speak for themselves. Every hour you spend on evidence buys more than an hour spent on polish. Polish is what students do when they have no evidence.

When You’re Done

• Run sheet complete: ten sections, ≤ 30:00 total, ≥ 3:00 for questions, demo ≤ 7:00
• One-sentence description ≤ 25 words, tested on a human who restated it correctly
• Deck built and exported to PDF, ≤ 22 slides, six-foot test passed on every slide
• Every slide traceable to an artifact in your repository
• Two decision slides, each with a rejected alternative, a constraint, a cost, and an ADR number
• Demo script written, seeded, and executed cold at least once on a timer
• Fallback recorded, trimmed, timestamped into the script, and played with the network off
• Three evidence slides, every number carrying its source file and date
• “What did not get done” slide: three rows, IDs, causes that are not “time,” hour estimates
• Ten questions prepared with one-sentence answers; three unanswerable ones triaged
• Three timed rehearsals logged; pace report reviewed; cuts made from data
• docs/ai-usage.md current and reconciled with what you will say out loud
• docs/hours-log.csv and CHANGELOG.md updated; everything committed and pushed

A theological footnote. “Let another praise you, and not your own mouth; a stranger, and not your own lips” (Proverbs 27:2, ESV). This is the week that verse stops being a nice sentiment and becomes a working method. You cannot spend thirty minutes insisting your work is good — nobody in that room has any reason to take your word for it, and they should not. What you can do is put strangers in front of them: a demo that runs, a test suite that passes, a defect log that volunteers evidence against you, an hours log that says where the time actually went. Those are witnesses with no incentive to flatter you, and that is exactly why they are believed. Notice too that the same discipline governs the other direction. False witness about yourself is still false witness whether it inflates or deflates, and the student who says “this is nothing, really” is making an inaccurate report to people relying on it. Your standing was never riding on these thirty minutes anyway; it was settled somewhere else, at a much higher cost. That is precisely what frees you to be accurate — to show the defect log, name the unbuilt feature, and say “I don’t know” in a graded room without flinching. Build the case. Then step aside and let the work speak.