Rubric

Rubric

You will be graded by your instructors on the criteria below. This rubric outlines the key areas in which you will be graded. Please note that all areas will be graded with equal importance. If you have any specific questions in regards to any of these key areas, please let us know at any time.

Project Management/Agile Practices

  • 4: Developer follows all requirements in the below section. Developer creates a backlog of new issues, bugs, refactors, and chores that could be worked on for the duration of the project. The developer utilizes labels to distinguish the difference in various story types.

  • 3: Developer regularly uses Github Projects as their primary agile board. Before starting to code, they write user stories that focus on each individual feature that will be created in the application. Each user story will contain a descriptive and consistently formatted title in relation to the feature being built. Each user story will also contain information pertaining to the feature being built within the description of the card. For example, this includes steps that a user may need to do in order to achieve their goal, or expected request/response data that may be seen during the use of an API. Developer is able to articulate the agile process during the project evaluation.

  • 2: Developer creates an agile board but uses it sparingly after the initial start date of the project. Developer creates a few stories but never pulls them into their respective columns at the appropriate time. Most stories do not have written descriptions.

  • 1: Developer creates an agile board but doesn’t utilize it for the duration of the project.

Git Workflow

  • 4: Developer satisfies all criteria below in section three. Developer demonstrates their git workflow as being 100% consistent in regards to the creation of branches, issuing pull requests, using PR templates, asking for feedback, and writing clear and concise commit messages.

  • 3: For each feature listed on their agile board, the developer has created a branch on git. Developer pushes their changes to their respective branches found on Github. Developer opens pull requests for every branch they create. All commit messages will be in imperative tense, start with a capital letter, and be consistent for the duration of the project. The name of pull requests are clear and concise of what work was completed. The title of the PR is not same name as the branch name.

  • 2: Developer creates pull requests on separate branches but often pushes directly to master. Developer is inconsistent in how they write commit messages. Some commit messages lack clarity and purpose for the code submitted. Developer may tag collaborators at times.

  • 1: Developer only pushes to master, never creates branches for their features work, and has very few commit messages at the end of the project. Commit messages are not informative and lack clarity as to what each piece of code is focused on. Commit messages are not consistent and lack proper structure across the project history.

Documentation

  • 4: Developer satisfies all criteria below in section three. Developer contributes additional information. This includes links to their agile board and any available production links.

  • 3: A thorough README is found in all related repositories. A README contains sections such as Introduction, Initial Setup, How to Run Tests, How to Use, Schema Design, Tech Stack List, and Core Contributors. Each section is thoroughly filled in with important information for visitors of your application’s repo.

  • 2: A thorough README is found in all related repositories. A README contains sections such as Introduction, Initial Setup, How to Run Tests, How to Use, Schema Design, Tech Stack List, and Core Contributors. Each section is not filled out thoroughly, or some are missing.

  • 1: A default README is found in all related repositories. No additional sections have been added. Developer has not added any related information to the project.

Testing

  • 4: Developer satisfies all criteria below in section three. Test coverage is at 90% and above. This coverage includes happy/sad path and a majority of edge cases. Developer will run the test suite during evaluation to show their final coverage.

  • 3: Developer codes and uses test driven development during all iterations. Test coverage must be at 75% and include happy/sad paths. Developer will run the test suite during evaluation to show their final coverage.

  • 2: Developer codes and uses test driven development during some iterations. Test coverage must be at 25% and include happy paths. Developer will run the test suite during evaluation to show their final coverage.

  • 1: Developer codes and does not use test driven development for the duration of the project. No specs can be run at any time.

Software functionality

  • 4: Requirements listed below are complete and student has additional endpoints completed for project. Endpoints include happy path testing.

  • 3: All endpoints within the project spec are working and complete. This also includes that endpoints are formatted correctly and deployed to production on Heroku.

  • 2: At least 75% of endpoints are partially working and complete within the project spec. Project is deployed to production on Heroku.

  • 1: Fewer than 50% of endpoints within the project spec are working and completed. Project not be deployed to production on Heroku.

Presentation and Defense

  • 4: Developer satisfies all criteria below in section three. Presentation is in line with one that would be presented during a demo competition. This includes slides that focus on their story, passion, and clarity in decision making.

  • 3: Developer clearly presents their team’s process and approach to how they completed the project during evaluations. Developer comes to evaluation with a prepared presentation with slides that lasts at least 10 minutes long and covers all primary areas within this rubric. The developer will demonstrate their articulation around how they built the project, what problems came up, and how their overall process allowed them to succeed.

  • 2: Developer arrives without a presentation and are prompted to answer questions by the instructor for the evaluation.

  • 1: Developer comes to evaluation unprepared with a presentation. Developer has a difficult time communicating their process. Instructor leads the entire evaluation and must prompt the developer on every area of the rubric.

Project Professionalism

Check-in one:

  • 4: Developer fulfills all requirements below, and has most of the project completed. Developer comes with a plan to refactor their current application or work on extensions during the checkin.

  • 3: Developer communicates and turns in any additional deliverables by the prescribed deadlines outlined by instructors. Developer has finished all endpoints for phase one of the project and has their application deployed to production.

  • 2: At least one endpoint within the project spec are working and complete. Project is deployed to production on Heroku.

  • 1: Developer misses instructor deadlines, has zero endpoints completed, and doesn’t have their application deployed to Heroku.

Check-in two:

  • 4: Developer fulfills all requirements below, and has most of the project completed. Developer comes with a plan to refactor their current application or work on extensions during the checkin.

  • 3: Developer communicates and turns in any additional deliverables by the prescribed deadlines outlined by instructors. Developer has finished all endpoints for phase two of the project and has their application deployed to production.

  • 2: At least one endpoint within the project spec are working and complete. Project is deployed to production on Heroku.

  • 1: Developer misses instructor deadlines, has zero endpoints completed, and doesn’t have their application deployed to Heroku.

Lesson Search Results

Showing top 10 results