Cadence AND flow: Scrum AND Kanban

I’m often asked, “Should we use Scrum or Kanban?”. That’s the wrong question. The right question is, “How can I use Scrum AND Kanban?”. I view Scrum and Kanban practices not only as compatible, but as extremely beneficial when used together.

Scrum is based on the cadence of a fixed-duration Sprint, while Kanban is based on the concept of continuous flow of work with work-in-process limits (WIP limits).

Let’s use this example of an ordered (prioritized) product backlog of work, shown in Figure 1 below. Let’s also assume that the backlog is ordered this way for a reason: to optimize value delivery and ROI and to address any lead-time dependency issues that may exist.

Figure 1: Hypothetical Ordered Backlog. The width of each item represents it’s size or scope.

The team can use a Sprint cadence for planning, reviews and retrospectives, while also setting a WIP limit as shown in Figure 2, below. In this example, the team has a WIP limit of 3 features (backlog items).

Figure 2: How do we fill Sprint 1? Is it more important to respect the backlog priority, or to finish all items we start during the Sprint?

Here is where I have seen many Scrum teams get dysfunctional, though, by applying an overly rigid view that all work started during a Sprint must be finished during the same Sprint. They treat the Sprint time box as a rigid container, and the work items like puzzle pieces that must all neatly fit inside the container. As a result, the team violates the ordering (priority) of the backlog in order to find smaller features (‘puzzle pieces’) that will fit inside the time box, as shown in Figure 3 below for Item 10 and Item 11.

Figure 3: Cadence without Flow. A dysfunctional Scrum team violates the backlog ordering to find lower priority work that 'fits’ inside the Sprint time box.

We need to remember that those backlog items are ordered for a reason - to optimize value delivery. So it’s likely dysfunctional to ignore the backlog ordering.

The team could instead combine the concept of continuous flow with the cadence of their sprint cycle. In this way, we respect the priority ordering of the backlog, and allow some backlog items to span the Sprint boundary. This also helps us avoid other silly dysfunctions such as splitting an atomic feature (or User Story) into 2 nonsensical pieces “Story Part 1” and “Story Part 2”, simply for the reason of making the ‘puzzle pieces’ fit inside the container. Figure 4 shows how to combine cadence and flow, respecting priorities and therefore maintaining higher ROI.

Figure 4: Cadence AND flow. Respect the backlog priorities, respect the WIP limit, and still leverage a cadence for Sprint planning, review, and retrospective.

The most important principle at play here is that value delivery is paramount. The Sprint boundary is somewhat arbitrary, though still useful for the purpose of having regularly scheduled times for planning and demonstrating our work to stakeholders. Value trumps cadence.

At the end of the Sprint cadence, we demonstrate our completed features to stakeholders, and transparently explain that some features are currently in process, but not yet done.