Capstone Rubric

Back to Capstone Overview

Team Planning & Work Processes

  • Exceeds Expectations: Team meets below expectations in addition to the following: Project board utilizes appropriate labels for better organization(feature, bug, chore, spike, sprint 1, etc), stories are divided into 2-3 day sprints, and cards are assigned owner(s) of stories. Team utilizes co-authored commits.
  • Meets Expectations: Team creates a project board and utilizes board for communication by keeping it up-to-date throughout project. Team plans for MVP using wireframes, schema designs, and JSON contracts. Team communication is clear using slack channel, daily standups and retros.
  • Approaching Expectations: Team uses project board, but it is not updated regularly. Team does not follow good communication practices: daily standups, retros, pull-request reviews etc.
  • Below Expectations: Team creates a project board, but does not utilize for communication. Team cannot show clear plan for MVP or provide planning documents.

Stretch Goals

  • Exceeds Expectations: Meets the below criteria and either FE or BE successfully complete a secondary stretch goal
  • Meets Expectations: Both FE and BE complete a stretch goal successfully
  • Approaching Expectations: Only FE or BE attempt a stretch goal
  • Below Expectations: FE and BE did not attempt a stretch goal :cry:

Git Workflow

  • Exceeds Expectations: Meets the below critera in addition to the following:All team members use git hooks to standardize commit messages and expectations (linter, tests).
  • Meets Expectations: Hold discussions in PRs and complete a code review with an instructor. Include multiple people on a PR where discussion takes place on at least one PR. Students do not merge their own PRs. Commit messages are clear, professional, atomic and follow a consistent convention.
  • Approaching Expectations: Use PR templates, but zero PRs include actionable code review. Commit messages are clear, professional, and usually atomic.
  • Below Expectations: No PR template was used. Commits have large unrelated pieces of code and/or have unprofessional messages.

CI & Deployment

  • Exceeds Expectations: App has CI and successfully builds by day 5 and is deployed successfully after every PR merges. Logs should show that failed builds are very quickly addressed.
  • Meets Expectations: App has CI and successfully builds halfway through the project, and on due day.
  • Approaching Expectations: App has CI and successfully builds on the due day.
  • Below Expectations: App does not have CI setup but does successfully deploy.


  • Exceeds Expectations: CI/Deployment badges on all repos OR swagger.ui or something similar for documenting for the endpoints is used. All team members are listed as contributors with links to their GitHub & LinkedIn profiles.
  • Meets Expectations: All repos have a README with a project description, wireframes (for FE), screenshots (for FE), endpoint documentation (for BE/Microservices), links to production sites, links to associated repos, instructions to setup, contributions to all team members. Clear and consistent markdown format is used.
  • Approaching Expectations: A README is present in all repos, but some relevant information is missing (too brief or uninformative) OR all information is present but formatted poorly and difficult to sift through.
  • Below Expectations: A README is present in all repos, but has minimal/no relevant information.


  • Exceeds Expectations: Developer satisfies all criteria below and the following: Test coverage includes both unit, integration, and end-to-end testing at 90% and above for the Frontend, Backend, and Microservices(if applicable). Coverage includes a majority of edge cases and approriate error handling.
  • Meets Expectations: Test coverage includes happy/sad paths. Frontend is expected to have at least 80% test coverage if using Cypress. If using a different testing framework, test coverage should be at least 25%. Similarly for backend, if you use Rails for your BE, then we expect at least 80% test coverage OR if you experiment with a new BE language/framework outside of Ruby and Rails, then BE test coverage is expected to be at least 25%
  • Approaching Expectations: Tests have been attempted but do not meet the required coverages. Missing sad path tests.
  • Below Expectations: Developers do not use test driven development for the project and no specs can be run at any time.

Lesson Search Results

Showing top 10 results