Grading

As an experiential course intended to prepare you for the transition to industry, grading operates a bit differently in this class. We will be employing criterion grading. With criterion grading, your work is either deemed “acceptable” or “unacceptable”. Acceptable work earns a 100%, while unacceptable earns 0%. Note there is no partial credit in criterion grading!

While this may seem harsh at first, it parallels what you can expect on the job. If you regularly turn in “almost-there” work in a professional setting, you can expect to be looking for a new job in short order. Your work must be of acceptable level. Of course, you should strive to do exceptional work rather than just acceptable - so there is a possible 5% bonus on criteria-graded assignments for exceptional work.

Sprint Release Grades

Given the use of criterion grading, each Sprint Release must meet all of these requirements:

• Code Quality Code should compile and run, not suffer from unhandled errors, and perform as described in the user documentation.
• Coding Style A consistent and understandable coding style should be employed throughout the code base. Variable names should be consistent and descriptive of their roles. Indentation should be used consistently to delineate nested code bodies.
• In-Code Documentation Code should contain detailed in-line descriptions of each class, property, method, and function at their point of declaration. An auto-document style appropriate to the language should be used for inline comments. Non-obvious sections of code should be commented with a description of their operation and purpose. The documentation should be legible, grammatically correct, and profanity free.
• Licensing Full text of the license should be included in the repository, and each file should contain a copyright statement referring to it.
• Developer Documentation The documentation should be sufficient to orient a new programmer to the codebase and describe where the important aspects of the code are located. The programmer documentation should include diagrams of the code structures and how they interact (i.e. class diagrams, database diagrams, use-case diagrams) where appropriate. The documentation describe how to set up the development, testing, and production environments. The documentation should be legible, grammatically correct, and profanity free.
• User Documentation User documentation may be integrated into the project GUI or provided as a separate document or website. The documentation should give currently correct instructions on how to use the software. It should be written appropriately for the target user’s background. It include screenshots, diagrams, or video to enhance understanding. The documentation should be legible, grammatically correct, and profanity free.
• Test Suite The release should include an appropriate test suite that performs unit and integration tests on the existing code base, and all tests should pass. If an automated test suite is not possible, the release should include a written test plan and documentation of its outcome for the release.

Attendance Grades

Rather than taking attendance every day, which cuts into our class time, I instead record absences as negative points in the corresponding categories. You can find two assignments in the Absences module:

• Team Meeting Absences will be used to record absences from regular team meetings, i.e. the stand-ups and check-ins. These are held during the class period, so there is no reason to miss them.
• Formal Meeting Absences will be used to record absences from the formal team meetings - i.e. Sprint Planning and Sprint Review meetings. These are the meetings where you present your work and plan future work with your customers so absences here are a big deal. Each absence will deduct points equivalent to a drop of a letter grade in the course.

Peer and Customer Reviews

Not all assignments are criterion-graded. Specifically, the peer review and customer review assignments are based on a survey given to your team members and customers, respectively. This survey asks them to evaluate you on a scale of 1 to 10 across several categories. Instead of translating directly to a grade, we use the following calculation:

Base score = 100 points
-10 points for each category averaging 6 or 7 points
-20 points for each category averaging 4 or 5 points
-30 points for each category below 3 points

This means that a category score of 8, 9, or 10 is “acceptable” and does not impact your grade. However, a score of 8 does suggest you have room to improve in this category, and should strive to do so. Keep this in mind when you fill out peer reviews for your teammates - you can rate them at an 8 or 9 to indicate that you see room for improvement without hurting their grade.