Optimizing flow requires defining what flow means in a Scrum context. Each Scrum Team must 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 workflows 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.

First, a quick review of a key tenet of The Scrum Guide: 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. Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.

Scrum mandates that the Sprint Backlog be transparent, but it provides limited guidance on how to accomplish this. Nor does it define how to achieve explicit transparency to the flow of work into the Product Backlog, from the Product Backlog into the Sprint Backlog, and whatever happens to the work after it makes it into a “Done” increment. This is where Kanban can help. By visualizing work in new ways, a Scrum Team can apply the set of practices laid out in this guide to more effectively optimize value delivery. These practices borrow from and build upon the principles of lean thinking, product development flow, and queuing theory.

Scrum Teams achieve flow optimization by using the following four practices:

• Visualization of the workflow
• Limiting WIP
• Active management of work items in progress
• Inspecting and adapting their definition of “Workflow”

Visualization using the Kanban board is the way the Scrum Team makes its workflow transparent. The board’s presentation should prompt the right conversations at the right time and proactively suggest opportunities for improvement.

Work in Progress (WIP) refers to the work items the Scrum Team has started but has not yet finished. Scrum Teams using Kanban must explicitly control these in-progress work items from the time they consider them “started” until the time they consider them “finished.” That control is usually represented as a number or numbers on a Kanban board. Those numbers are called “WIP Limits.”

Limiting WIP is a necessary component to achieve flow, but it alone is not sufficient. The third practice to establish flow is the active management of work items in progress. Active management can take several forms, including but not limited to the following:

• Responding quickly to blocked work items. 
• Making sure that work items are only pulled into the workflow at about the same rate that they leave the workflow. 
• Ensuring work items aren’t left to age unnecessarily and are completed according to an established SLE. 
• Unclogging work that piles up in a column or columns.

Kanban in a Scrum context does not require any additional events to those outlined in The Scrum Guide. However, using a flow-based perspective can enhance Scrum events.