A kanban board is an agile project management tool designed to help visualize work, limit work-in-progress, and maximize efficiency (or flow). It can help both agile and DevOps teams establish order in their daily work. Kanban boards use cards, columns, and continuous improvement to help technology and service teams commit to the right amount of work, and get it done!
Kanban has come a long way from its origins in lean manufacturing thanks to a small but mighty group of kanban enthusiasts. David Anderson’s work defining the kanban method helped bring kanban into the software and services space, and Personal Kanban, by Jim Benson and Tonianne DeMaria, helped expand the applications of kanban to places you wouldn’t believe.
I use kanban boards every day and couldn’t imagine life without them. The ideas and best practices here are a peppering of my personal experiences, research, and conversations I had with with Zach Nies, Keith Nottinson, and Jim Benson.
What keeps me coming back to kanban are the kanban values and (surprising) lack of rules. The kanban values are respect for people and continuous improvement.
David Anderson established that kanban boards can be broken down into five components: Visual signals, columns, work-in-progress limits, a commitment point, and a delivery point.
Visual Signals — One of the first things you’ll notice about a kanban board are the visual cards (stickies, tickets, or otherwise). Kanban teams write all of their projects and work items onto cards, usually one per card. For agile teams, each card could encapsulate one user story. Once on the board, these visual signals help teammates and stakeholders quickly understand what the team is working on.
Columns — Another hallmark of the kanban board are the columns. Each column represents a specific activity that together compose a “workflow”. Cards flow through the workflow until completion. Workflows can be as simple as “To Do,” “In Progress,” “Complete,” or much more complex.
Work In Progress (WIP) Limits — WIP limits are the maximum number of cards that can be in one column at any given time. A column with a WIP limit of three cannot have more than three cards in it. When the column is “maxed-out” the team needs to swarm on those cards and move them forward before new cards can move into that stage of the workflow. These WIP limits are critical for exposing bottlenecks in the workflow and maximizing flow. WIP limits give you an early warning sign that you committed to too much work.
Commitment point — Kanban teams often have a backlog for their board. This is where customers and teammates put ideas for projects that the team can pick up when they are ready. The commitment point is the moment when an idea is picked up by the team and work starts on the project.
Delivery point — The delivery point is the end of a kanban team’s workflow. For most teams, the delivery point is when the product or service is in the hands of the customer. The team’s goal is to take cards from the commitment point to the delivery point as fast as possible. The elapsed time between the two is the called Lead Time. Kanban teams are continuously improving to decrease their lead time as much as possible.
A kanban board with these five elements will undoubtedly set your team up for success. But now, I’ll present an opposing point of view.
Jim Benson says that kanban only has two rules: Limit work in progress and visualize your work. If you start with just those rules and apply them to your work, your kanban board will look much different than the one described above. And thats ok! Jim advocates for starting with just these two rules because, he says, “The more rules you add, the less contexts it fits into.”
Kanban can be adapted to many environments, from manufacturing to human resources, to agile and DevOps software development. The type of environment adapting kanban often dictates if the board is physical or digital. In my research, I discovered a $58 million dollar construction job managed with a physical board in a trailer and I spoke to many, many software teams using digital kanban boards.
The simplest kanban boards are physical boards divided into vertical columns. Teams mark up a whiteboard or blackboard and place sticky notes onto the board. These sticky notes move through the workflow and demonstrate progress.
One advantage of a physical board is that it’s “always on.” You can’t open a new tab on a giant rolling whiteboard sitting right by your desk. It’s simple to set up, simple to show others, and is often times the better way to communicate with certain teams. However, physical boards are not ideal for remote teams or people with terrible handwriting, like me.
Optimizely makes software to help companies learn what variants of a web page or product users like best. They use Jira to track work items large and small, but Keith Nottonson, Senior Director of Development, saw a gap.
Individual teams were humming in Jira, but they weren’t talking to each other. To get everyone on the same page, Keith erected a massive physical kanban board called “the wall of work.”
Their board has every project the engineering team is working on, with metrics, team members, and status on display for all. While this was helpful for understanding their whole portfolio of work, an even more interesting value began to play out.
“At first, the wall was just “to-do” “doing,” and “done,” but over time people began having conversations about how we work,” Keith said. Keith went on to share that thanks to those conversations, the wall grew and evolved and in a matter of weeks, Optimizely had a clearer picture of how work gets done than ever before.
Optimizely’s board is especially great because it has a commitment and delivery point. Once a project is defined and meets certain criteria, an engineering team will pick up the project and commit to getting it done. At this point, the project goes in Jira so they can capture all the juicy data and interactions involved in the final delivery.
Keith recommends that teams start with a physical kanban board as those early conversations will lead to rapid iterations of the workflow and board.
As the kanban system gained favor with software and engineering teams, kanban boards underwent a digital transformation. Digital boards allow teams that do not share a physical office space to use kanban boards remotely and asynchronously.
Trello is a fast and simple way to make a digital kanban board. The setup involves just a few clicks to create digital lists, which represent the stages of your kanban process, on a board view that your whole team can access and manage.
For example, you might create lists for “Backlog,” “Up Next,” “In Progress,” and “Done!” Each task is organized as a card, which you move across the lists as they are queued up, worked on, and completed.
The advantages of a digital kanban board like this are the speed to set it up, the ease in sharing it with others, and the ability to asynchronously track an infinite number of conversations and comments as the project progresses. No matter where or when team members check in on the kanban board, they’ll see the most up-to-date status of the project. Plus, you can even use a Trello kanban workflow for your personal to-dos, like this sample board shows.
Some digital kanban boards are simple, and some are more robust and customizable. Teams that require additional functionality like WIP Limits and Control Charts should opt for a more powerful tool like Jira Software. Jira comes out of the box with a kanban project template that makes getting a kanban team up and running a breeze. The team can jump into the project and then customize their workflow and board, place WIP limits, create swimlanes, and even turn on a backlog if they need a better way to prioritize.
The difference between kanban and scrum is actually quite subtle. By most interpretations, scrum teams use a kanban board, just with scrum processes, artifacts, and roles along with it. There are, however, some key differences.
Scrum sprints have start and stop dates whereas kanban is an ongoing process.
Team roles are clearly defined in scrum (product owner, dev team, and scrum master), while kanban has no formal roles. Both teams are self-organized.
A kanban board is used throughout the lifecycle of a project whereas a scrum board is cleared and recycled after each sprint.
A scrum board has a set number of tasks and strict deadline to complete them.
Kanban boards are more flexible with regards to tasks and timing. Tasks can be reprioritized, reassigned, or updated as needed.
Both kanban and scrum are popular agile frameworks with software developers. For more on this, read our full breakdown of kanban vs. scrum.
Kanban is a “start with what you do now” method. That means you don’t have to uproot what you’re doing to get started with kanban. The kanban method assumes three things:
You understand current processes, as they are actually practiced, and respect current roles, responsibilities, and job titles.
You agree to pursue continuous improvement through evolutionary change.
You encourage acts of leadership at every level - from individual contributors to senior management.
This is a team process, so the first thing your team should do is get together! You’ll want to try and break your work into the distinct activities that compose the workflow (columns). From there, you can figure how and when new work(cards) get added to the board. Will you have a service desk where customers submit ideas or will the team set up a meeting to write down and post their cards?
You’ll also want to decide the size and scope of one card. Try and find a time estimate or complexity estimate that will be uniform across all the cards. If something is too meaty or challenging, try to break it up into multiple cards.
Once you decide on a commitment point and delivery point you’re ready to get to work. As time progresses, rely on your team to critique and improve the process. Remember that kanban calls for acts of leadership at all levels on an ongoing basis, a concept called Kaisen. With the kanban values of respect for people and continuous improvement in mind, you’ll be up to speed in no time.
Max Rehkopf
As a self-proclaimed “chaos muppet” I look to agile practices and lean principles to bring order to my everyday. It’s a joy of mine to share these lessons with others through the many articles, talks, and videos I make for Atlassian