Kanban Board

In order to keep overview over current tasks, we have a physical kanban board in our office. Current tasks are put onto cards and attached to it using magnets.

Layout

The Kanban Board consists of the following four columns:

• New: new issues/tasks/ideas/requests/etc. (in no specific order) from anyone, e.g. fellow colleagues or stakeholders. Every ticket will be checked/reviewed on a regular basis and put in the backlog if accepted.
• Backlog: this is a list of tickets (e.g. tasks or issues in GitLab) which is sorted by priority. Tickets at the top have the highest priority.
• In Progress: in here the progress of the implementation and review phase is tracked. A detailed explanation of every column and sub-column will be provided in the next part.
• Done: a list of finished tickets (in no specific order).

Always add newly created tickets to the New column, never to the Backlog column. Tickets get only moved from the New to the Backlog column when the team accepted and prioritized them. Tickets (meaning physical cards) in the Backlog column always need a corresponding GitLab issue - yes, even simple tasks!

The In Progress Column

The In Progress column consists of the following three columns which represent the stages when working on a ticket:

Implement

In this stage the ticket gets done/implemented. If the task is to break down a bigger ticket into smaller ones this is where it is done. This stage has the additional column Blocked/Track for tickets for which work has started but could not be finished because of external factors. They always have the highest priority and everyone helps out finishing them when done with his/her current task.

Done rules:

• The GitLab CI pipeline succeeds.
• The corresponding MR in GitLab is not WIP.
• The corresponding MR in GitLab has no assignee.
• The version is bumped (e.g. in pyproject.toml file for a python project)
• An entry with all the changes in the change log is present.

Limit work in progress (WIP):

Only a limited amount of tickets may be in progress at any point. Check out the Kanban board for WIP limits.

Review

In this stage the MR in GitLab gets reviewed. If the task is to break down a big ticket into smaller ones this stage serves as the review step for the plan / road map.

Done rules:

• No unresolved discussion in the corresponding GitLab MR.
• The GitLab CI pipeline succeeds. As new commits can be pushed when resolving discussions, the pipeline can fail even when it succeeded before.
• The corresponding MR is assigned to the person who did/implemented the ticket.

Limit work in progress (WIP):

Only a limited amount of tickets may be in progress at any point. Check out the Kanban board for WIP limits.

The Done Column

Tickets in the Done column are GitLab issues which are done - no backsies! A GitLab issue is done when the following rules apply:

Done rules:

• The corresponding MR in GitLab is merged.
• The branch from the MR in GitLab is deleted.
• The corresponding GitLab issue is closed.
• A tag for the new version is created.
• The package is released or the application deployed.
• If an application was deployed it needs to run & be healthy.

Kanban Cards

Cards on the Kanban board should have the following information:

• project-name: The name of the project in GitLab. Use Kebab Case.
• short title: Short title of the corresponding GitLab issue. Try to make it short and specific so everyone knows which issue it is and what it is about.
• #<issue-id>: The id of the corresponding GitLab issue. Please use the same format as used in GitLab, e.g. #123.