Evaluating GitHub Repositories (within an Agile Software Development Course)

The following four 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!

The Product Backlog, Sprint Backlogs, and Sprint Task Boards, viewable under the Projects tab of the repository, must be named clearly, e.g. “Product Backlog”, “Sprint 0 - Backlog”, “Sprint 0 - Task Board”, “Sprint 1 - Backlog”, “Sprint 1 - Task Board”, etc.

Product backlog

A list of all User Stories for the entire project must be present in a table named “Product backlog”.

Nothing else should be placed in the Product Backlog.
All user stories must have an appropriate title i.e., “As a _____, I want to _____, so that _____.”, where the blanks are filled.
All user stories must have the label, “user story”.
A small list of User Stories is a sign of little effort and should be graded as such.

Sprint backlogs

User stories being worked on in the current Sprint must be placed in a Sprint N - Backlog table, where N is replaced with the current Sprint number.

Nothing else should be placed in a Sprint Backlog.
User Stories in each Sprint Backlog must conform to the same rules as those in the Product Backlog.
Sprint Backlogs for any previous Sprint must be frozen in the state they were in when the prior Sprint ended and not modified after the fact.

Task Boards

A Task Board for the current Sprint must 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.

Columns in each Task Board must be named clearly, e.g. “To Do”, “In progress”, “Awaiting review”, “Done”.
The Task Board must show all the Tasks and Spikes derived from the User Stories in the relevant Sprint Backlog… A small number of Tasks and Spikes indicates lack of effort… typically there will be several-to-many Tasks per User Story.
Each Task and Spike must be placed in a column that accurately represents its current status at all times.
Task and Spikes on the Task Board must be labeled “spike” or “task” appropriately, but never more than one of those labels and certainly never labeled “user story”.
All Tasks and Spikes in the current Sprint must be assigned to one or more team members - it is not acceptable for any Tasks or Spikes to be left unassigned after the start of the Sprint.
If a Task or Spike needs to be completed independently by multiple team members (such as installing something on their own computer or learning something individually), it is not acceptable to have just a single isntance of that Task or Spike - there must be one instance of it for each team member who must independently complete it.
Every Task must contain a link to the User Story from which it was created.
At the start of development, 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.

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.