Our team depends heavily on GitHub Issues for project management. It has taken a while to develop a workflow that maps GitHub’s features to our Agile workflow. This is an overview of the life of a project and the life of an issue in our workflow.

I am assuming you’re familiar with agile project management that uses difficulty estimation and velocity to project delivery dates.

A Project is Created

When we start structuring a project with a client we setup a new repository on their organization acccount, and we setup a team for ‘Spry Release Managers’ with read/write access to the repository and a team for ‘Spry Developers’ with read only access to the repository.

A Backlog is Populated

The first step to starting a project is creating issues in GitHub. We structure our deliverables into multiple contracts called statements of work. We generate an issue for each deliverable on our statement of work and assign and SOW label to the issues. SOW labeles are identified by an SOW/{ID} label, where {ID} is the unique identifier we use for a statement of work in our business.

Deliverables are Prioritized

Once we’ve generated the backlog we meet with the client and assign priorities to the tasks. Tickets are prioritized on a scale of 1, being the highest priority, to 10. The priority is annotated on the issue using a label in the form of priority/N where N is the set of values 1 through 10.

Difficulty is Estimated

After issues have been prioritized by the end users, our developers start reviewing and assigning difficulty to the tickets. During the estimation process our developers work with the client and stateholders to develop a list of acceptance criteria for each ticket that is included in the issur body. Difficulty is annotated on the issues using a label in the form of points/N where N is the set of values 0, 0.5, 1, 2, 3, 5, 8.

A Sprint is Started

We create a milestone to represent a sprint. We allocate the highest priority work items to the sprint trying to match our velocity projections. On a new project we arbitrarily assign the issues developers feel they can complete in the first sprint according to priority.

An Issue is Started

When a developer begins work on an issues, they assign it to theirself.

An Issue is Completed

When a developer completes a task, they submit a pull request to incorporate their code. A Release Manager reviews the pull request. If the pull request is acceptable it will be merged and the original issue closed and assigned to the client responsible for final review.

A Sprint is Reviewed

Once a Sprint is complete the closed issued are reviewed with the client for final determination of completion. Any incomplete or re-opened issues are returned to the backlog. The Sprint Velocity and the Projects Velocity are re-calculated.

Experiences

This has worked well for our team and seems to work well with the clients we’ve used the process with. What workflows are you using with GitHub’s Issues? What is working for you?