doc/tutorials/kanban/_index.md
This tutorial guides you through the steps on using GitLab issue boards to manage your tasks in a Kanban workflow. By setting up groups, projects, boards, and organizing issues, you can enhance transparency, collaboration, and delivery.
To use GitLab issue boards to manage your tasks in a Kanban workflow:
For other information, see advanced tips and tricks at the bottom of this page.
Follow the corresponding steps to create your groups and projects
If your team is working across multiple repositories, create a project for each repository in your group.
Issues will canonically be in their respective projects, but your kanban board will be in your group so you can maintain visibility across all of your projects. If you are working in a single repository, you can skip this step.
Next, let's create some labels to represent each step in your Kanban lifecycle:
In both scenarios, the process for creating labels is the same. Create scoped labels for status::to do, status::doing, and status::done.
After you've created your labels, the next step is to create a Kanban board:
Congrats, you now have a Kanban board. You can now create new issues in each list, drag and drop issues from one workflow step to another, and assign issues to team members.
Optionally, you can enable work in progress (WIP) limits for each label list on your board. To do so:
Your list background will now automatically turn red when the limit is reached. A "work in progress limit" cut line will also be visible in the list to visually display all issues that are over the limit below the line.
Kanban traditionally uses Cumulative Flow Diagrams to visualize load and help identify bottlenecks. In GitLab, this can be accomplished with Value Stream Analytics (VSA). Next, we'll create a custom VSA report that matches your Kanban workflow.
To visualize flow:
With your custom VSA report that matches the same workflow as your Kanban board, GitLab automatically calculates the time each issue spends in each stage and aggregates the data across all stages. As a result, you get the lead time and cycle time. You can dig into each stage to see the specific timings for individual issues.
To visualize distribution:
gitlab-triage. For example, you can create a policy to automatically close issues when the status::done label is applied, or automatically add the status::to do label when an issue is created. The open source gitlab-triage gem is designed to work seamlessly with GitLab pipelines.