If you are eager to learn more about how Azure DevOps Kanban boards work and see what else can be done to make them better. This is the right post to read. Let’s dive in.
First of all, Azure DevOps as an application lifecycle management system has Kanban boards as one of the native ways to display work items. You can choose whether you view items via backlog/list style interface or you visualize work items on the Kanban board.
One of the most complicated things in Azure DevOps Kanban boards is that they use two new, Kanban-only specific structure building blocks. Below you can see an example of a somewhat standard Kanban board that contains both Board columns and swimlanes. Let us explain each one separately.
Each board column represents a separate Kanban flow step. Surprisingly those are not the same as the work item field state. But they are mapped and you can customize that mapping to fine-tune which Board column matches which Work item State. So, once you move the item from ‘New’ to ‘Active’ board column, its underlying state will change.
Swimlanes are those splitter rows on the board. They span through ‘In progress’ type columns. Swimlanes are excluding New and Closed columns. This is not configurable and you can only add more “in progress” type columns for swimlanes. You also cannot have different board columns per swimlane. In our above board example, we have a default swimlane and a red one called “expedite”. This special state is reserved for the most urgent/important work items to be pulled through the workflow as the top priority.
In Azure DevOps, each board belongs to a team, and each team is mapped to a project area. You can have as many of those as you want. If you split boards by team or some other aspect, for example, function – development, design, support. It is purely up to you. But by default, boards are envisioned split by teams.
The board structure is quite a specific thing, and each team can have quite a different one based on their line of work, size, and industry. Yet we believe that starting simple is always better, so you should try working your way up from the default templates offered by Azure DevOps Kanban boards. You can start without swimlanes as well.
Once you get going, you might want to start introducing new board columns and swimlanes to provide better structure and documentation for your team workflow. A good rule of thumb is the priority column on what to do next and QA/testing column for quality management. You can build quite extensive boards but we must emphasize that they will become quite inconvenient due to design decisions in Azure DevOps.
Customizing Kanban Cards
You can customize Kanban cards by enabling additional fields to be shown right on the card. What we disliked the most is that you need to expand each card to view those additional fields.
The good thing is that you can customize cards by their work item type. Good flexibility point.
You can also turn on Queue or “Done” column splits for every Board column on the board which is of type ‘In progress’. In essence that means you are able to park work items once the actual work happened. This becomes quite useful when measuring queue times and workflow efficiency. Unfortunately, these metrics are not yet developed or available in Azure DevOps.
As a Kanban practitioner, you will definitely want to set up some column limits to reduce multitasking and increase workflow throughput. Each “in progress” type column can have a custom limit set.
For a more detailed guide on how and what you can configure, read this Azure DevOps Kanban guide.
Displaying different work item types on the same board
That is the biggest downside/limitation according to our experience. You need to switch between work item types on the top filter panel and you cannot simply have all work items in a flat manner. This is quite an impediment when the team needs to visualize all work equally.
Based on our experience and common topics in the support section for Azure DevOps Kanban, we have handpicked the most popular pieces of advice that can make your work easier.
To tackle the majority of issues and inconveniences mentioned throughout this post we propose trying Teamhood as a frontend on top of Azure DevOps. Teamhood is a specialized Kanban System that is updated every two weeks and brings a modern approach to lightweight team collaboration. You will be able to define flexible board structure, customize field mapping and leverage integrated Teamhood features for a full work lifecycle management. Our vision is that Teamhood works as a front-end facing interface and Azure DevOps takes the work item database role.
Teamhood – a fully integrated project environment for complex knowledge workers.
✅ Native two-way synchronization with Azure DevOps
✅ Fully featured Kanban System with best-in-class UX
✅ Native time tracker
✅ Native workload management
✅ Wiki pages
✅ Gantt charts and List views
✅ Easy dependency and work item relation management