Open Innovations comprises a small team, and we necessarily work across a multitude of projects. Sometimes this works, but increasingly we find that we need a process to help us manage this.
We are mainly interested in tracking delivery of our code-related projects, which we typically manage in GitHub. We have made use of GitHub issues within individual repositories in the past, and have recently decided to implement GitHub projects to integrate all repositories.
Sprint planning meetings are held the day before the sprint starts. This will be the opportunity to agree priorities across project and draft the content of the sprint. The team will also hold an informal retrospective to allow improvements to be made to the process.
The team will hold a shorter mid-sprint checkpoint meeting on Tuesdays where a sprint changeover is not taking place. This is an opportunity to check for general blockers in the process and apply course correction. It is also an opportunity to perform backlog refinement to ensure that the next sprint planning session has a good range of tickets to work with.
The team has adopted the GitHub projects default states. This is how we will use them.
| State | Description |
|---|---|
| New | This state should be used to hold rough drafts which could be significantly refined as they enter the backlog. |
| Backlog | Place for refinement of the ticket, towards being able to include in a sprint. Items in the backlog are not yet deemed sufficiently well defined to be able to implement. Generally this means they will need clearer acceptance criteria adding. There may be tasks required (e.g. speaking to customers) before these can be progressed. |
| Ready | Tickets in this state can be picked up by anyone with the skills to complete them. It is the responsibility of the person picking up the ticket to ensure they understand the acceptance criteria. If these are not clear, for any reason, they should move the ticket back into backlog for further discussion |
| In Progress | Tickets that are being actively worked on. It's generally best practice to only have one ticket in progress per team member at any one time. Things like urgent changes might slightly break this rule, but lots of items per team member might point to unclear tickets, or other blockers. |
| In Review | This is a state where nearly complete tickets that require a brief review are kept. This is particularly useful for more complex tickets, or new features. It's generally good practice to move the ticket into this column then add a brief comment @-mentioning the people that you would like to take a look. Include any specific points that you'd like an opinion on. This state can also be used if something is blocked. Mention this in the column. |
| Done | The ticket has been completed, with all acceptance criteria met. No further discussion required. |