Skip to Content

Github Sprint Workflow

Posted on 3 mins read

During each project iteration (sprint), the team will work on making progress on their project and all of its associated parts (coding, documentation, etc.). The following set of rules must be adhered to for project work. Sprint evaluation and grading will involve checking for these.

  1. The Sprints Page in your GitHub wiki must be updated. This would be best done immediately after the demos in lab. Follow the page description on GitHub wiki pages. In particular, create content for the sprint velocity, team performance and sprint reflection on the past sprint; and then edit the goals and scrum master for the current (new) sprint.

  2. You must create/edit your GitHub issues at the beginning of the new sprint. Then you must select issues to work on for this sprint by assigning the milestone “Sprint#” to them (whatever the sprint number is). Issues that had the previous sprint’s milestone associated with them but were not closed should have their milestone tag removed and either left blank or have this sprint’s milestone added (if you intend to work on the issue). All selected issues must be assigned to one or two team members. Optional: If you are using the project work board, issues with this sprint’s milestone tag can be added to the Work Project “To Do” board.

  3. Team members should not be doing any work that is not associated with at least one GitHub issue (thus, you should have issues even for documentation and other tasks). If you are about to do work that cannot be associated with any existing issue, then create one and assign yourself! Optional: If you are using the project work board, each issue must be moved to the project board’s “Doing” and “Done” columns as it proceeds.

  4. Beginning in Sprint 2, all work must be done in a Git branch that is created either: a) for the team member’s project work (recommended); b) for the team member’s work for that sprint; or c) for work on a particular issue. See my page on branching for more detail.

  5. Before the end of a sprint, all work branches must be merged into the main branch by using pull requests. You probably will be using pull requests to also merge work pushed to the main branch back into your development branch.

  6. All commits must have at least one issue number (as a hashtag) in its commit message.

  7. After merging, the team should review the work that was done, and should close any issues that have been completed. You should not have long-running generic issues, such as “Work on documentation” that you never close; rather, you should have specific issues, such as “Create domain model and integrate into Wiki” and then when they are done you should close them.