Scrum + Kanban = Scrum enhanced

For some years I have been using, and teaching, the use of Kanban as a way to improve the way teams operate in a variety of business contexts and situations.

When I joined the XSCALE Alliance back in 2016 I was introduced to the idea of “Scrumban” or “Scrum + Kanban”, and learned that the Kanban focus on transparency and “flow” can enhance and complement the Scrum framework and its implementation.

Since then I have been coaching teams to integrate Kanban practices into their agile (and Scrum) implementations and have seen many teams benefit greatly from this combination. I also began recommending Scrumban as a better framework for both new and existing teams.

More recently, Scrum.org has launched “The Kanban Guide for Scrum Teams”, in which they have laid out some of the ways Kanban can be integrated with Scrum practices.

My aim in this article is to introduce some key concepts regarding the use of Kanban with Scrum which, I hope, will encourage you to learn more and to experiment with adopting Kanban practices as part of your own agile toolkit.

Kanban is a strategy for optimizing the flow of stakeholder value through a process that uses a visual, work-in-progress limited, pull based system.

Central to the definition of Kanban is the concept of “flow.” Flow is the movement of customer value throughout the product development system. Kanban optimizes flow by improving the overall efficiency, effectiveness, and predictability of a process.

I have described Kanban in more detail here and I would recommend reading up on more details regarding the Kanban framework. You may also wish to read The Kanban Guide for Scrum Teams (Scrum.org and Daniel Vacanti).

Kanban with Scrum

Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known.

My recommendations for combining Kanban with Scrum also come from direct experience, along that of many other agile professionals. We have adopted these practices based on learning through doing, and through helping others improve their own processes.

Scrum defines the Sprint Backlogas being the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.

However, the Scrum Guide provides limited guidance as to how this planning is to be done and how the Sprint Backlog is to be made visible. Development teams often find themselves with too much, or too little, work in the Sprint Backlog. Within the duration of the Sprint, visibility external to the Development team can be limited, which limits opportunities for inspection of progress or adaption of work being delivered. Furthermore, changes to priorities in the Product Backlog can’t be easily reconciled with work being done as part of the current Sprint.

The Kanban framework contains a set of Core Practices which can be applied by a Scrum team to help address these challenges and improve visibility and maximise flow:

1. Visualize the work/workflow
2. Limit WIP (Work in Process)
3. Manage Flow
4. Make Process Explicit
5. Implement Feedback Loops
6. Improve Collaboratively, Evolve Experimentally

Let’s look at what these mean when applied in combination with Scrum:

1.    Visualize (the work, workflow, and risks to flow/value delivery)

A Scrum board is a great way to create transparency regarding work in progress throughout a Sprint. I recommend tracking product Backlog Items (PBIs) rather than tasks, as this gives better visibility of the “flow of value” as opposed to tracking individual tasks.

Everyone, including the Development team and the product Owner, can see the stage at which Backlog items are at and can immediately see when items are completed (moved to “Done”). As well as creating a sense of achievement, these “Done” items can be inspected and feedback received as they are completed, rather than waiting for the Sprint Review.

It’s also clearer where bottlenecks are showing up and which items may not get completed this Sprint.

2.    Limit WIP (Work in Progress)

Work in Progress (WIP) = The number of work items started but not finished (according to the Scrum Team’s definition of “Workflow”).

The purpose of a Work in Progress (WIP) LIMIT, is to help the team reduce the amount of WIP and ultimately to improve the flow of work and reduce the amount of incomplete (unfinished) work each Sprint.

This is usually implemented by the Development team agreeing a constraint on the number of PBIs which can be in a given stage (column) at one time. Note that aWIP Limit can include work items in a single column, several columns, or a whole board.

Once the limit is reached in one stage, instead of starting a new PBI, members of the development team help others deal with the current PBIs already in progress. This helps to encourage teamwork and improves the rate of work being delivered (completed).

Note that this differs from the traditional “up front” planning nature of Scrum’s sprints. Instead, the team “pulls” work from the backlog when they have capacity, based on the current priorities in the Backlog.

Optimizing WIP limits can increase productivity. A lower WIP limit can increase focus (and reduce multitasking) which can result in higher productivity.

3.    Manage Flow (Active management of work items in progress)

In my previous article on Kanban, I described various flow metrics which are used to help monitor and manage the flow or work.

The Daily Scrum can be used as a way to monitor progress and the Kanban flow metrics help to focus attention on areas which require attention. The Cycle time of PBIs indicates the amount of time that has passed as an item on the Kanban board moves between stages and can be used to identify bottlenecks.

Using these Kanban metrics as part of the Daily Scrum increases the transparency of the process, enabling the team to inspect and adapt its own process more effectively.

A Cumulative flow diagram can be used to make WIP levels visible over time.

WIP aging is one of the crucial flow metrics used in Professional Scrum with Kanban. It shows, for each item on the Kanban board how long ago has it been pulled into WIP.

Cycle Time is a lagging indicator only relevant for finished items, Work Item Age is a leading indicator which is relevant for non-finished items.

The main role of the Work Item Age metric is to identify specific items that are struggling and require attention.

4.    Make Process Explicit (Inspecting and adapting their definition of “Workflow”)

Scrum already encourages teams to review and improve processes during the Sprint Retrospective.

