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.
| Status | Description |
|---|---|
| No Status | These are tickets that have not been fully refined or pointed yet. |
| Open | 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. |
| Blocked | This is for tasks that are blocked and waiting on something from a source other than the assigned developer. |
| Done | These are tickets that have merged PRs or completed tasks. Use GitHub
trigger
keywords
(for example, |
They appear visually as columns on our project board as seen in this screenshot.
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.
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.
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.
Pointing
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.
| Points | Description |
|---|---|
| 1 | This is something incredibly straightforward such as a copy fix. |
| 2 | This is twice the complexity of a one line or copy change. |
| 3 | 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. |
| 5 | 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. |
| 8 | 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. |
| 13 | 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. |
| 21 | This is a wildly difficult task. This will take more than an iteration/sprint. This task likely needs further refinement. |
| coffee | This 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.
Iterations/sprints
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.