Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
A Kanban board in Azure DevOps is a visual tool used to manage work items and track progress in a project. It provides a clear overview of tasks, their status, and their flow through different stages. Teams can use Kanban boards to visualize work, limit work in progress, and optimize their workflow. Each work item is represented as a card on the board, and columns represent different stages, such as "To Do," "In Progress," and "Done." As work progresses, cards move across columns, allowing teams to monitor and improve their efficiency. Kanban boards are commonly used in agile methodologies and are essential for effective project management.
Both Kanban boards and Taskboards support visualizing the flow of work and monitoring metrics to optimize that flow. The Kanban boards track requirements are sprint-independent, and provide a cumulative flow chart for monitoring progress. Each sprint is associated with a Taskboard that supports tracking tasks defined for the sprint. You can monitor progress through capacity charts and the sprint burndown chart. For more information, see Update and monitor your Taskboard.
Note
Kanban is a Japanese word that literally translates to "signboard." This article uses the general term "boards" to refer to Kanban boards.
Product and portfolio boards
Each product and portfolio backlog corresponds to a board. These boards are associated with teams and display work items based on the selected area and iteration paths. For more information, see Define and configure iterations.
To enhance consistent delivery of high-quality software, Kanban emphasizes two key practices. The first practice is to visualize the flow of work by mapping your team's workflow stages and configuring the board appropriately. The next practice is to constrain work in progress, by setting work-in-progress (WIP) limits. With these practices in place, you can track progress and monitor metrics to reduce lead or cycle time. You can get started by exploring how to use your board.
Kanban concepts and terms
The following table describes terms and tools commonly used for tracking work with Kanban boards and Kanban methods.
| Concept or term | Description | More information |
|---|---|---|
| Blocker | An issue that prevents work from progressing. You can highlight blocked work by using tags and changing the card color. | Customize cards and define style rules for highlighting cards |
| Bottleneck | A constraint in the system that limits the flow of work. Identifying bottlenecks makes it easier to reduce their effect and provides a mechanism for controlling work flowing through the process. | Manage columns and identify bottlenecks |
| Card reordering | Card reordering lets you change the priority order and forces cards to maintain the backlog priority when you drag and drop them on the board. | Reorder cards |
| Columns | A column maps to a stage of work. The default columns map to the workflow states of the work item types that appear on the board. You configure the columns to map workflow states of your team. | Map the flow of how your team works |
| Cumulative flow diagram (CFD) | The in-context CFD report shows the count of items in each column for the past 30 weeks or less. From this chart, you can gain an idea of the amount of work in progress and lead time. Work in progress counts unfinished requirements. | Cumulative flow, lead time, and cycle time guidance |
| Cycle time | Cycle time is the time calculated for a work item from first entering an In Progress category state to entering a Completed state category. You can gain valuable metrics and visualize the cycle time for a team and a configurable time period by adding the Cycle Time widget to the dashboard. | Cumulative flow, lead time, and cycle time guidance |
| Definition of done | Criteria that a team specifies for each stage of work to share and standardize on what makes up work being done at that stage. | Add Definition of Done to a column |
| Kanban board | An interactive, electronic sign board that supports visualization of the flow of work from concept to completion. Azure DevOps provides a board for each product and portfolio backlog. | Kanban board basics, Kanban board features and epics, Track work in swimlanes |
| Lead time | Lead time is the time calculated for a work item from first entering a Proposed category state to entering a Completed state category. You can gain valuable metrics and visualize the lead time for a team and a configurable time period by adding the Lead Time widget to the dashboard. | Cumulative flow, lead time, and cycle time guidance |
| Portfolio backlog | An interactive list of work items, similar to the product backlog that supports organizing or grouping work under features epics, or scenarios. Portfolio backlogs work similarly to product backlogs in that you can prioritize work and view the tree hierarchy of work. | Define features and epics |
| Product backlog | An interactive list of work items that corresponds to a team's project plan or roadmap for what the team plans to deliver. The product backlog supports prioritizing work, forecasting work by sprints, and quickly linking work to portfolio backlog items. You can define your backlog items and then manage their status by using the board. Each team can customize its product backlog. | Create and manage your backlog |
| Product backlog item | A type of work item that defines the applications, requirements, and elements that teams plan to create. Product owners typically define and stack rank product backlog items, which are defined with the Scrum process. | Scrum process work item types and workflow. |
| Split columns | The Split columns feature lets your team implement a pull mechanism within the workflow process. Without split columns, teams push work forward to signal they completed their stage of work. However, pushing work to the next stage doesn't necessarily mean that a team member immediately starts work on the item. With split columns, your team knows exactly how many items sit idle, waiting for work to begin. | Manage split columns |
| Swimlanes | A swimlane is a configurable row on a board used to support different service class levels of work. | Speed up work with swimlanes |
| Task checklists | A task is a type of work item used to track work required to complete a user story or product backlog item. You can add tasks from your board that appear as a checklist of work to be done. As you complete a task, you can update its status by checking the checkbox for the task. | Add tasks or child items as checklist items |
| Task switching | Task switching, also referred to as context switching or multitasking, is when a team member shifts their attention among different tasks. Limiting task switching can allow a person to work more efficiently by minimizing the amount of time required to redirect cognitive function to a new activity. | Switch to backlog view, Switch to board view, Switch to a Taskboard |
| User story | A type of work item that defines the applications, requirements, and elements that teams plan to create. Product owners typically define and stack rank user stories. A user story is defined with the Agile process. | Agile process work item types and workflow |
| Work in progress (WIP) limit |
Work in progress is work that is started but isn't done or completed. A WIP limit is a constraint that a team applies to one or more workflow stages. The WIP limit helps prevent potential bottlenecks that hinder the continuous flow of work in the system. | Work-in-progress limits |
| Workflow state categories | State categories determine how the board treats each workflow state. The state categories used by the backlogs are Proposed, In Progress, Resolved, and Completed. | Workflow states and state categories |
| Workflow states | Workflow states are defined for each work item type to support tracking the status of a work item, from its creation to its completion. These states define the workflow process: actions, steps, or stages that a piece of work goes through from inception to completion. The State and Reason fields differ depending on the work item type and process selected for the project. | Customize the workflow |
For more information, see the following articles:
Use board controls
Quickly switch from the backlog view to the board view by using the Backlog and Board links. Access other interface features by using the toolbar icons.
The following table describes the available board controls:
| Control | Description |
|---|---|
| Backlog link | Switch to backlog view |
| Board link | Switch to board view |
Filter by icon 
|
Filter by keywords, tags, or fields |
Customize icon 
|
Customize the board and configure team settings: - Cards and Card reordering - Columns, Swimlanes, and Cumulative flow diagrams (CFDs) - Backlogs and Working with bugs on backlogs |
Enter icon 
|
Enter full screen mode |
Exit icon 
|
Exit full screen mode |
Open keyboard shortcuts
To open the board keyboard shortcuts, use the question mark (?). The following image shows a sample of the available shortcuts:
For more information, see Keyboard shortcuts for Azure DevOps and Team Explorer.
Configure and customize your board
Your board is highly configurable to support your team's workflow. Each team can configure each board with the following tasks:
Configure boards
Configure card displays
Along with these team configurations, you can customize your project by adding or modifying work item types, the workflow, and add customized portfolio backlogs and boards.
Note
Each team controls their own team settings and board configurations. You can't define a single board configuration for use by multiple teams.
Update work item status
After you configure your board, you can add work items directly to the board. Update the status of work by dragging a card to another column on the board. You can also change the order of items as you move a card to a new column. For more information, see Workflow states and state categories.
Display leaf node work items
You can create a hierarchy of backlog items, tasks, and bugs. We don't recommend that you create same-category hierarchies. In other words, don't create parent-child links for work items of the same type, such as story-story, bug-bug, or task-task.
The last node in a same-category hierarchy might only appear on boards, sprint backlogs, and Taskboards. For example, if you link items within a same-category hierarchy that's four levels deep, only the items at the fourth level appear on the board, sprint backlog, and Taskboard.
Rather than nest requirements, bugs, and tasks, we recommend that you maintain a flat list. Create parent-child links one level deep between items that belong to a different category. For more information, see Troubleshoot reordering and nesting issues.
Reorder and reparent work items
All backlogs and boards support drag-and-drop to reorder and reparent work items. Updates made to your team's backlogs and boards are reflected in other team backlogs and boards that share the same area path. You might need to refresh the page to see the changes.
You can only use drag-and-drop to reorder or reparent work items assigned to area paths selected for your team. When the Parents view option is enabled, work items might appear on your backlog that your team doesn't own. Any item with the 
information icon can't be reordered or reparented because another team owns the item.
Update columns
Each team can customize the board columns and swimlanes. The values assigned to board fields might differ from what you expect when another team updates the work item from a different board.
Even if the management team and the feature teams configure their board columns with identical workflow mapping, one team's board items aren't reflected on another team's board. Only when the work item moves to a column that maps to a workflow state does the card column display the same information on all boards.
For more information, see Manage columns.
Provide permissions and access
When you're a member the Contributors group for a project, you can use most features available under the Boards or Work options. Users with Basic access have full access to all features. Users with Stakeholder access can use certain features with limited access.
For more information, see Set permissions and access for work tracking and Stakeholder access quick reference. To add users to a project, see Add users to a project or team.
Customize your project and board inheritance
If you require more than three board levels, you can add more levels. For more information, see Customize your backlogs or boards (inheritance process).
You can also add or modify the fields defined for a work item type (WIT), add a custom WIT, or modify the workflow. For more information, see About process customization and inherited processes.