18.1 KB
Newer Older
1 2 3 4 5 6 7 8 9 10
layout: markdown_page
title: "Category Direction - Kanban Boards"
description: This is the category strategy for Kanban Boards (Issue Boards) in GitLab; which is part of the Plan stage's Project Management group. Learn more!
canonical_path: "/direction/plan/kanban_boards/"

Last reviewed: 2020-07-13

12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266

## 🚥 Kanban Boards

|          |                                |
| -------- | ------------------------------ |
| Stage | [Plan](/direction/plan/) |
| Maturity | [Viable](/direction/maturity/) |

### Introduction and how you can help

<!-- Introduce yourself and the category. Use this as an opportunity to point users to the right places for contributing and collaborating with you as the PM -->

Thanks for visiting this category strategy page on Snippets in GitLab. This page belongs to the [Editor](/handbook/product/product-categories/#editor-group) group of the Create stage and is maintained by <PM NAME>([E-Mail](mailto:<>) [Twitter](<TWITTER>)).

This strategy is a work in progress, and everyone can contribute:

 - Please comment and contribute in the linked [issues]( and [epics](([]=snippets) on this page. Sharing your feedback directly on is the best way to contribute to our strategy and vision.
 - Please share feedback directly via email, Twitter, or on a video call. If you're a GitLab user and have direct knowledge of your need for snippets, we'd especially love to hear from you.

👋 This is the category strategy for Kanban Boards (Boards) in GitLab; which is part of the Plan stage's [Project Management](/handbook/categories/#project-management-group) group. Please reach out to the group's Product Manager, Gabe Weaver ([E-mail](, if you'd like to provide feedback or ask any questions related to this product category.

This strategy is a work in progress and everyone can contribute:

- Please comment and contribute in the linked [issues]([]=group%3A%3Aproject%20management) and [epics]([]=Category%3AIssue%20Tracking) on this page. Sharing your feedback directly on is the best way to contribute to our strategy and vision.
- Please share feedback directly via email, Twitter, or on a video call.

### 概要

<!-- A good description of what your category is today or in the near term. If there are
special considerations for your strategy or how you plan to prioritize, the
description is a great place to include it. Provide enough context that someone unfamiliar
with the details of the category can understand what is being discussed. -->

#### Purpose

GitLab's mission is to build software so that **everyone can contribute**. Boards are intended to helps teams collaborate together more effectively during the planning and execution of sprints and releases.

#### Essential Intent

The goal of a Category's "Essential Intent" is to provide a concrete, inspirational statement. Another way to think of it is answering this single question -- *"If Issue Boards can be truly excellent at only one thing, what would it be?"* This is Issue Boards' Essential Intent:

> To empower teams to work on the right things in a transparent, collaborative, and consistent manner.

Next, asking "How will we know when we're done?" provides clarity of purpose. This is how we will know:

- Boards support other objects that move through workflows such as Epics and Merge Requests.
- Teams can create workflows to automate the movement of objects between lists based on rules they define.
- Boards can be configured to support Timeboxed or Continuous Planning models with the click of a button.
- Changes to data on objects reflected on issue boards is propogated to all connected clients and rendered in under a second.
- Teams can reliably communicate when any object on a Board will be completed with 99% accuracy.
- Team Members can immediately understand what next steps they need to take on which object and in what order just by looking at the Card.
- Boards provide built in modes for various "Agile" practices such as backlog refinement, prioritization, conducting release planning, or holding a retrospective.
- Boards have integrated analytics that helps teams continuously improve their processes.
- Boards expose rich contextual data about the relationships and current status of related objects.
- Teams never have to leave their current Board to manage or interact with any objects represented on a Board.

#### How we prioritize

We use the following decision framework when evaluating what to work on. Each idea must meet all three of the minimum criteria and two of the extreme criteria.

|                  | Criteria 1 | Criteria 2 | Criteria 3 |
| ---------------- | ----------------------------------- | ------------------------------------ | ----------------------------- |
| Minimum (3 of 3) | simplifies collaboration | reduces the friction to contributing | aligned with market direction |
| Extreme (2 of 3) | enhances the ability to build trust | decreases manual effort | increases clarity and purpose |

#### Target Audience

List the personas ( involved in this category.

Look for differences in user's goals or uses that would affect their use of the product. Separate users and customers into different types based on those differences that make a difference.

Issue Boards are geared towards software development teams, but are also flexible enough for other teams in your organization to manage any type of tasks requiring tracking. We are optimizing Issue Boards for the following personas:

- [Parker (Product Manager)](/handbook/marketing/product-marketing/roles-personas/#parker-product-manager)
- [Delaney (Development Team Lead)](/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead)
- [Presley (Product Designer)](/handbook/marketing/product-marketing/roles-personas/#presley-product-designer)
- [Sasha (Software Developer)](/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer)
- [Devon (DevOps Engineer)](/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer)

#### Challenges to address

- What needs, goals, or jobs to be done do the users have?
- How do users address these challenges today? What products or work-arounds are utilized?

Provide links to UX Research issues, which validate these problems exist.

- ~55% of teams use Scrum, ~10% use Kanban, 5% use ExtremeProgramming, and the rest a mixtures of the various core agile methodologies. First class support for all of these in a simple, convention over configuration manner within Issue Boards is non-trivial.
- Issues Boards are fairly useless from a "real time collaboration" standpoint. There is a large demand for solving this by building a Trello Powerup to enable [attaching issues to Trello cards](
- GitLab is currently not tracking the important metrics for Scrum and Kanban teams. Many customers have written custom scripts to import information from GitLab via the API into BI tools for reporting on common things like cumulative flow and velocioty.

### Where we are Headed

Describe the future state for your category.
- What problems are we intending to solve?
- How will GitLab uniquely address them?
- What is the resulting benefits and value to users and their organizations?

Use narrative techniques to paint a picture of how the lives of your users will benefit from using this
category once your strategy is at least minimally realized -->

We've written a [mock press release](/direction/plan/project_management/one_year_plan.html) describing where we intend to be by 2020-09-01. We will maintain this and update it as we sense and respond to our customers and the wider community.

#### What's Next & Why

<!-- This is almost always sourced from the following sections, which describe top
priorities for a few stakeholders. This section must provide a link to an issue
or [epic]( for the MVC or first/next iteration in the category.-->

These are the epics that we will be working on over the next few releases:

- [Real-time Boards](
   - **Why:** To allow teams to collaborate in real time on Issue Boards to improve the efficiency and effectiveness of planning and staying in sync on who is working on what.
- [Integrated analytics on Issue Boards](
   - **Why:** So that teams have burndown charts and cumulative flow diagrams specific to their team and workspace.
- [Custom Workflows](
   - **Why:** So teams can define a standard process and workflow that issues should flow through. This will help teams improve consistency, have a clear understanding of the current status of an issue, and is a pre-requisite to providing more advanced value stream reporting.
- [Swim lanes on Issue Boards](
   - **Why:** So teams can gain more visibility into their workflows by organizing issues in horizontal lanes across lists that group issues according to differnet contexts such as epics, assignees, milestones, and label.

#### What is Not Planned Right Now

<!-- Often it's just as important to talk about what you're not doing as it is to
discuss what you are. This section should include items that people might hope or think
we are working on as part of the category, but aren't, and it should help them understand why that's the case.
Also, thinking through these items can often help you catch something that you should
in fact do. We should limit this to a few items that are at a high enough level so
someone with not a lot of detailed information about the product can understand
the reasoning-->

#### Maturity Plan

<!-- It's important your users know where you're headed next. The maturity plan
section captures this by showing what's required to achieve the next level. The
section should follow this format:

This category is currently at the XXXX maturity level, and our next maturity target is YYYY (see our [definitions of maturity levels](

- Link to maturity epic if you are using one, otherwise list issues with maturity::YYYY labels) -->

This category is currently at the 😊**Viable** maturity level, and our next maturity target is 😁**Complete** by 2020-06-22.

We are tracking our progress against this target via [this epic](

### User success metrics

- What specific user behaviors are indicate that users are trying these features, and solving their problems?
- How will users discover these features?

We are currently using the [loose Stage Monthly Active Users (SMAU) definition]( and intend on migrating to the strict definition as soon as we've implemented the necessary telemtry to measure the defined events.

### Why is this important?

- Why is GitLab building this feature?
- Why impact will it have on the broader devops workflow?
- How confident are we? What is the effort?

Issue Boards are the primary mechanism to keep teams aligned and executing on a shared, prioritized roadmap at the issue level. They also will provide the foundational constructs that allows teams to follow a consistent workflow and get quantitative data that empowers them to build trust through setting better expectations.

### Competitive Landscape

<!-- The top two or three competitors, and what the next one or two items we should
work on to displace the competitor at customers, ideally discovered through
[customer meetings]( We’re not aiming for feature parity with competitors, and we’re not just looking at the features competitors talk
about, but we’re talking with customers about what they actually use, and
ultimately what they need.-->

The top competitor in this space is Atlassian's Jira, who are entrenched in many enterprise organizations that need an Agile/Kanban board solution. Atlassian also bought Trello, which is another significant player in this space, which has emphasized usability and being able to abstract out underlying software implementation details of an Agile sprint, to just simple task planning with a board interface.

Jira's and Trello's boards have inspired us to further refine and make our boards even more usable. In particular, we have the following ideas sketched and scoped out, including doing a lot more right in the board itself, without leaving it:

- [Combine board config and board filter for milestones](
- [Rows and columns design of boards - Remove mixed lists boards](
- [Epic swimlanes and filter in boards](
- [Edit issues without leaving board](

### Analyst Landscape

<!-- What analysts and/or thought leaders in the space talking about, what are one or two issues
that will help us stay relevant from their perspective.-->

Similar to [Project Management](../issue_tracking/), the analyst landscape is focused on enteprise agile planning and value stream management. Issue Boards are a means to further make these processes more refined and efficient. See:

- [Agile Portfolio Management](../../portfolio_management/)
- [Value Stream Management](../../../direction/manage/value_stream_management/)

### Top Customer Success/Sales issue(s)

<!-- These can be sourced from the CS/Sales top issue labels when available, internal
surveys, or from your conversations with them.-->

- [Overview of Issue Boards across ALL projects]( (👍 108, +4, +5, +4)
- [Improve the efficiency and experience of weighting an issue backlog]( (👍 0, +0, +0, +0)
- [Custom Workflows Per Group]( (👍 11)

### Top user issue(s)

<!-- This is probably the top popular issue from the category (i.e. the one with the most
thumbs-up), but you may have a different item coming out of customer calls.-->

- [Subissues on issue board]( (👍 93 +1, +2, +1)
- [Create personal issue boards]( (👍 74, +5, +2, +4)
- [Multiple projects issues on same Kanban/Board]( (👍 48, +1, +1, +1)
- [Configure view when clicking on Issues tab to be issue board]( (👍 44, +0, +1, +0)
- [Show tasks completed on Issue Card]( (👍 45, +2, +1, +1)
- [Add Time Tracking column totals to Issue Board]( (👍 42, +1, +3, +0)
- [Import/Export label configuration & Issue Board layout]( (👍 47, +4, +3, +3)
- [Filter by (and board config) Project on Group Issue Board]( (👍 70, +11)

### Top internal customer issue(s)

<!-- These are sourced from internal customers wanting to [dogfood](/handbook/values/#dogfooding)
the product.-->

- [Burndown chart in issue boards]( (👍 10, +3, +0, +2)
- [Real time boards]( (👍 99, +5, +4, +6)
- [Horizontal Swimlines]( (👍 28, +2, +5, +6)

### Top Strategy Item(s)

<!-- What's the most important thing to move your strategy forward?-->

Make Boards more extensible to support multiple different types of objects such as Epics and Merge Requests and expose rich context about the relationships of these objects with other objects within GitLab:

- [Epic/Program Boards](
- [Merge Request Boards](
- [Highly configurable X and Y axes on Boards](

A one year goal is to provide soft real time collaboration on objects within Boards. To get there, we need to:

- Implement [websockets](
- Refactor Issue Boards to use GraphQL / Subscriptions to work with our websockets implementation. This will enable baseline [real-time baord lists](
- This will then open the door for allowing full interaction with objects from [within Boards](

Another goal is to integrate analytics such as burndown charts and cumulative flow diagrams directly into Boards. In order to do that, we need to:

- Introduce the ability to define consistent workflows. The working approach is to abstract the ability to do this from the existing behavior of [customizing stages in cycle analytics reports](
- Make a lot of improvements outlined in the `Category:Issue Tracking` direction that directly impact the quality of data we can show on a Card.

We also want to provide a more seamless flow from top down planning all the way to the issue level. As we work on improving epics and our roadmapping capabilities, we will also need to focus on:

- Incorporating epics [more formally]( into Boards.
- Integrating [capacity planning and management]( into Boards.