Project Partner Evaluation
Your project partner scores 25% of your grade every term, in two surveys:
- The Midterm Pulse (5% of the term grade): three statements about how the team works with them, answered in two minutes.
- The Final Evaluation (20% of the term grade): the six facets below, each scored 100, 90, 80, 70, or 50; spring Verification and Validation adds a 60 rung.
Fall and winter are progress-focused; spring scores outcomes. The facet weights move with the year:
| Facet | CS 461 | CS 462 | CS 463 |
|---|---|---|---|
| Reflection | 15% | 15% | 15% |
| Requirements and Specifications | 40% | 15% | 5% |
| Design, Implementation, and Deployment | 15% | 40% | 20% |
| Verification and Validation | 5% | 10% | 40% |
| Teamwork | 15% | 10% | 10% |
| Communication | 10% | 10% | 10% |
Fall is won on requirements, winter on building, spring on the shipped outcome. If a team changes projects mid-year the weights do not change.
How the scoring works
Section titled “How the scoring works”Every facet has three written anchors, at 100, 80, and 50. A partner scores 90 or 70 when the team sits between two anchors. The spring Verification and Validation ladder has six rungs of its own.
Under each facet is a short list headed What it looks like. It is the same list for both readers: for the student, it is what to do every week; for the partner, it is what to look for before choosing an anchor. In the lists and the anchors, “you” is the partner. Nothing on the lists needs a rubric to be understood, and nothing on them is optional in a professional engagement. Discuss the lists with your partner in the first meeting of every term.
The survey also asks the partner to flag any specific student who did not contribute; that flag starts the corroboration review at the bottom of this page.
Midterm Pulse (5%)
Section titled “Midterm Pulse (5%)”Three statements, each answered from Strongly disagree to Strongly agree. Each is one behavior from the facet lists below, so the way to score well in week 6 is the way to score well in week 10.
| Item | Statement your partner rates | Drawn from |
|---|---|---|
| Responsiveness | The team answers my messages within one working day, with an answer or a date. | Communication |
| Professionalism | The team arrives at our meetings with a written agenda or status, and every student speaks. | Communication |
| Delivery quality | What the team has shown me so far matches what we agreed and works as demonstrated. | Requirements and Specifications; Design, Implementation, and Deployment |
Reflection
Section titled “Reflection”Whether the team learns from each sprint and shows it.
What it looks like
- The team can say, without being asked, what the last sprint taught them and what they changed because of it.
- Feedback you gave appears in the next iteration, or the team tells you why not.
- Retrospective outcomes reach you as changed behavior (a new meeting rhythm, a different demo format).
- The team states the project’s impact and its intellectual-property terms in their own words.
| Points | Anchor |
|---|---|
| 100 | Every sprint the team names one thing it learned and one process change it made because of it; your feedback shows up in the next sprint’s work, or you are told why not. |
| 80 | The team reflects when asked and has acted on some of your feedback; some sprints show a change, most do not. |
| 50 | No reflection you can point to; the same feedback is given twice with no visible effect. |
| Points | Anchor |
|---|---|
| 100 | The team explains, with named examples, what worked, what did not, and what it would do differently, and the handoff reflects it. |
| 80 | General lessons with few specifics; the handoff does not show them. |
| 50 | No lessons the team can articulate. |
Requirements and Specifications
Section titled “Requirements and Specifications”Whether the team knows what it is building, in terms you agreed to.
What it looks like
- Goals are written down, stated so they can be measured, and you have agreed to them.
- The team asks before assuming; an unclear item comes back as a question within the week, not as a surprise in a demo.
- Priorities are explicit: the team can tell you what is in, what is out, and what is next, and you have seen the list.
- The written requirements change as understanding changes, and you can see what changed.
| Points | Anchor |
|---|---|
| 100 | Written, measurable goals you agreed to; a prioritized list you have seen; questions arrive before the work starts. |
| 80 | Goals are written but some cannot be measured as written or carry no priority; you sometimes learn of an assumption after the fact. |
| 50 | No written goals you have seen; the team builds on assumptions you never confirmed. |
| Points | Anchor |
|---|---|
| 100 | Requirements are complete, prioritized, and current; what shipped matches them, or the difference was negotiated with you. |
| 80 | Requirements are mostly documented; there is drift between the document and what shipped. |
| 50 | Requirements are missing or stale; the delivered work does not map to them. |
Goals that are not stated and measurable cannot be evaluated; that is the first conversation of fall.
Design, Implementation, and Deployment
Section titled “Design, Implementation, and Deployment”Whether working software exists, advances, and can be run by someone other than the team. Fall carries little weight here; the goal is to have the implementation and a deployment path under way so winter starts at speed.
What it looks like
- You can open the current version at any time (a link, a build, or a branch you can run), not only at demos.
- Milestones you were told about are met, or renegotiated before they slip.
- Design decisions that affect you (data, integrations, hosting, cost) are explained before they are made.
- Documentation exists for whoever runs this after the team is gone.
| Points | Anchor |
|---|---|
| 100 | Working software you can access every sprint; milestones met or renegotiated ahead of time; decisions that affect you explained first. |
| 80 | Progress is visible most sprints; some milestones slip without warning. |
| 50 | Nothing runnable to show; progress is described, not demonstrated. |
| Points | Anchor |
|---|---|
| 100 | Deployed where it needs to run, documented for its successor, used by you or your users, and no gap you raised remains open. |
| 80 | Deployed and functional, with gaps the team has named and not yet closed. |
| 50 | Not deployed, or deployed but unusable without the team present. |
“Deployment” is read loosely: for a research project it means the code and artifacts are documented and reproducible; for a FOSS project it means the patches include every necessary change, documentation included, and work in the existing codebase without regression.
Verification and Validation
Section titled “Verification and Validation”The outcome of the project, not only the output.
What it looks like
- Tests exist, and the team can show you the latest run.
- Feedback from you or from users is collected every sprint, and you can see where it went.
- The team states, in writing, what “verified” means for this project and against which expectations of yours.
- In spring, the team can name the rung of the ladder it is on and the evidence for it.
Fall & Winter Terms
Section titled “Fall & Winter Terms”| Points | Anchor |
|---|---|
| 100 | A written test and validation approach you have seen; tests run on every change; feedback from you or from users is collected every sprint and visibly acted on. |
| 80 | Tests cover some parts and run when someone remembers; feedback is collected some sprints. |
| 50 | No tests you know of; no feedback collected. |
Spring
Section titled “Spring”In spring the scale is one ladder for every project: who ran the software. Read it literally. Every rung above 50 describes someone outside the team running your work, and the top rung describes people who depend on it. Code that works but that nobody ever ran is not a high rung. Getting to a real user, a real deployment, or a real merge is the part that takes a year of lead time, and it is what the Shipping guide maps out for each outcome type. The outcome type is guidance and a playbook; it does not change the scale.
| Points | What is true about who ran the software |
|---|---|
| 100 | People outside the team depend on it. Consultancy: the partner runs it in operations. FOSS: patches shipped in an upstream release. Research: a stranger reproduced the result from the published artifact. New Product or Game: sustained use by strangers (tens of heavy or hundreds of light users). |
| 90 | Someone outside the team runs it in their own environment. Consultancy: the partner is integrating it into production. FOSS: patches merged. Research: a person outside the team reran the pipeline on real data and got the numbers. New Product or Game: two dozen strangers used it. |
| 80 | An outsider ran it and the team acted on what they found. Consultancy: your feedback on a prototype addressed in a newer version. FOSS: a pull request reviewed and revised. Research: your group ran it on real data and the issues were fixed. New Product or Game: a dozen strangers, or a completed user study. |
| 70 | An outsider ran it once. Consultancy: you tried a prototype. FOSS: a pull request submitted. Research: a real-data run shown to you. New Product or Game: friends tried a deployed build. |
| 60 | You watched it run on your real inputs (a live demo or a recording) but nobody outside the team has operated it. |
| 50 | Nobody outside the team has run it. |
Your Definition of Shipped does not replace the ladder. It makes your rung concrete. The rungs are written generally because they have to cover every project in the class. Your Definition of Shipped says what your target rung means for your project: which environment, which users, which upstream, measured how. That is what your partner scores against in spring, and it is why you write it in winter, while there is still time to act on it.
Custom scoring is for genuine deviation, not for restating the ladder. If your partner’s expectations differ from the ladder in kind rather than in detail, they can score on a custom scale of [50,100]. The standing example is a project whose right outcome is zero users yet, such as a tool that must not reach patients or operators before a certification the course cannot wait for; it is scored on the user activities it did run, such as supervised trials and reproduced results. Agree that in the Definition of Shipped in winter, not in spring week 10.
Teamwork
Section titled “Teamwork”Whether the team works as one unit in front of you.
What it looks like
- The same people show up; an absence is announced to you in advance.
- Any team member can answer for the project, not only the one who did the work.
- Disagreements reach you as decisions the team made together, with the options it weighed.
- Work is visibly shared: over a term, the demos and the questions come from different people.
| Points | Anchor |
|---|---|
| 100 | Whole team present and prepared; anyone can speak to the project; disagreements are resolved and reported to you; work is visibly spread across members. |
| 80 | Mostly present; one or two members carry the meetings; disagreements show in a meeting and are settled by the next one. |
| 50 | Members missing without notice; one person does the talking and the work; conflict visible and unmanaged. |
Students also evaluate each other directly every term, and the end-of-spring survey adds the CATME instrument. See Peer Evaluations.
Communication
Section titled “Communication”Whether you always know where the project stands without asking.
What it looks like
- Every student speaks at every meeting.
- The team arrives with a written agenda or status, and sends notes with decisions and next steps within a day.
- Demos show working software, not slides about it.
- A question gets an answer or an “I will find out by X”, and X holds.
- Written updates arrive on the cadence you agreed, without being chased, and a message gets an answer within one working day.
- Documents you receive are short, current, and answer the question they were sent for.
| Points | Anchor |
|---|---|
| 100 | All of the above, every time: agenda before, every voice during, notes after, working demos, updates on cadence. |
| 80 | Meetings are prepared and followed up most of the time; one or two students rarely speak; you occasionally have to chase an update. |
| 50 | Meetings without an agenda or notes; the same one or two people speak; you chase for updates; demos are slides. |
Activities That Prepare This
Section titled “Activities That Prepare This”- Regular Stand-Up Meetings: the Teamwork and Communication lists; the habit of every voice, every time.
- User Story Mapping: the Requirements list; written, prioritized goals your partner has seen.
- External Feedback Session: the Reflection and Verification lists; feedback collected and visibly acted on.
Browse teamwork and communication when these run out.
Individual Accountability
Section titled “Individual Accountability”Project partner evaluations are primarily team-level assessments. However, if a project partner explicitly flags that a specific student did not contribute meaningfully to the project, the instructor may apply individual grade adjustments to that student’s project partner score.
Corroboration Review
Section titled “Corroboration Review”When a project partner flags an individual student, the instructor will cross-reference that signal against the following:
| Source | What it shows |
|---|---|
| Peer evaluation scores and comments | Teammates’ direct assessment of contribution, work quality, and attitude |
| Contribution lines in sprint notes | The reviewed PR(s) each student owned, sprint by sprint |
| Repository activity | Commits, pull requests, code reviews, and issue ownership (NDA teams: verified live at the walkthrough or defense) |
| Individual assignments | The student’s RFCs, defense performance, and career retrospective |
A flag that is corroborated by two or more of these sources is treated as strong evidence of non-contribution. A flag that is not corroborated may still result in a minor adjustment but will be given more benefit of the doubt, since project partners do not always have visibility into all aspects of individual work.
How Adjustments Are Applied
Section titled “How Adjustments Are Applied”Adjustments are applied at the facet level, based on what the corroborated evidence shows about the student’s individual contribution to each area. Facet adjustments are reserved for partner-originated flags; routine non-contribution already handled by the sprint-note individual modifier is not penalized a second time here. All six facets are susceptible to individual downgrading; none is protected by default.
For each facet, the instructor asks: does the evidence show that this student meaningfully contributed to this area? If the answer is no, the facet is graded at a level that reflects the student’s actual contribution rather than the team’s. A student with no traceable contribution across all areas may receive 50% on every facet. A student who communicated but did not produce output may receive a lower score on Teamwork and Design/Implementation while retaining the team’s score on Communication. The adjustment is always proportionate to what the evidence shows, facet by facet.
How Students Can Protect Themselves
Section titled “How Students Can Protect Themselves”The best protection is visible, traceable contribution throughout the term:
- A student should commit code to their own branches and open or close their own issues; work should not be committed by a teammate on their behalf.
- Each student should author their own contribution lines in sprint notes and their own individual assignments; having a teammate write their contributions for them undermines the traceability that protects them.
- All contributions should be measurable and attributable to the student. If a student is doing work that is not easily traceable (e.g., design discussions, testing, documentation), they should make sure to document it in a way that can be corroborated (e.g., meeting notes, issue comments, pull request reviews).
- If a student is blocked, they should communicate early with their team and their project partner. A student who raises a blocker and adapts is treated very differently from one who goes quiet.
- Peer evaluations reflect teammates’ real-time view of a student’s work. A student who is having a difficult term should address it in their individual retrospective section and discuss it with the instructor proactively; waiting until grades are posted is too late.