Skip to Content

Github Issue and Milestone Usage

Milestones

Each team must create a milestone for each iteration; we will call the iterations “sprints”, so you will have the milestones “Sprint 1”, “Sprint 2”, etc. Make the due date of the milestone the date of the associated lab demo. At the beginning of a new sprint (right after a demo), you must select (and create, if needed) the issues that you will work on and assign them to the new sprint milestone.

Issues

Issues must be created to capture all project work. Issues should be created when the team recognizes that some future work item needs to be done, so that you can use your open issues to help plan your work. Think of your open issues as your Scrum product backlog.

Every issue must have an effort estimation at the end of its title, in parentheses; this estimation is in terms of fibonacci-restricted story points; you must not change this estimation as you go.

Every issue must have at least one label. See more discussion below on labels.

If an issue is directly related to one user story, include “[US#]” in its title.

A good practice is to make every commit have at least one issue number hashtag in its commit message. Github recognizes this in a commit message and will create a link from, e.g., “#37” in a commit message to issue 37. This then ties the work to the issues that the work is for (called traceability).

Labels

GitHub default labels are pretty bad. You can read my page on labels for more extensive ideas, but a good simple change to the default labels would be to change them to be: User Story, Documentation, Bug, Refactor, Infrastructure, Toolwork, Testing. You must assign at least one label to every issue when you create it.

Wiki

Every team must use the GitHub Wiki to document their project. This page has more info. Assignments will also provide more detail as to the documentation content.

Project Board (optional)

If you want to use the Project tab in GitHub, my recommendations are: create one Project, called “Work Backlog”. Choose the “Basic Kanban” template when you create it. Issues will be assigned to this “project” only when they are selected to be worked on. Do not immediately assign a new issue to this project unless you intend to immediately work on it. Otherwise, leave the issue unassigned.

Never delete anything from your project boards, only move them (finally) to Done.

You can create board cards for notes, but never create cards that represent real work; real work must be captured by an issue.

Using a project board is optional; you can organize and manage everything in issues (with labels and milestones), but you may find the project board useful.