Sprint Notes and Demos

Submission: Team, with the individual contribution modifier
Due: Every sprint: 4 in fall, 5 in winter, 3 in spring
Weight: 2% each: 8% of the fall grade, 10% of the winter grade, 6% of the spring grade; pass/fail per item

At the end of every two-week sprint, the team submits a one-page sprint note and demos working software. There is no long-form progress report in this course. The note is evidence plus judgment, not prose: if your repository and board are in order, producing it takes 15 minutes.

AI use: you may generate the evidence with AI from your own repo history and board. Two things must be human-written, because they are the parts anyone reads: the judgment layer, and the one sentence in each contribution line saying what you shipped and how you know it works. Start from the sprint note template.

The Sprint Note (one page, five items)

Working software evidence: a URL, tagged release, or demo video, plus the CI run. If nothing works yet, say so plainly and say why.
What got done: the things the team actually finished this sprint, each one concrete and consequential. Link the board.
Top risk and one decision needed: the single biggest threat to shipping (in fall, before your Definition of Shipped exists, the biggest threat to the term gate), and one concrete decision the team needs from the partner, the staff, or itself.
Contribution lines: one per student, in the shape below.
Judgment layer (about five lines, human-written): what the team learned this sprint and what it changes about the plan.

What counts as “done”

Concrete means someone could go and look at it. Consequential means the project is meaningfully further along because of it. It does not have to be code. A partner agreement reached, a dataset cleared for use, a deployment pipeline that now works, a real-user session run and written up, a flaky test suite made reliable: all of these are done things worth naming. Work that is not code counts when it is measurable, which means it landed in the repository as a written PR someone can open: findings, interview notes, a requirements section, an RFC section. Research with nothing to open is activity.

What does not count is activity without a result. “Worked on the API”, “researched options”, “had meetings”, and “made progress on the frontend” describe how time was spent, not what exists now that did not exist two weeks ago.

Everything in this list should be something you can show. The demo and this list are the same content in two formats.

Contribution lines

One line per student, three parts:

The pull request(s) you owned this sprint, by title or ID. NDA teams list IDs only. Owning it means you authored or drove it, answered review, and merged it. A written artifact counts when it landed as a PR like anything else; a rename, a formatter run, a lockfile bump, or a status update does not.
Whose work you reviewed, and the one change you asked for. Name it specifically: “asked Priya to handle the empty-cart case in checkout” is a review; “LGTM” is not, and neither is a comment that names no line and requests no change.
The most consequential thing you shipped this sprint, in one sentence, and how the team knows it works. This is the part with judgment in it, and it is the part that is read.

Also name who chaired a decision this sprint and which decision they drove to a conclusion. Over a term every student should appear here at least once. This is the record your defense role criterion is checked against, so it saves you reconstructing your own leadership from memory in week 8.

Counting pull requests and reviews gives staff something countable, which matters because “everyone says they contributed” is not evidence. But volume metrics are easy to inflate and easy to misread, so three rules bound them.

Mechanical changes are not evidence. A formatter run, a lockfile bump, a bulk rename, a generated file, a dependency update: all normal work, none of it a signal about contribution. Do not pad your line with them, and staff will not count them. This is exactly why the course does not use lines of code: a lint pass can move ten thousand lines and mean nothing.

The numbers are only ever read as a pattern. One sprint where you shipped little, with an explanation, is ordinary life. Four sprints of nothing with no explanation is the thing the modifier exists for. No single sprint’s count decides anything.

The sentence outranks the counts. A student with one pull request who can say what it made possible and how they know it works is contributing more than a student with six and nothing to say about any of them.

Demo Cadence

Every sprint, your team demos to your TA in your cohort check-in, and every student demos the part they owned. The check-in falls in the sprint-note week, on the day your TA sets. One team, one TA, nobody else’s team in the room. Your TA picks what you demo, from your latest sprint note’s contribution line (from the board, for the first one): open the PR or the document you listed, show the change, run it. Showing the same artifact at two check-ins running is nothing new, and nothing new is no contribution that sprint. Two to three minutes each, so 6 to 12 minutes of a 25-to-30-minute check-in for a team of three or four. The rest of the check-in is your top risk and the decision you need; anything that would have been open-ended TA coaching happens async between check-ins.

Demoing your own work every two weeks is the point. It is the same claim your contribution line makes, made out loud in front of the people who would know if it were not true, and it is twelve rehearsals before the Expo.

When the check-in is taken by a checkpoint walkthrough (NDA projects), attach a demo video to the sprint note instead: one video, timestamped, one segment per student. Timestamps are not a formality. They are what makes each student’s segment individually findable and scoreable, which is the whole reason the video substitutes for the live slot.

Two all-hands demo days per term, around weeks 5 and 10, put a sampled lineup in front of the whole cohort with partners invited. These are not assessed. They exist because seeing what eleven other teams built is good for morale and occasionally changes what you decide to build next.

Rubric (100 points)

Each note is checked pass/fail per item, 20 points each; the rubric conventions say why sprint notes have two bands instead of three. The note is a professional habit, not an essay.

Item	Pass (20)	Fail (0)
Working software evidence	A URL, tagged release, or demo video is provided (link the CI run when one exists); or the note says plainly that nothing works yet and why. Where the video substitutes for a live demo slot, it is timestamped with one segment per student.	Item missing: no evidence and no plain statement of why nothing works yet.
What got done	Links to the board and lists what the team finished, each item concrete and consequential. Non-code work counts. Activity without a result (“worked on the API”, “researched options”) does not.	Item missing: no board link, or the list describes how time was spent rather than what now exists.
Top risk and one decision needed	Names the single biggest threat to shipping (the Definition of Shipped once it exists; the term gate in fall) and one concrete decision the team needs from the partner, the staff, or itself.	Item missing: no top risk, or no concrete decision needed.
Contribution lines	One line per student with all three parts: PR(s) owned (titles or IDs; NDA teams list IDs only), whose work they reviewed and the specific change they asked for, and a human-written sentence on the most consequential thing they shipped and how the team knows it works. A missed PR norm is explained on that student’s line. The owned PR is a real change that landed this sprint; graders open one per student.	Item missing: contribution lines absent or incomplete (students unaccounted for, or an owned PR that does not open, did not land this sprint, or is mechanical, with no explanation on the line).
Judgment layer	About five human-written lines on what the team learned this sprint and what it changes about the plan; any genuine, sprint-specific content passes.	Item missing: judgment layer absent, or the same text reused across sprints.

Individual contribution modifier: half of each sprint note’s points are individual and default to full credit. A student’s individual half is reduced when the sprint’s evidence (contribution lines, repo record, review activity) shows no meaningful contribution. Deductions are flagged by the cohort TA with the evidence noted, and confirmed by an instructor following the corroboration process on the partner evaluation page; no deduction lands without a written evidence note you can see and respond to. You have five business days from notification to respond with evidence; an instructor makes the final call. Missing your PR-per-sprint norm once with an explanation in the note is normal life; a pattern with no explanation is what this modifier exists for.

Activities That Prepare This

Twelve sprint notes a year means per-note recommendations would be silly. Three activities are worth doing once, in fall, and then never again: Kanban Board Setup, Definition of Done, and Regular Stand-Up Meetings. Get those right and the note takes fifteen minutes every time.

Two are worth repeating: Prioritization for the top-risk-and-decision item, and Learning Journal for the judgment layer, which is the part staff actually read.

Browse planning for anything touching the board, estimates, or risk.