Assignments
The Capstone Series assessment focuses on evaluating the six facets that, in our opinion, define a software engineer. For better or worse, we’re also bound by the ABET (Accreditation Board for Engineering and Technology), WIC (Writing Intensive Curriculum), and Beyond OSU (program-level) learning outcomes.
In professional life, writing will help students become better engineers. It is hard for us to assess individual contributions to written documentation, so we had to shape a few individual writing assignments and team assignment with individual contributions.
Here are all the assignments we believe are relevant for the team to successfully complete the project. The handbook contains many activities that can help determine the contents of these assignments. If the team is unsure where to begin, browse activities.
Most assignments apply to every term. Assignments marked Spring only are due at the end of the academic year.
Team Setup
Section titled “Team Setup”Stand up the minimum rails so the team can collaborate: version control, CI, communication channels, task tracking, and a shared Definition of Done. Teams inheriting a legacy codebase also capture a current-state summary and verify they can run it.
Sprint Progress Reports
Section titled “Sprint Progress Reports”An evidence-based update submitted at the end of each two-week sprint: planned vs. done, working software proof (URL, commit, CI), top risks and quality signals, next goals, a brief team reflection, and linked individual contributions. Fourteen reports over the academic year.
Team Charter
Section titled “Team Charter”Define how the team will work together: roles, decision process, cadence and tools, a restorative conflict path, Definition of Done (tests, reviews, static checks, docs, CI), and inclusion norms. Publish a CONTRIBUTING.md and show evidence of individual contributions. Updated at the start of each term.
Stakeholder Memo
Section titled “Stakeholder Memo”Interview the project stakeholder(s) and turn the conversation into a one-page internal memo: problem statement, initial constraints and acceptance criteria, IP, licensing, and data-use notes, and expectations. Written in fall term.
Requirements
Section titled “Requirements”Align on scope and “what good looks like.” Produce an ID’d, atomic, testable requirement set with non-functional requirements, acceptance criteria for priorities, an explicit prioritization method, and traceability to risks and constraints. Revisited and updated each term.
Background Research Brief
Section titled “Background Research Brief”Learn a narrow, high-leverage slice (technology, standard, user research, or competitive landscape) and synthesize credible sources into key findings and actionable implications for the team.
ADRs and Code Review Packs
Section titled “ADRs and Code Review Packs”Write an Architecture Decision Record (ADR) documenting a real design decision (context, options including “do nothing,” decision, consequences) with embedded evidence. Pair it with a substantive code review covering correctness, design, tests, and security, with proof of follow-through.
Technical Design
Section titled “Technical Design”Share a coherent system view (context and diagrams), concrete interfaces and contracts (examples, errors, auth, versioning), and a ranked risk register. Link to evidence artifacts and ADRs. Revisited and updated each term.
Retrospectives
Section titled “Retrospectives”Tell the story of the term via two to three themes covering top successes and pain points. Support with one to three crisp artifacts and commit to three team actions with owners, timeframes, and recognition cues. Each student contributes an individual page: wins, gaps, commitments, and one risk with a mitigation plan.
Project Partner Evaluations
Section titled “Project Partner Evaluations”At the mid or end of every term, the project partner or mentor receives a survey asking them to grade the team. See the details and criteria here.
Project partner evaluations account for 25% of each student’s total grade each term. The evaluation approach varies by term:
- Fall and Winter Terms: Progress-focused assessment using adapted rubrics that evaluate development milestones, learning growth, and team collaboration.
- Spring Term: Final outcome-focused assessment using complete rubrics that evaluate project deliverables and final results.
The midterm survey (when there is one) is a lightweight “pulse” check to ensure the team is on track. The end-of-term survey is more comprehensive and will significantly impact each student’s grade.
They will grade the team as a whole, but they will have the option to add notes as needed. The team must ensure the project partner is up to date on progress and aligned on expectations. Review all artifacts for the term (including the demo) with them.
The facet distribution for project partner evaluations can be found on the grade distribution page.
Peer Evaluations
Section titled “Peer Evaluations”At the mid and end of each term, students evaluate their teammates on contributions to the team’s success. Peer evaluations account for 25% of each student’s total grade each term. The midterm survey is lighter and provides an opportunity to adjust; the end-of-term survey is more comprehensive.
Spring Release
Section titled “Spring Release”A recorded 8-12 minute video that presents the project to a general audience. Covers the problem statement, a live or narrated end-to-end walkthrough of the project, and an honest outcomes segment with concrete numbers or verifiable status. Submitted with a one-page release notes PDF that includes a link to the video, segment timestamps, and a repository or archive link.
Project Retrospective
Section titled “Project Retrospective”A team document that looks back across all three terms. Covers the project arc (key pivots and why), what was delivered versus the original goals and agreed-upon outcomes, three to five engineering decisions with honest consequences, team dynamics and conflict, process changes that helped, and a forward-looking section for whoever continues the work.
Project Handoff
Section titled “Project Handoff”A partner-facing PDF that gives the project partner everything needed to continue, maintain, or extend the project: project overview and current status, step-by-step setup instructions, known issues and future work, reference links to the final requirements and technical design documents, and a completed handoff checklist with written partner confirmation.