Kanban Practices for Scrum Teams
Scrum is purposefully incomplete. The effectiveness of Scrum evolves over time when you use it as a container for other practices to make it efficient for your context. For instance, XP practices are a perfect fit for the Scrum process to incrementally and iteratively deliver a done Increment each Sprint.
“Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.” Scrum Guide
Why Kanban practices are also a good fit for Scrum?
First looking at Scrum and Kanban definitions, both have the same end-goal to deliver value in order to achieve business agility.
“Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems”. Scrum Guide
“Kanban is a strategy for optimizing the flow of value through a process that uses a visual, work-in-progress limited pull system”. The Kanban Guide for Scrum Teams
To achieve business agility, Scrum and Kanban have different, yet complementary focus areas:
- Scrum is founded on empiricism to deal with complexity through the frequency of the transparency, inspection, and adaptation cycle.
- Kanban is founded on the concept of flow to improve the overall efficiency, effectiveness, and predictability of a process.
“Scrum is based on Empiricism and Kanban is based on Flow. Flow enhances Empiricism and Empiricism enhances Flow” Daniel Vacanti — The Agile Wire podcast .
In the context of Scrum, flow is the movement of the Product Backlog items towards customer validation (feedback loop). At the Sprint level, flow could be seen as how value work items (e.g user stories) flow from “in-progress” to “done” states.
To put it in simple words, Kanban practices will help you optimize your flow of work during the Sprint to get earlier feedback and validate your assumptions throughout the Sprint.
They will allow you to create a pull system so that the team frequently has a Done Increment available for its users throughout the Sprint. If you have a 2-weeks Sprint, and a work item is sized to be completed in 5 days or less, then you shouldn’t be waiting until the end of the Sprint to validate that work item! It’s a common misconception that teams can only deliver value once per Sprint.
Good Scrum Teams already have a good understanding of the importance of flow within the Sprint. Good Scrum Teams don’t start all work items from the first day and hope to have all of them done by the last day of the Sprint.
At this stage, you should have a strong understanding of “why” Kanban practices are a good fit for Scrum! Remember, it’s about the flow optimization through the feedback loop — which can also be described as optimizing the Cycle Time through the feedback loop.
Let us now explore “how” Kanban practices can positively impact your Scrum Team.
Definitions of key Kanban concepts:
- Cycle time is the elapsed time* (including nights!) between the moment a work item starts and the moment it finishes.
- Work In Progress refers to the number of work items started but not yet finished.
- Throughput is the number of work items finished per unit of time (day, week, or Sprint).
*elapsed time is what speaks to our customers compared to working days. Elapsed time is different from working days as it includes waiting time, nights, holidays and weekends!
What is key to governing flow?
Flow is mainly measured by Cycle Time. Cycle Time, Work in Progress (WIP), and Throughput are intrinsically linked by a very straightforward and powerful relationship known as Little’s Law:
Average Cycle Time = Average Work In Progress / Average Throughput
“The fundamental result of Little’s Law is that for a given process, in general, the more things that you work on at any given time (WIP on average) the longer it is going to take for each of those things to finish (Cycle Time on average)”. Little’s Law for Professional Scrum with Kanban
Despite this straightforward understanding, managers tend to increase the number of work in progress (WIP) expecting faster delivery!
Now, keeping Little’s Law in mind, you should realize if you want to shorten the Cycle time you need to work on fewer items at the same time (lower WIP).
What are the 4 Kanban practices to achieve flow optimization?
Scrum Teams can optimize their workflow by adding four Kanban practices:
- Visualizing the Sprint Backlog workflow on a Kanban board (Figure 5 below)
- Limiting Work in Progress (WIP)
- Actively managing work items in progress
- Continually inspecting and adapting the way the team uses flow optimization
The visualization example above helps the Scrum Team make transparent:
- Workflow properties (pink items): explicit policies, work item definitions, WIP limit policies, start and end of workflow, and Definition of Done
- Kanban metrics (purple items): work item age, work in progress, throughput, and Cycle time (with Service Level Expectation SLE)
In addition to visualizing the workflow via a board and adding columns to make the workflow stages visible, explicitly limiting Work In Progress (WIP) is a mandatory practice. Limiting WIP could be done in a single column, several grouped columns/lanes/areas, or a whole board.
Limiting WIP in the “start” column of your workflow will help you create a pull system. The value of that limit (arrival rate) shouldn’t be exceeding your throughput (departure rate) so that you can have a stable and optimized flow. Optimized flow for more efficiency. Stable flow for more predictability.
Limiting WIP alone is not enough, the Scrum Team members must actively manage work items in progress by setting explicit policies (example in Figure 5) about how work items can flow through their workflow. The expected result is a collective focus on eliminating waste (waiting time between activities and handover). Actively managing work items could be achieved by monitoring work items age metric on a daily basis (for more info, see the “work item age” section).
Limiting WIP is meant to have an impact on your development process and to help you optimise the flow of work. For instance, DEVOPS practices of continuous integration and continuous delivery (CI/CD) underpin your ability to limit your WIP (thanks to automation). If your current WIP limit doesn’t create such an impact then you have to lower it.
To enable these Kanban practices, your team needs to inspect and adapt its workflow by:
- Defining when work items are started and finished within the Sprint (Cycle time will be measured between the start and finish stages of your Sprint).
- Defining the stages between start and finish (board columns and activities performed within these columns/stages)
- Aligning on how work items can flow through each stage (pull policies between stages and Definition of Done).
- Agreeing on policies for limiting Work in Progress (WIP).
The 4 Kanban practices are simple to understand but require joint discipline and efforts from all team members to reinforce collective focus, commitment, and collaboration resulting in flow optimization.
How can you reap the benefits of Kanban practices through the 4 flow metrics?
I’m a strong believer in the statement :
“If you can’t measure it, you can’t improve it” — Peter Drucker.
Kanban comes with 4 key flow metrics as a way to measure and optimize the benefits of the practices over time, grouped into 2 pairs.
- Every completed item counts towards Throughput and has a Cycle Time,
- Every item still in progress counts towards WIP and has a Work Item Age.
The four metrics are interconnected by the above-mentioned Little’s law.
1. Work In Progress : the number of work items started but not finished.
It could be measured for a single column, several grouped columns/lanes/areas, or a whole board.
Actively measuring the amount of work in progress will allow you to:
- create a pull system (Scrum is a pull system — Sprint Backlog limits WIP to capacity),
- have a system stability for higher predictability and efficiency of your Sprint,
- improve collective focus, commitment, and collaboration (team performance rather than individual performance).
It creates a pull system because the team owns the decision to start work (i.e. pulls) on an item only when it is clear that it has the capacity to do so. Teams should pull to fulfil WIP limits. The limits are the team’s capacity to do work and should be honoured.
Limiting your WIP is about setting upper and lower bounds. The WIP limits frame the capacity of your team within the Sprint, therefore you should operate as close as possible to these limits throughout the Sprint. Flow is all about efficient, effective, and predictable value delivery. Efficiency is a big part of it!
The numbers of WIP are not what’s important but how lowering your WIP could lead to improving flow.
Finding the suitable WIP limit is an experimental and iterative process. Help your team find its suitable WIP limits by monitoring your WIP trends in relation to Cycle Time and Throughput.
2. Throughput: the number of work items finished — or Done, in Scrum parlance — per unit of time (day, week, or Sprint).
Looking at the throughput metric trends will allow you to assess the consistency of your value delivery over time.
Consistency of throughput and comparing it to the rate at which you start work, will help you to assess the stability of your Sprint (remember Little’s law).
Having a reliable throughput metric will allow you to forecast:
- Your next Sprint by looking at the average (screenshot above).
- Your next release using Monte Carlo simulation to answer the questions “how many” features or “by when”. Monte Carlo forecast is more accurate than using averages.
In relation to time and capacity, throughput gives an additional perspective compared to Story Points and Velocity. Here is a simple analogy to understand the difference: at the toll booth, you can measure the number of cars (throughput) or their weight (story points).
Throughput metric could be used as an alternative to velocity to help the Scrum Team forecast the amount of work for their next Sprint.
3. Cycle time: the amount of elapsed time (including nights!) between when a work item starts and when it finishes.
Looking at the Cycle Time Scatterplot helps us see how predictable we are. More predictable teams see more condensed dot patterns than less predictable teams.
Shortening Cycle Time will help you get earlier feedback and help your business validate their assumptions as soon as possible.
By looking at the cycle time of each work item you can define your Service Level of Expectation (SLE). It is the expectation in terms of how long a single item should flow through your Sprint within an agreed confidence level (e.g. 85% of our items finish in 8 days or less). The SLE will help you:
- trigger the slicing of big items, during refinement or Sprint Planning (before pulling them into your Sprint).
- Answer how much ageing is too much (when an item is taking too long to complete).
SLE is a good alternative to estimation (transition to no-estimate):
- Focus changes from exact size to “Is it small enough to fit in a Sprint?”
- Team asks “Do we think we can finish this item within our SLE?”
- If the answer is no, then the Team works to break down the item so it can be.
4. Work item age : it’s the amount of time between the moment a work item started, and now.
Work item age is the easiest metric and the one you should start tracking. The older an item is, the older it is likely to become! Indeed, the longer a work item takes to finish, the more chances it will have to not get done (absences, server down, multi-tasking, priority conflict, dependency with other teams, etc.).
Work item age is directly linked to perceived fluidity as you will be lowering the inactive time of each item (thereby eliminating waste).
Work item age is a leading indicator (compared to Cycle time and Throughput as lagging indicators).
Work item age should be monitored by the team on a daily basis, ideally at the Daily Scrum, to:
- spot earlier signs of an item not flowing as expected,
- call for a new decision (pro-active process improvements),
- prompt the team to get together (swarming) to solve what slows down their Sprint flow; or in simple terms — just ask for help, and provide help, on that item.
The 4 Kanban metrics serve as alerts so that you can proactively deal with flow issues rather than retroactively fight fires.
Flow metrics should be inspected during Scrum events to trigger improvements and start the right conversation about optimizing flow.
How to get started
1. Run a workshop to help your team align on their workflow and explicit policies to actively manage WIP. In a white board:
- Draw your team’s current workflow (columns with workflow stages),
- Invite your team members to add sticky notes to explicit activities required for each column (exit policy),
- Together agree on WIP limits (per column is an easy way to start)
In the screenshot below, we visualize the workflow inside (yellow colour) and outside (purple colour) of the Sprint.
2. Drive change with the Ageing WIP chart to:
- Monitor work items ageing daily,
- Trigger decisions using “age” to impact Cycle Time and SLE.
3. Inspect the Cycle Time Scatterplot chart to:
- Get a sense of your predictability,
- Determine your SLE.
Takeaways:
- “Scrum and..” — the flow-based perspective of Kanban can enhance and complement the Scrum framework and its implementation.
- Focusing on flow and reducing batch size is a way to improve your delivery of value and gather feedback faster to validate your assumptions.
- The 4 core Kanban practices and 4 key flow metrics can help you focus on understanding and improving the flow of work.
- Optimizing the flow of work increases team performance by improving collective commitment, focus and collaboration.
- Adding Kanban practices enables you to reflect on your Sprint’s health and performance and will help inform decisions about how value gets delivered.
Closing:
Kanban practices help the Scrum Team to self-manage and deliver increments of value in a sustainable way. Value delivery happens throughout the Sprint, leaving out the myth that we can deliver only at the end of the Sprint.
Kanban practices can be used to help Scrum Teams solve some core flow issues as well as help more advanced teams evolve towards a DevOps-like continuous integration/deployment flow in a structured way.
Kanban practices could be also helpful to teams that are new to Scrum by making the Sprint Planning as light-weight as possible. The Scrum Team crafts a Sprint Goal and do just in time planning in a regular cadence to honour their WIP limits and move towards a pull-system.
Kanban practices take its roots in lean thinking and therefore help the Scrum Team reduce waste.
Flow metrics will trigger the right flow-related questions in the different Scrum events.
Sources:
- Scrum Guides: https://scrumguides.org/scrum-guide.html
- The Kanban Guide for Scrum Teams: https://scrumorg-website-prod.s3.amazonaws.com/drupal/2021-01/01-2021%20Kanban%20Guide.pd
- Little’s Law for Professional Scrum with Kanban https://scrumorg-website-prod.s3.amazonaws.com/drupal/2018-05/Little%E2%80%99s%20Law%20for%20Professional%20Scrum%20with%20Kanban.pdf
- Fixing your Kanban videos playlist https://youtu.be/Jmi83OnmrtA
- The Agile Wire: Talking Flow with Daniel Vacanti https://www.scrum.org/resources/agile-wire-talking-flow-daniel-vacanti
- Actionable Agile Metrics for Predictability https://www.amazon.fr/Actionable-Agile-Metrics-Predictability-Introduction/dp/098643633X
