Kanban: Board Deep Dive
Going Through Some Kanban Notions Applied
Hey, fellow Leader 🚀,
I am Artur and welcome to my weekly newsletter. I am focusing on topics like Project Management, Innovation, Leadership, and a bit of Entrepreneurship. I am always open to suggestions for new topics. Feel free to reach out to me and share my newsletter if it helps you in any way.
As you may have noticed by now, I am a strong adopter of Kanban. This is simply because it's easier to adapt to a multitude of teams and companies. Don’t get me wrong, Scrum still has its place, especially in small to medium companies where product development is core. However, once a company becomes more structured and less like a startup, the cracks in Scrum start to appear. This isn't the fault of the methodology. It's simply because it's often misused and applied in contexts it's not designed for. Another misconception is that Kanban is only for BAU (Business-As-Usual) tasks or operational methods. This highlights Kanban’s potential to grow and, like its brother Scrum, start to be misused.
The key tool for Kanban is the board, and the image below provides some interesting concepts to ease comprehension. There are two fundamental notions of the Kanban board: Downstream and Upstream. Imagine a river where Product Teams work intensively to bring new features to the product, and a series of analyses and discussions take place. It's like fighting a river upstream to make things happen. The discovery part (where the backlog is worked and refined) is done on an Upstream board. Once a ticket is presented to Development teams and commitments are made, it goes down the river to arrive at the Production ocean. This is the most well-known aspect of Kanban. The majority of resources we see online focus on Downstream Kanban boards. Today’s article focuses on the Downstream flow and the most popular part of Kanban: the board.
The Board
The Kanban board is highly personalized for the team, and the goal is to reflect the actual work the team does and its actual workflow. The workflow itself is a different conversation, which I will try not to delve into too much here. Defining the workflow is the number one challenge in Kanban transformations and is by far the most complex topic to handle (it needs its own dedicated article). For now, let’s focus on the board itself and some key notions about it.
The Backlog in the image above, also named “Selected To Start”, is where the Product Owner and the Development team add the tickets the team will work on in the near future. Sorting these tickets is typically done by the Product Owner or the team member responsible for prioritizing the team's work. Tickets in this column don’t count toward any metrics, as there's no commitment from the team yet. The team's commitment to address a ticket comes during one of Kanban’s signature ceremonies: Replenishment.
The Replenishment
Replenishment is a meeting that should take no more than 5 minutes per ticket, where the ticket creator asks the team to review and approve it. This ticket can be created by the Product Owner, the Business Analyst, or any non-technical role within the team, but they can also be technical tickets created by the developers themselves. The goal of replenishment is to get the team's commitment that the ticket will be managed and worked on, and that its content and goal are clear to everyone. This means that even if the ticket is clearly assigned to a specific developer, if that developer goes on vacation for 3 months, any other developer could pick it up and finish it. This notion is crucial because once a ticket is replenished, the team promises it will move through the workflow as fast as possible. In order to fulfill this promise, there are a set of conditions the ticket needs to meet:
No roadblocks ahead: This means if the ticket is replenished, the developer won't get blocked after two days of work, waiting for someone or something. If there is a potential roadblock, it should be addressed before replenishment.
Clear content and objectives: Typically, this is ensured by meeting the 'Definition of Ready' (conditions guaranteeing the ticket is ready to be worked on), 'Definition of Done' (conditions stating when the ticket is considered complete), and 'Acceptance Criteria' (conditions detailing how to assess if requirements are met).
Other team-specific conditions met: This includes things like completed estimations, finished documentation, received testing files, or any other workflow-related prerequisites defined by the team. These conditions are case-by-case and relate to the rules each team has defined for its workflow.
The reason why the replenishment in the picture above has a bride and a ring illustrates that it's a moment of marriage, or commitment, between the team and its stakeholders. Once the ticket is replenished, the team commits to doing everything in its power to push the ticket forward. For that reason, it's important that the team understands the ticket's purpose and that all team rules are respected.
Classes of Services
Another trademark of Kanban is its Classes of Service. This is fancy wording for the swimlanes we typically see on team JIRA boards. If the board is well-designed, the team’s priorities are reflected by a simple rule: Anything further to the right on the board has higher priority than tickets to its left. This means a ticket in an advanced stage (e.g., testing) has higher priority than one that was just replenished. The mindset is to push tickets off the board as fast as possible. However, this rule is only half the story, because it's complemented by the rule that tickets higher up on the board have higher priority than tickets lower down. This introduces the concept of Classes of Service (often represented as swimlanes in tools like Jira).
One mandatory Class of Service I try to introduce is 'Expedite'. This is usually the top swimlane on the board. This swimlane is specifically for high-priority tickets, like a critical feature needed for an event, or something broken that needs fixing ASAP. It's the swimlane where the team puts on its firefighter hat and addresses the issue as fast as possible. Because tickets in this lane are in the highest position, they have the highest priority overall.
Other Classes of Service are typically customized for each team. These might represent feature sets for a specific software area, a new project, or other task groupings. Once these Classes of Service are identified and created on the board, it's up to the Product Owner (or whoever is responsible for team priorities) to organize the board, placing the highest priority swimlanes at the top and lower priorities at the bottom.
When the team matures, the Product Owner can sort tickets in 'Selected to Start' (the Backlog) by their linked Class of Service, and go on holiday for three weeks, and the team can autonomously pick up new tickets and address priorities without needing anyone to arbitrate. The priorities are reflected on the board.
The Daily Kanban
One of the biggest differences between Scrum and Kanban is how the daily meeting is organized. The Kanban daily focuses on the board, and the team discusses the status of items, column by column or ticket by ticket. The goal is to quickly identify and address bottlenecks. Keep in mind that the daily Kanban meeting should only take about 10 minutes. Therefore, any discussion extending beyond this timeframe should be handled ad hoc with only the necessary people involved.
The daily Kanban typically follows the board's priority structure: The team starts top-to-bottom, right-to-left, addressing higher-priority tickets first and moving toward lower-priority ones.
During the daily Kanban, everyone should provide a short and clear status on the ticket, aiming for less than a minute per ticket. It is normal to have the conversation go more than these 60 seconds of fame for some tickets, but it should be the exception and not the norm.
This differs greatly from the Scrum daily, since in Scrum the developer is the highlight and states how the work progressed from the previous day, whereas in Kanban, the board dictates the flow of the daily, ticket by ticket, and how the ticket can progress off the board.
The Metrics
Kanban metrics are a very interesting topic deserving of their own dedicated article. However, let’s cover the basics: Throughput and Lead Time. Both of these metrics focus on the time tickets spend on the board. The Kanban mentality is that once a ticket is added to the board, the goal is to get it off as fast as possible. Therefore, the main metrics in Kanban reflect this focus.
Throughput represents the amount of work (e.g., number of tickets) the team delivers over a specific period. The keyword is delivered. The goal is to understand how much work the team delivers, not just how much is in progress. This differs from Scrum's Velocity, which focuses on effort (like story points or effort days). Throughput is literally the number of deliverables (e.g., tickets) the team produces in a given period (e.g., a week, a month, etc.).
Lead Time is another key metric, measuring the total time a ticket spends on the board. This clock starts at the commitment point (Replenishment) and stops when the item is delivered. Various analyses can be done here, looking at the current lead time, the rolling average, and trends over weeks.
The main point is to analyze these metrics with the team during retrospectives, where the team can review metrics per Class of Service and decide on actions for improvement or discuss the reasons behind the numbers. They can also discuss whether they're satisfied with the current performance for a specific Class of Service. The goal is to have factual conversations based on these metrics, discussing how the team perceives and addresses them.
That’s it. If you find this post useful, please share it with your friends or colleagues who might be interested in this topic. If you would like to see a different angle, suggest it in the comments or send me a message.
Cheers,
Artur