Project Handoff

Team·Spring·4% of the spring grade

• Project HandoffSunday of week 8·Rubric

The last thing your team ships.

Up to 48 hours late loses one rubric band on each criterion. After that it scores zero, unless you contacted the instructors before the deadline with a documented reason.

Within a few weeks, your team stops existing and the project keeps going: with your partner, a maintainer community, next year’s capstone team, or you. The handoff is professional knowledge transfer, and the bar is concrete: someone with relevant technical background who didn’t build it can run and maintain the project using only this document and the repository. If your living docs stayed current all year, this assignment is mostly assembly.

If you are keeping the project

You hold the IP by default (IP, NDA, and Licensing has the details), so the successor can be your own team. Three things change: repository ownership stays with you instead of transferring, the archive declaration in section 6 still applies, and the conversation with your partner about what you’re taking forward happens before week 10, not after. One thing does not change: the spring rung is scored on what shipped by week 10. “We are going to keep working on it” is the same move as “the partner will deploy it after the project ends” (see Some Truths About Shipping) and it earns the same rung.

What You Produce

A partner-facing handoff document (2 to 4 pages, delivered where your partner keeps project documents: their issue tracker, wiki, or document system, or the repository’s issues if they have none) containing the sections below. Student-proposed projects use their mentor or instructor as the confirming partner. A non-responsive partner does not tank your grade: after two documented attempts, an instructor or mentor confirms instead and the criterion is scored on your documented attempts.

AI use: AI may draft and assemble from your repository; that is what the living docs were for. Do not let it invent steps, links, or artifact locations: every command and URL in this document must work, because the person who discovers otherwise cannot ask you anymore.

1. Overview and Current Status

What the project is and what problem it solves; the current deployment or delivery state (is it running, where, how stable); what is and is not included in this handoff, with reasons; and a contact for each team member for follow-up questions.

2. Setup Someone New Can Follow

From nothing to running: prerequisites with versions, copy-pasteable install and build commands, how to run the tests, how to run a local development environment, how to deploy (or a pointer to the runbook), and the pitfalls you know about with their fixes. This should largely already exist in README.md and CONTRIBUTING.md; the handoff points at it and fills gaps rather than duplicating it. Verify it: have the team member who least knows the setup path (or your partner) execute it clean and fix what breaks.

3. Known Issues, Limitations, and Future Work

A prioritized accounting: open bugs with severities (link the tracker), features that are partial or fragile, technical debt and whether it was intentional, a prioritized backlog of future work, and every credential, API key, or access permission that must be transferred, with its transfer status, or a line saying there is nothing to transfer.

4. The Living Docs

Links into the repository’s living documentation, each confirmed current as of handoff: docs/requirements.md, docs/design.md, and docs/risks.md, plus docs/rfcs/ or docs/adr/ for the decision record. The successor team’s first task is an audit of what you left behind (the inherited-codebase audit lists what it covers), so write the handoff to answer that audit. The Repo Checkpoints kept those three current, and the forward-looking section of your Project Retrospective tells the successor how to read them. See the Documentation guide, and Diataxis if you’re unsure whether a given page should be a tutorial, a how-to, a reference, or an explanation.

5. Handoff Checklist and Partner Confirmation

Complete this checklist in the document; unchecked items get a reason and a follow-up plan:

• Repository access transferred to the partner, kept by the team, or archived, per agreement
• Credentials and secrets transferred securely, none committed to the repo
• Deployment environment access transferred or documented
• Open issues triaged and documented
• README.md and the living docs current and accurate
• Partner has confirmed receipt in writing

The written confirmation (quoted email or signed note, included in the document) must say the partner can access the repository, can run the project, and understands what maintaining it will take.

6. Release Consent and Archive Declaration

The school may share project archives with future students and project partners as examples of student work; this is optional and separate from your partner’s rights to the software. Include a declaration listing every team member as Consenting or Not Consenting, note any NDA or partner restriction on sharing, and state where the project archive lives (the repository itself, or the agreed sanitized export if your project is under NDA). One dissent or restriction means the archive is not shared; the declaration is still required.

What You Submit

The handoff document as one PDF, with the cover Submitting Your Work describes and the written partner confirmation from section 5 inside it.

Rubric

Rubric: 100 points across 5 criteria

Criterion	Ratings
Overview and status15 pointsOutcomes: SO3	Exceeds Expectations (15)Within half a page, states what the system does, what state it is in, what is explicitly out of scope, and who to contact. No course jargon. Meets Expectations (12)States what the system does and what state it is in, but the exclusions name no specific feature or component, the contacts name no person or channel, the overview runs past half a page, or it uses course jargon. Does Not Meet Expectations (3)No overview, or a reader cannot tell what the system does or what state it is in.
Setup: complete, copy-pasteable, verified by a fresh runcomplete, copy-pasteable, and actually verified by a fresh run30 pointsOutcomes: SO2	Exceeds Expectations (30)Setup instructions are complete and copy-pasteable, and the team verified them from a clean environment. A grader following them cold reaches a running system. Meets Expectations (24)Setup is mostly right but has gaps: an undocumented prerequisite, a step that fails without a stated workaround, or no evidence of a fresh-run verification. Does Not Meet Expectations (6)Setup cannot be followed to a running system.
Known issues and future work20 pointsOutcomes: SO6	Exceeds Expectations (20)Open bugs carry severities and the tracker is linked; each piece of technical debt says whether it was intentional; future work is in priority order; and every credential, API key, or access permission is listed with its transfer status, or the section says there is nothing to transfer. Meets Expectations (16)A known-issues section exists, but bugs carry no severities, the tracker is not linked, technical debt does not say whether it was intentional, future work is unordered, or a credential or access permission has no transfer status. Does Not Meet Expectations (4)No known-issues section, or no credential and access list and no statement that there is nothing to transfer.
Living docs linked and currentrequirements, design, and risks linked and current, decision record reachable10 pointsOutcomes: SO1	Exceeds Expectations (10)The requirements, design, and risk documents are linked and current, and the decision record is reachable from the handoff. Meets Expectations (8)Docs are linked but one no longer describes the system that exists, or the decision record is not reachable from the handoff. Does Not Meet Expectations (2)Living docs are missing or unlinked, or two or more no longer describe the system that exists.
Checklist, partner confirmation, and release consentChecklist, written partner confirmation, and release-consent declaration all complete25 pointsOutcomes: SO4	Exceeds Expectations (25)Handoff checklist complete, written partner confirmation attached, and the release-consent declaration lists every team member, with any NDA or partner restriction noted. Meets Expectations (20)Checklist and confirmation present, but a checklist item is unchecked with no reason and follow-up plan, the confirmation leaves out repository access, running the project, or the cost of maintaining it, the consent declaration leaves a member unnamed, or an NDA or partner restriction goes unstated. Does Not Meet Expectations (5)No written partner confirmation, or no release-consent declaration.

Activities That Prepare This

Planning for Maintenance and Long-Term Support for known issues and future work, and Describe your API Reference for the living-docs criterion if other code or people build on your product.

Examples. A project may match several rows or none. If none fits, ask your partner or mentor which activities do.

If	Activities
some of your contributions to an open-source project are still unmerged	Software Release and Versioning: what you owe is the state of that unmerged work
the next owner has to get your results back	Make Your Artifact Reproducible. For a result, this is the handoff
the partner’s people will operate it after you leave	Planning for Maintenance and Long-Term Support. You graduate and the system stays, so for the partner the runbook largely is the product
people keep using it after you leave	User Manual

Browse Testing, Release, and Handoff and Research Methods when these run out.