Kanban’s focus on flow helps to make the team’s processes visible. Specifically, by agreeing and documenting the detailed “rules of the game” which a Scrum team is applying, all members on the team will be more aware of how they should be working together.

This applies to every aspect of the team’s operation, including how “Workflow” is defined, when PBIs can move between states and what is the agreed definition of “Done”.

5.    Implement Feedback Loops

If you are already using Scrum, the you know that of course Scrum has feedback loops built-in as a core part of the Scrum Framework!

Sprint Planning, the Daily Scrum, the Sprint Review, and the Sprint Retrospective are all feedback loops which are embedded in Scrum.

You can use the Scrum Board and various Kanban metrics which you are collecting to improve visibility at the Daily Scrum and to help drive better improvement suggestions at the Retrospective.

In addition, the visibility provided by Kanban creates opportunities for the Product Owner to review “Done” PBIs throughout the Sprint as they are ready.

6.    Improve Collaboratively, Evolve Experimentally

Scrum is built on the principles of empirical process control theory. The fundamental principles of inspection, adaptation, and transparency support and encourage experimentation and improvement.

The objective of the Sprint Retrospective is to give all members of the Scrum Team the ability to inspect and adapt how the team works and therefore directly support collaborative improvement and experimentation.

But what is “Workflow” 

Each team’s definition of “workflow” is unique and it can and should change as a team discovers better ways of working. The team’s definition of “Workflow” should include a definition of how work is defined, the start state of the process, the active states for the work items, and the finished state of the process.

“Workflow” can be thought of as the “Team’s policy” for how to get work “Done”.

Similarly, the definition of “Done” can be considered the “Team’s policy” for what “Done” looks like.

The Scrum + Kanban Guide recommends that a Scrum team create its definition of “Workflow” containing the following elements:

• Defined points at which the Scrum Team considers work to have started and to have finished.
• A definition of the individual units of customer value that are flowing through the Scrum Team’s system (most likely Product Backlog Items (PBIs)).
• A definition of the workflow states that the PBIs flow through from start to finish (of which there must be at least one active state).
• Explicit policies about how work flows through each state (which may include items from a Scrum Team’s definition of “Done” and pull policies between stages).
• A definition of how Work in Progress (WIP) will be limited.
• A set Service Level Expectation (SLE) that communicates a forecast of how long it should take to complete work items.

Service Level Expectation 

An SLE forecasts how long it should take a given item to go from start to finish, for example: 85% of items will be completed within 5 days.

Initially this is likely to be a “guess” which can be improved over time based on the actual rate at which the team delivers work.

An SLE can be used to give the Product Owner and stakeholders an idea of the service level to be expected, but it does not provide a specific date for each PBI in the Sprint Backlog.

Kanban Flow Metrics and Scrum

The flow based metrics used in Kanban can be leveraged by a Scrum team to improve the effectiveness of their Scrum based events.

There are four basic Kanban metrics of flow that Scrum Teams using Kanban should track:

• Work in Progress (WIP): The number of work items started but not finished (according to the Scrum Team’s definition of “Workflow”).
• Cycle Time: The amount of elapsed time between when a work item “starts” and when a work item “finishes.” Cycle time is a lagging indicator – you only know the cycle time after the PBI reached the end of the team’s definition of Workflow.
• Work Item Age: The amount of elapsed time between when a work item “started” and the current time.
• Throughput: The number of work items “finished” per unit of time. Note the measurement of throughput is the exact count of work items.

Sprint Planning

Throughput can be used as a part of Sprint Planningin order to create a more realistic forecast for the Sprint Backlog.

Daily Scrum

The focus of Daily Scrum is the ongoing flow within the Sprint, therefore Current WIP and Work Item Age are the most important metrics in the Daily Scrum.

The Daily Scrum focuses on ensuring the Scrum Team is doing everything it can to maintain flow every day.

Some things to consider during the Daily Scrum are:

• What work items are blocked and what can the Scrum Team do to get them unblocked?
• What is the Work Item Age of each item in progress? What work items have violated or are about to violate their SLE and what can the Scrum Team do to get that work completed?
• Are there any things that may impact the Scrum Team’s ability to complete work today that is not represented on the board?

Sprint Review

 The Scrum Guide provides a detailed outline of the Sprint Review process. In addition to these activities, inspecting Kanban flow metrics as part of the Sprint Review increases transparency.

Sprint Retrospective

The Sprint Retrospective is focused on inspecting and adapting the process and the workflow.

A Kanban style Sprint Retrospective adds the inspection of flow metrics and analytics to help determine what improvements the Scrum Team can make to its processes, including the Sprint Retrospective itself.

The Scrum Team using Kanban also inspects and adapts the definition of “Workflow” to optimize the flow in the next Sprint.

Where to next with Kanban and Scrum? 

If you are new to both Scrum and Kanban and wish to begin improving the way a team (or teams) within your organisation operate, then I recommend considering Scrum + Kanban as an excellent starting point in your “Agile Journey”.

If you already use Scrum, then please consider how the Kanban practices outlined here might benefit you. The Agile Manifesto includes the Principle “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”, and the adoption of some of the practices I have described can certainly help you and your team become more effective.

By increasing your opportunities to inspect and adapt, you can improve your ability to deliver value as quickly as possible. That is surely worth at least consideration?

Chris Young

#scrum #kanban #scrumban #descaling #xscale #finaplana