Sprint Notes and Demos
Canvas is the source of truth for this term’s assignments. This page may already show changes Canvas does not have yet.
Every two-week sprint ends with a one-page sprint note, due by Sunday of the sprint’s second week, and a demo of working software at your TA check-in that week. The note is evidence plus judgment, not prose: if your repository and tracker are in order, producing it takes 15 minutes. The sprint guide covers how to plan, run, and review a sprint; the windows below are when this course’s sprints fall.
| Term | Sprints | Sprint windows |
|---|---|---|
| Fall | 1 to 4 | Weeks 3 to 4, 5 to 6, 7 to 8, 9 to 10 |
| Winter | 5 to 9 | Weeks 1 to 2, 3 to 4, 5 to 6, 7 to 8, 9 to 10 |
| Spring | 10 to 12 | Weeks 1 to 2, 3 to 4, 5 to 6 |
What You Produce
Section titled “What You Produce”The sprint note is one page with 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 where the work is tracked: the board, the issue list, or the pull requests.
- 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 next checkpoint milestone), and one decision the team needs, naming who makes it: the partner, the instruction team, or the team itself. Take the risk from the top of your
docs/risks.md. - 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.
An early sprint can be light on code, or have none, and that’s fine when the note says where you are and why. For example:
- No code yet, by agreement: the partner asked for a research and planning phase first. Done: the comparison of existing tools the partner reviewed, the requirements draft they approved, notes from interviews with their staff.
- No code yet, by agreement: the partner wanted the design settled before any build. Done: the architecture the partner reviewed, ADRs (architecture decision records) for the storage and hosting decisions, a data model, the interface contract with the partner’s existing system.
- No working software yet: the open-source project you contribute to builds and passes its tests on every member’s machine, and the first pull request, a documentation fix, is in review.
- The pipeline runs end to end on synthetic data; the real data waits on the data agreement, whose owner is named under Top risk.
- A clickable prototype only, because the partner’s system access hasn’t been granted; the request is linked.
Each sprint, update the living docs for what the sprint changed, starting with docs/requirements.md, docs/design.md, and docs/risks.md. In fall and winter the next repo checkpoint checks them; in spring they go to whoever continues the project, through the Project Handoff.
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.
What counts as “done”
Section titled “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. So are a literature or prior-work review the partner discussed with you, a requirements document the partner approved, an architecture or design document the partner reviewed, a design decision recorded as an ADR, a prototype the partner tried, an IRB application submitted, and a development environment that builds from README.md for every member. Work that is not code counts when someone can check it, wherever it lives: findings, interview notes, a requirements section, an RFC section.
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
Section titled “Contribution lines”Every sprint, every student owns at least one piece of work that someone else accepted. That is the contribution floor, and Individual Contribution says how the evidence for it is read.
A piece of work is something you owned that a grader can check. A code change is its pull request. Other work is the issue, ticket, or document where it lives, in the tracker your CONTRIBUTING.md names. Accepted means someone else reviewed and took it: the pull request approved and merged, the issue or ticket closed with its outcome, the document approved, including by your partner in their own system.
One line per student, three parts:
- The work you owned this sprint, one or more pieces, each with a link or ID. NDA teams list IDs only. Owning it means you authored or drove it, answered review, and saw it accepted. A rename, a formatter run, a lockfile bump, or a status update does not count. If a grader cannot open it (your partner’s system, an NDA), give its ID and show it at your check-in demo.
- A review you gave this sprint, and what it said. Any artifact counts: a pull request, a spec, a design, a test plan, a document, a dataset. Link it or give its ID where the review is recorded (a pull request review, a document comment, an issue thread), and name either the change you asked for (“asked Priya to handle the empty-cart case in checkout”) or, for an approval, what you checked before approving (“ran the migration against a copy of the seed data and compared row counts”). A bare “LGTM” is not a review, and neither is a comment that names nothing checked and requests no change. If you reviewed nothing this sprint, say so here.
- 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’s the part that’s read.
If a teammate has nothing this sprint, their line says so plainly, and so does a review part with no review behind it. The team’s Contribution lines item still passes either way; whether it costs that student anything is their individual contribution’s question.
Google’s code review standard is worth reading on where that bar sits: approve once the change improves the overall code health of the system, even when it is not perfect, and say what would need to change if it does not.
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 at your defense.
Demo Cadence
Section titled “Demo Cadence”Every sprint, your team demos live to your Teaching Assistant (TA) in a check-in during the sprint-note week, in person or over Zoom, at a time your team and your TA agree. One team, one TA, nobody else’s team in the room. Every student demos their own work: pick one artifact from your contribution line for this sprint (a piece of work you listed as owned), open it, show the change, and run it. It cannot be the artifact you showed at the last check-in: nothing new to show means nothing was done that sprint. Your TA follows up with a question about what you showed, such as which lines are yours or what your reviewer asked you to change.
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. Your demo makes the same claim as your contribution line, out loud, in front of the people who would know if it weren’t true.
Sprint Notes 1: the fall week 4 check-in is the week before Repo Checkpoint 1. After the demos, the time for your top risk and decision goes to a review that is not graded: your TA goes through what Repo Checkpoint 1 asks for against your repository, so you find what is missing with a week left to fix it.
A video replaces the live demo in two cases only: you miss the check-in, or your TA cannot meet your team that week. Record it on media.oregonstate.edu with captions on, share it unlisted, and give one timestamp per student so each segment can be found and scored on its own (a student who missed alone records only their own segment). Link it in the sprint note, or in a comment on your submission if the note is already in, within 48 hours of the scheduled check-in.
The all-hands demo days are a different thing from this cadence: the whole class in one room, and your team takes one of the five across the year.
What You Submit
Section titled “What You Submit”Sprint Notes N
Section titled “Sprint Notes N”The sprint note as one PDF, with the cover Submitting Your Work describes, and your demo as Demo Cadence describes.
Sprint Notes N: Individual Contribution
Section titled “Sprint Notes N: Individual Contribution”Nothing to hand in: your contribution line in the sprint note is the evidence.
Rubric
Section titled “Rubric”Sprint Notes N
Section titled “Sprint Notes N”Each note is checked pass/fail per item, 20 points each; the rubric conventions list it among the rubrics that use other bands.
| Criterion | Ratings |
|---|---|
| Working software evidence20 points | |
| What got done20 points | |
| Top risk and one decision needed20 points | |
| Contribution lines20 points | |
| Judgment layer20 points |
Sprint Notes N: Individual Contribution
Section titled “Sprint Notes N: Individual Contribution”| Criterion | Ratings |
|---|---|
| Individual contribution this sprintdefaults to Full; a lower rating needs a written evidence note the student can see and answer100 points |
Your individual half defaults to full credit. A student’s individual half is reduced when the sprint’s evidence (contribution lines, the record where the work lives, review activity) falls short of the contribution floor. Deductions are flagged by the team’s TA with an evidence note, then confirmed by an instructor; 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. Each sprint is scored on its own, from the first one: no contribution that sprint, or a contribution line the record contradicts, scores zero, and anything else short of the floor is partial credit at the grader’s discretion. Being blocked is not a reason to contribute nothing, since there is other work to pick up, unless the whole team is blocked.
Two other sources can raise a concern about your contribution: the Defense, which spot-checks ownership claims live, and your partner’s surveys, which can flag an individual concern and start an individual review of your partner evaluation score.
If you join your first team mid-term, the sprints before you joined score full credit on your individual contribution, and your defense and RFC draw on the work since you joined. If you switch teams, each sprint is scored on the team you were on that sprint.
Activities That Prepare This
Section titled “Activities That Prepare This”Sprint notes repeat twelve times a year, so these recommendations aren’t per note. Three activities are worth doing once, in fall: Kanban Board Setup, Definition of Done, and Regular Stand-Up Meetings.
Two are worth repeating: Prioritization for the top-risk-and-decision item, and Learning Journal for the judgment layer, which is the part the instruction team reads.
Browse Team and Workflow for anything touching the board or estimates, Requirements for prioritizing, and Planning and Risk for risk.