Skip to main content
Testing. You are viewing the public testing version of GCN. For the production version, go to
New Announcement Feature, Code of Conduct, Circular Revisions. See news and announcements

GitHub Project Board

Go to GCN Project Board

We use GitHub Projects to organize our development process. We chose GitHub Projects becase we already extensively use GitHub Issues and Milestones. GitHub's Projects Documentation

We have a total of six possible ticket states.

No Status

These are tickets that have not been fully refined or pointed yet.


These are tickets that are fully refined and pointed and are ready to go. They may be planned for a particular sprint or have no sprint attached.

In Progress

These are tickets that are under way. A developer should be assigned to any tickets in progress.

In Review

We manually put tickets into review status when PRs are ready for review.


This is for tasks that are blocked and waiting on something from a source other than the assigned developer.


These are tickets that have merged PRs or completed tasks. Use GitHub trigger keywords (for example, closes #123) to ensure tickets are linked to PRs and this will automatically happen on merge.

They appear visually as columns on our project board as seen in this screenshot.

Screen shot of GCN Project in GitHub Projects

When you open a specific Issue while on the Project board, you will see ticket details open on the right hand side of the window. This is where you can find ticket metadata.

Screen shot of and open ticket on the GCN Project in GitHub Projects

Project specific metadata can be found by scrolling down in the right hand Issue pane. There are other types of ticket metadata preceding and following this section. The GitHub Project specific metadata section looks like the following screenshot.

Screen shot of ticket Project metadata in GitHub Project

We create Issues for all work. All Issues should have a detailed title, description, and acceptance criteria. All issues must be pointed before moving into the Backlog or In Progress. Some Project metadata is also editable from an Issue page.

Screen shot of a GitHub Issue


We point tickets as a group during planning meetings. We use the description and acceptance criteria written in the GitHub Issue to ensure group understanding of the work. Once we have agreed that we understand the scope and request, we vote on the level of complexity for that body of work. We use the unique numbers in the Fibonacci sequence to represent complexity. We only go up to 21 points, making our options 1, 2, 3, 5, 8, 13, and 21. We also have the additional options of coffee or question mark. We average the votes if there is not wide variation in pointing values, so a ticket may be pointed at values not found in our pointing options. If there is a difference of more than a couple of points, we discuss why we voted higher/lower. Someone might have information that the others don't have.

1This is something incredibly straightforward such as a copy fix.
2This is twice the complexity of a one line or copy change.

This is associated with a feature or bug fix of medium complexity. It is larger than a few line changes, but is typically smaller than a fully fledged feature, and includes more significant testing.


This level of complexity represents a more full feature or a more complex bug that takes a bit more effort than a 3. It might require more intensive testing, in depth research, documentation, and/or higher code complexity.


This is quite large for one ticket. This is typically the highest we like to point tickets. It may need to be broken down into smaller steps where possible. This level of complexity could take a large part of a sprint.


This is where we start deeply questioning the scope of the ticket. If a ticket is 13 points, it is possible that it is not broken down into small enough steps and would benefit from further refiment.


This is a wildly difficult task. This will take more than an iteration/sprint. This task likely needs further refinement.

coffeeThis indicates that you are present but abstaining from voting.
question mark

This is used when the description or acceptance criteria are too vague to make an accurate estimate or there are any outstanding questions that would prevent accurate pointing.

Tickets with clear descriptions and acceptance criteria are pointed before being placed in the Open column.


We use both sprint and iteration to mean a two week period of work. Our GitHub Project board uses iterations though these spans of work are more frequently known as sprints. Our team uses both words interchangeably.

Looking for U.S. government information and services? Visit