Capstone Expansion Rubric

Back to Capstone Expansion 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 app changes and additions using wireframes, schema designs, and JSON contracts where applicable. 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 the project or provide planning documents.

Stretch Goals

  • Exceeds Expectations: Team completes a stretch goal successfully and is able to speak to the approach they took to learning, resources used, and documentation related to the stretch goal
  • Meets Expectations: Team attempts a stretch goal and is able to speak to the approach they took to learning, resources used, and documentation related to the stretch goal
  • Approaching Expectations: A stretch goal is attempted but the team is unable to speak to their approach to implementation
  • Below Expectations: Team 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. Include multiple people on a PR where discussion takes place on at least one PR (even if you’re working solo). Students do not merge their own PRs unless on a solo team. 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.

Documentation

  • Exceeds Expectations: In addition to a thorough README documenting the entire project, team members draft a post for LinkedIn or a blog describing their personal contibutions to Iteration 2, including challenges, wins, and take-aways.
  • Meets Expectations: A README is present in all repos, and it covers all the requirement from the Capstone initial interation. Changes to the project from Iteration 2 are documented including any new wireframes, changes to schema, or links to information about 3rd party tools (if applicable).
  • Approaching Expectations: A README is present in all repos, and it covers all the requirement from the Capstone initial interation, but has not been updated to reflect the changes in the project from the second iteration.
  • Below Expectations: A README is present in all repos, but has minimal/no relevant information.

Testing

  • 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.

CI & Deployment

Because all projects were expected to be deployed and have CI implemented in part 1, this expectation remains. Now that you will be working in smaller teams on the same project, the expectation is that if your code breaks CI or the deployment, you are responsible for fixing it. You are welcome to pair and seek help from others on the team if needed, but leaving it broken for someone else to fix is not an acceptable response. If your work requires a new repository (ex: building a microservice), that repository is expected to have CI setup and deploy by the due day.

  • Exceeds Expectations: App has passing CI and is deployed successfully after every PR merges. Logs should show that failed builds are very quickly addressed.
  • Meets Expectations: App has passing CI and successfully deploys on due day.
  • Approaching Expectations: One of CI or the production deployment is not functioning as intended on the due day.
  • Below Expectations: Neither CI nor the production deployment is not functioning as intended on the due day.

Lesson Search Results

Showing top 10 results