Final Project Grading

Grading

For most of the submission components below there are two "baseline" rubrics: one for a submission that is satisfactory (full marks), and one that would be meeting our minimum expectations (a pass). In practice, when grading projects we will usually assign numeric grades and provide partial credit, using these rubrics as guidelines for those two extremes. A rubric for the remaining components will be provided by individual instructors.

Adjustments in project scope

We are hopeful that all teams will deliver all essential AND desired features proposed in their revised project plans. However, it is possible that there might be some minor deviations from the original plan - in the four-week implementation period, there are sure to be some teams that encounter unexpected technical hurdles. As described in greater detail in the rubrics below, teams that have regular communication with their TA regarding their project status may have the opportunity to request variances to their project scope.

Individual Contributions to the project

In cases where team members do not equally contribute to the project, we may assign different grades to different individuals, up to an extreme of deducting 50% of the marks from a student. In the event that a group member does not contribute at all to the project, student might receive 0. We will evaluate each individual's contribution on the basis of a variety of factors, including progress reports at weekly meetings, through inspecting version control history, through each team's (or student's) peer evaluations during and/or at the end of the project, and through each student's self-reflection. We will make regular efforts to collect and distribute this feedback throughout the project. Our ultimate goal is for all students to participate and receive full marks.

Summary of grading

From Project Overview:

  • Planning (15%)
    • This includes the Preliminary Project Plan and the Revised Project Plan.
  • Warm-up (15%)
    • The evaluation of the warm-up can be found in Project 3.
  • Process (15%)
    • This includes: use of a structured development process, including regular git commits, pull requests, code reviews, timely completion of progress reports and individual/team surveys, and weekly meetings.
    • This also includes appropriate division of labor within the project (i.e., roughly equal). For full credit, each member of the team must have at least 2 commits during the each sprint (i.e., sprints 1,2 & 3) even when using pair programming.
  • Product (40%)
    • 20% Successful delivery of your Minimum Viable Product as defined in your project plan
    • 10% Desirable delivered features
    • 10% Test suite of your features.
  • Reports (15%)
    • 10% Final Report
    • 10% Poster and Demo
  • Individual Reflection (required to receive an ‘A')

This adds up to 100%; this sum is worth 40% of the course grade.

Detailed Rubrics

Here are the detailed rubrics for the final deliverables:

Product (40%)

Product > Minimum Viable Product (20%)

Product > Additional Desirable Features (10%)

We will grade each of these using the following rubric:

  • Satisfactory:
    • Implemented features satisfy the conditions of satisfaction as proposed by the team and as agreed to by the instructor. If technical difficulties resulted in features being dropped, the project may still earn full marks on "delivered features," but these difficulties must have been documented and communicated to me as you encountered them during development.
    • Implemented features are deployed to a publicly-accessible URL, using Render and/or Heroku for hosting (or as per deployment instructions provided).
    • Implemented features contain no ESLint warnings or errors; do not include any eslint-disable or ts-ignore flags
  • Meets minimum requirements:
    • Implemented features largely satisfy acceptance criteria as proposed to me, but perhaps implemented features not in agreement to my interpretation of those criteria.
    • Implemented features are deployed to a publicly-accessible URL, using Render.com and/or Heroku for hosting (or as per deployment instructions provided).
    • The implementation may have some obvious flaws, but largely works without crashing.
    • Implemented features do not include any eslint-disable or ts-ignore flag

Product > Testing (10%)

The project must include evidence of testing (both for front-end and back-end). Ideally, all new features will be accompanied by fully automated tests, but in some circumstances, this may not be feasible. If automated tests are not possible, include a discussion of your manual testing strategy. The evidence of testing can be submitted as part of your report. Teams are welcome to make use of any testing technology (e.g. mocks, spies, etc.) or library (e.g., cypress) – there is no requirement to use any specific library.

  • Satisfactory:
    • Any new or modified backend features include tests that validate that the feature works as intended. These tests cover the changed code, and also contain well-written assertions that thoroughly check the expected behaviors.
    • Any new or modified frontend features should be thoroughly tested to validate that the feature works as intended. Evidence of your testing is provided. These tests may be manual if automated tests are not possible.
    • Tests contains no ESLint warnings or errors; do not include any eslint-disable or ts-ignore flags
  • Meets minimum requirements:
    • Any new or modified backend features include at least one test, which may or may not be an effective test.
    • Any new or modified frontend features should be minimally tested. Limited or no evidence of testing is provided
    • Tests may contain ESlint warnings (but no errors); does not include any eslint-disable or ts-ignore flags

Process (20%)

The Process grade includes: use of a structured development process, including pull requests, code reviews, timely completion of sprint progress reports/retrospectives, individual/team surveys, peer evaluations and weekly meetings with TA Mentor (for Week 6, 8-13). It also includes appropriate division of labor within the project.

  • For full credit, each member of the team must have at least 2 commits during each sprint in the final delivered code.
  • 10% of grade: Ongoing development progress including pull requests, code reviews, github commits, issue tracker activity, etc.
  • 10% of grade: Peer evaluations, instructor meetings, submission of surveys/reports. These items will be evaluated using the rubrics below.
  • Satisfactory:
    • There is a clear development history visible from the git repository: features were delivered incrementally, and not in a single (or several) commits at the end of the project
    • There is evidence of code review - for example, pull requests that have comments on them. Teams are expected to merge their development branches to main only after code review.
    • There is a correspondence between commit messages and the technical tasks that they are associated with; there are few (if any) commits with meaningless commits messages like . or Add files via upload.
    • Each team member has made at least 2 commits per sprint over the lifespan of the project
    • The team meets regularly with me and communicates progress. All or most members attend all meetings. Members who are absent from meetings send an excuse in advance.
    • Progress reports and other weekly reports and surveys are submitted in a timely fashion, not filled in later.
    • Meetings with me include demos or other evidence of progress.
  • Meets minimum requirements:
    • There is a clear development history visible from the git repository: features were delivered incrementally, and not in a single (or several) commits at the end of the project
    • Each team member has made at least 4 commits over the lifespan of the project
    • Attendance at an instructor meetings may be irregular, but enough to give me a sense of the the team's progress.
  • Individual grading for Process component

    Team members with unexcused absences from class, or with fewer than 2 commits per sprint during the lifespan of the project, may receive a lowered grade for the Process component.

Final Report (10%)

The final report should consist of three sections:

  • Feature Overview and User Manual
  • Technical Overview
  • Process Overview

The allocation of the 10% credit will be as follows: Overview and manual will be worth 3%, technical and process overviews will be worth 4% and 3% respectively.

Feature Overview and User Manual

  • Satisfactory:
    • The Feature section contains sufficient documentation for a user to build and interact with your updated version of GameNite.
      • The documentation covers all the steps that a user would need to build a working version of your project.
      • The documentation includes a link to the deployed version of your project
    • The documentation covers all steps that the user would need to take to exercise all of your user stories.
    • Screenshots are included that capture the key interactions between a user and your new feature.
    • Course staff were able to follow these instructions to successfully interact with your project implementation.
    • URL of the deployed app.
    • The section is at most 4 pages (roughly 2,000 words maximum), NOT including figures. Fewer pages are absolutely acceptable; consider this a rough limit
  • Meets minimum requirements:
    • The Feature contains documentation for a user to interact with your updated version of GameNite, but perhaps does not fully describe how.
    • The documentation includes at least one or two screenshots, but screenshots do not capture interactions with all of the user stories.
    • The course staff were able to figure out how to use it through trial and error.
    • URL of the deployed app.
    • The section is at most 4 pages, NOT including figures. Fewer pages are absolutely acceptable; consider this a rough limit

Technical Overview

  • Satisfactory:
    • Technical Overview contains a description of any substantive changes to the existing GameNite codebase, and of the architecture of your new code.
    • When appropriate, it uses diagrams and/or figures to illustrate a design (there is no requirement to use a specific tool or format for this – lucidchart, draw.io, d2 diagrams, mermaid or even hand-drawn diagrams are all acceptable).
    • It provides a well-reasoned rationale for why this is the "right" design.
    • It provides a table showing the status of all proposed user stories and conditions of satisfaction (proposed vs completed). The status could be fully implemented, partially implementted (feel free to add percentages), not completed.
    • It provides evidence of front end testing.
    • The document is at most 2 pages (fewer pages are absolutely acceptable, consider this a rough limit) excluding the table.
  • Meets minimum requirements:
    • Technical Overview includes a description of all major changes to the code compared to our existing GameNite codebase.
    • It provides a table showing the status of all proposed user stories and conditions of satisfaction (proposed vs completed). The status could be fully implemented, partially implementted (feel free to add percentages), not completed.
    • It provides limited or no evidence of front end testing.
    • The document is at most 2 pages (fewer pages are absolutely acceptable, consider this a rough limit) excluding the table.

Process Overview

  • Satisfactory:
    • Process overview contains a detailed description of the manner in which agile project management processes were used during the project (i.e., sprints, sprint reviews, retrospectives and blameless reviews).
    • It provides a summary of what was planned to happen in each sprint vs what actually happened, with a discussion of what was revised as a result.
    • It provides a short list of best practices for the project that you would suggest to future teams.
    • The document is at most 2 pages (fewer pages are absolutely acceptable, consider this a rough limit)
  • Meets minimum requirements:
    • It provides a summary of what was planned to happen in each sprint vs what actually happened, with a discussion of what was revised as a result.
    • The document is at most 2 pages (fewer pages are absolutely acceptable, consider this a rough limit)

Posters/Fliers and Demo/Presentation (10%)

Each team is required to submit a poster or Flier. Details can be found on Project Deliverables page.

Each group will present a live demo to show the feature that they have added for the final project. You will have 15 minutes maximum (14 minutes to setup and present + 1 minute for questions and everything else). You will lose points if your demo goes over 15 minutes. Please rehearse it and time yourself (best to keep it to 13 minutes or less).

Please note:

  • The live demo must be from the deployed site, not from localhost.
  • Attendance is REQUIRED for these demos. Please email the instructor if you have extenuating circumstances.
  • Each group will also be required to submit an evaluation of demos from other groups and provide these to the instructor.

Your presentation should include the following:

  • {Required} A title slide with your group and the names of your group members
  • {Required} 1 slide with the overall theme of your project and describing all user stories [no more than 1 slide]
  • {Required} 1-2 slide for each user story listing the conditions of satisfaction, numbered in the way they were numbered in your proposal (i.e. 3.2), and their priority. Indicate whether the conditions of satisfaction were met. Feel free to use percentages. This can be based on the table from your project plan
  • {Required} Discuss any deviations from the proposed plan [1-2 slides]
  • {Optional} Discuss any challenges you faced and how did you resolve them [1-2 slides]
  • {Required} 1 slide summarizing overall contributions made by each group member [no more than 1 slide with 1-2 sentences per member]

You might want to include your email address and other related info (i.e., github repo link, pictures, hosted site link, etc). You will also submit a copy of your presentation slides (pptx/pdf file, not link) on Blackboard under "Project: Poster + Presentation Slidedeck" assignment.

  • Grading Rubric

    Your final Poster/Flier and Presentation are worth 4% of the overall course grade.

    Poster/flier will be worth 1% and will be graded based on whether you submitted it on time or not.

    Presentation (which includes demo) will be worth 3%. This will be based on:

    • The presentation includes all the required aspects
    • All team members contributing to presentation
    • Quality of overall demo
    • Satisfactory responses to the Q&A
    • Peer feedback from groups

    You will NOT receive points for the demo if your group fails to submit copy of the presentation on Blackboard, if you do not submit peer feedback from other groups to your instructor, or if you are not present for all presentations/demos during class.

Individual Reflection

Accompanying the final team deliverable will be an individual reflection, which every student must submit on their own. Satisfactory completion of all parts of this reflection is required to receive an "A" grade in the course, and may be used to calibrate project scores across multiple team members. The individual reflection also provides an opportunity for students to provide confidential feedback on the performance of their teammates.

Project Concept

Reflect on the evolution of your project concept: How does the project that you delivered compare to what you originally planned to deliver? What caused these deviations?

  • Satisfactory:
    • Is at least 2 paragraphs long;
    • Includes at least 1 paragraph describing all variances from original project concept;
    • Includes at least 1 paragraph of personal reflection on the cause of any variances from the project concept.

Project Process

Reflect on the evolution of your development process: How did the process by which you designed and implemented evolve from your original project plan? Were there any processes that in hindsight, you wish that you followed, or wish that you followed better?

  • Satisfactory:
    • Is at least 2 paragraphs long;
    • Includes at least 1 paragraph describing all variances from the software development processes envisioned in your original project plan;
    • Includes at least 1 paragraph describing software processes (described in class or not) that you wish you had followed, or wish you had followed better, supported by evidence from your personal experience working on the project.

Project Team

Reflect on your team dynamic: Provide a frank (and ideally, blameless) postmortem of your and your teammates collaborative performance and participation. If you had to do this same project over with the same teammates, what would you have done differently (or not) to improve your team's overall performance? Do you think that each of your teammates are deserving of the same grade as you?

  • Satisfactory:
    • Is at least 2 paragraphs long;
    • Includes at least 1 paragraph reflecting on your own performance as a team member on this project, including what you would have done differently, given what you know now;
    • Includes at least 1 paragraph reflecting on your overall team dynamic, including strengths and weaknesses. Reflect on how you might have organized your team differently given what you know now.