Jean-Paul Bayley — January 22, 2020 
Students and clients ask us “Can Kanban and Scrum work together?” all the time. The answer is an emphatic, “Of course!” However, what do you mean by “Kanban”? If you are talking about Kanban as a strategy for optimizing the flow of value through a process that uses a visual, work-in-progress limited pull system, then The Kanban Guide for Scrum Teams has some clear advice on how we make this happen.
Why bother using Kanban and Scrum together?
The Scrum Guide is particular about roles, events and artifacts, but it does not offer an opinion on some of the aspects of the day to day of being in a Scrum Team. Scrum is silent on how to do estimation, how to figure out how much work to do, how to know how well a sprint is going, how to provide focus and openness. Kanban offers a range of powerful complementary practices to Scrum that can help with all of these things. It’s self-organisation rocket fuel for teams to take their Professional Scrum practice to the next level.
How can Kanban and Scrum work together?
The Guide introduces some Kanban-based complementary practices for The Scrum Framework. What does this mean? Well, it means that we keep the entirety of Scrum as defined in the Scrum Guide and add some Kanban-goodness tell help smooth things. The 4 practices are:
- Visualization of the workflow
- Limiting Work in Progress (WIP)
- Active management of work items in progress
- Inspecting and adapting the team’s definition of “Workflow”
At the heart of this is the Scrum Team’s definition of their “Workflow”. The workflow describes the Scrum Team’s shared understanding of how they follow the Kanban practices. It may also go beyond the Sprint and the Sprint Backlog too. Whilst the whole Scrum Team is accountable for the definition of Workflow, the Development Team defines the parts of the workflow that relate to the activities of the Development Team. So, in the same way as no-one can tell the Development Team how to go about delivering the work in the Sprint Backlog, no-one can tell the Development Team what their workflow is for doing the work in the Sprint Backlog. The Scrum Guide still applies.
Metrics
Further to these practices, Kanban and Scrum can work together with metrics. The most powerful of these in my opinion are the metrics that are now available to the Scrum Team. Because we define when our work “starts” and when we consider it “finished”, we are able to record the date work began and the date work finished. These 3 pieces of information are incredibly powerful – take a look at my colleague José’s talk on metrics. Simply put, we can calculate the Cycle Time [(date finished – date started) +1], our Throughput (how many items completed per day), and the Age of a Work Item [(today – date started) +1] by capturing these data.
Cycle Time
Cycle Time allows us to provide a forecast of when we will deliver a single item of work expressed as a level of confidence (chance) and a time range. For example, 85% chance of 8 days or sooner. We refer to this as a Service Level Expectation (SLE). We can use this to answer whether an item is good to go into a Sprint Backlog – if we think it is of the right size for us to complete within the SLE, then we can have a level of confidence that we can get the work done. This reduces our estimation effort when working with Kanban and Scrum.
Throughput
With throughtput, we can answer questions such as “When will it be done?” and “How much stuff will I get by when?” with Monte Carlo forecasting. We can use this in Sprint Planning to decide out how many items we should put in our Sprint Backlog. The difference with the commonly used Story Points and Velocity (neither of which are in the Scrum Guide, by the way), is that we are using raw data. We don’t need relative estimates of complexity or such like, with the issues that we see reported about that. In our experience, Kanban and Scrum together speeds up Sprint Planning significantly!
Monte Carlo forecasting is also helpful for the Sprint Review – it informs the Product Owner’s discussions about delivery dates.
Work Item Age
One of the most empowering shifts that we observe with our clients is the use of Work Item Age to manage the flow of their work. It doesn’t matter if they are using Scrum with Kanban or if they are applying the Kanban Method, the impact of Work Item Age metrics is profound. If we augment this with Work Item Aging trends, then we are really cooking with gas. We are no longer forecasting, we are nowcasting – what is happening to our work right now. It is our only leading metric. I don’t think I can over-express how powerful this is. At our Daily Scrum, we can use this to decide what we should be working on as a team – it’s a key part of the active management of work items in progress. Metric-driven focus… how amazing is that?!?
Business & Finance Articles on Business 2 Community
(37)
