Evaluating GitHub Repositories (within an Agile Software Development Course)

The following eight parts of a project should be thoroughly completed. Each is worth equal amounts of the total grade for setting up the project documentation correctly. Each of these parts will be graded all or none… if a team has clearly not put in effort to think through and set up the project nicely, they should not be given a good grade!

Product backlog

A list of all User Stories and Spikes in the Product Backlog must be viewable in the Issues tab on the repository.
The students should have spent some effort thinking about most of the obvious user stories that their project might require - a small list is a sign of little effort.

Task Board set up

The Task Board is supposed to show exactly what each member of the team is working on at any given moment. If it fails to accurately show this, it is not done correctly.

The Task Board, viewable under the Projects tab of the repository, must be named correctly, e.g. “Sprint 0 Task Board”, “Sprint 1 Task Board”, etc.
Are the columns named correctly, e.g. “Sprint Backlog”, “To Do”, etc.
User stories should be in the Sprint Backlog column, never in any other column
Tasks and Spikes should be in the other columns, and they should be placed in the column that accurately represents their current status

Issues in the Task Board (including User Stories, Spikes, and Tasks)

Issues in the Task Board must be labeled either “user story”, “spike”, or “task”, but never more than one of those labels.
All issues in a sprint must be assigned to the proper milestone, such as the “Sprint 0” milestone.
All tasks and spikes must be assigned to one or more team members - it is not acceptable for any to be unassigned
If an issue needs to be completed independently by multiple team members (such as installing something on their own computer or learning something individually), it is not okay to have just a single issue for it on the Task Board - there should be one issue for it assigned to each team member individually.

User stories in the Task Board

All user stories must have a title like, “As a ___, I want to ___, so that ___.”, where the blanks are filled.
All user stories must have the label, “user story”.
User stories in the current Sprint Backlog must be assigned the milestone associated with the current Sprint.
Every User Story must have at least one Task associated with it. More likely than not, there should be many Tasks for any one User Story.
User stories may optionally have a description that includes Acceptance Criteria and an Estimate of Work.

Tasks in the Task Board

Every Task must contain a link to the User Story from which it was created.
Every Task must be assigned to a specific developer.
Every Task must be assigned to a specific milestone.
Every Task must be labeled, “task”.

Spikes

Going forward, each team member will have to set up GitHub, install software on their local machines, and learn how to use the technology stack for their project. If none of these things are represented as separate Spikes in the Task Board for each team member, then their Task Board is not accurately showing the work they need to do. In subsequent sprints, these sorts of spikes may or may not be present.
All spikes must have the label, “spike”.

Markdown files in the repository

Students are required to keep their README.md and CONTRIBUTING.md files well written, and up to date, with proper markdown syntax and clear formatting. Sloppiness in text formatting or writing is not allowed and will be punished.
The README.md must show a clear description of the project, a link to the CONTRIBUTING.md file, and very clear and thorough instructions on how to install and build the project code. As the project evolves and the steps to install and build the project change, these files must be kept up-to-date.e
The instructions on the README.md file for how to to install and build the project code must work. If someone elses can’t figure out how to install and build the code, then the instructions are useless.
The CONTRIBUTING.md file must show a clear description of how members of the team contribute to the project, and what is and is not acceptable to the team.