Scrumban and the Kanban Guide for Scrum Teams: Adding Flow to Scrum
Adding flow to Scrum doesn't require dropping the Sprint: the Kanban Guide for Scrum Teams adds a DoW, WIP limits and the four flow metrics to Sprint Planning, the Daily Scrum, Review and Retrospective without changing any part of the Scrum Guide. We cover Scrumban as Ladas described it, as a transition path, its loose use today, and choosing Scrum, Kanban or both for support, platform and product teams.
Version note: This post is based on The Kanban Guide 2025.5, Scrum.org's Kanban Guide for Scrum Teams (2021 update) and the Scrum Guide 2020.
Guess First
Besides the support team, Bookstore has a second team: a Scrum Team that builds the catalog and search side of the product in two-week Sprints. The same complaint comes up in the last four retros: three or four half-finished items roll over into the next Sprint at the end of each Sprint, and there is less finished work to show at the Sprint Review. Someone on the team suggests: "The support team moved to Kanban and they're happy. Let's do Scrumban too: drop the Sprints, put WIP (Work in Progress) limits on the board, pull work as it comes."
Does this suggestion solve the team's problem? What does the team lose when it drops the Sprint? And consider this: is the reason for the half-finished work at the end of the Sprint the Sprint itself, or how many items are started at once inside the Sprint?
Ladas's Scrumban: A Transition Path
The word "Scrumban" comes from essays Corey Ladas wrote in 2007–2008; they were collected in 2008 in the book "Scrumban: Essays on Kanban Systems for Lean Software Development." Ladas originally described Scrumban as a way for a Scrum team to move step by step toward Kanban's pull system: first make the board visible, then add WIP limits, and finally replace fixed-length iterations and batch planning with planning that is triggered when the queue drops below a certain level. In other words, Ladas's Scrumban was not a destination but a bridge from Scrum to continuous flow.
Today the word "Scrumban" is used much more loosely. When a team says "we do Scrumban," it usually means it kept some parts of Scrum (the Daily, the retro, maybe the Sprint Review), dropped others (the Sprint Goal, Sprint Planning) and added a few things to the board. There is no official definition; neither the Scrum Guide nor The Kanban Guide defines Scrumban. That's why, whenever you say "Scrumban," you need to spell out what you mean.
The Kanban Guide for Scrum Teams
Scrum.org gave a more structured answer to this confusion: the Kanban Guide for Scrum Teams. Developed by Daniel Vacanti and Yuval Yeret together with the Scrum.org community, the guide was updated in January 2021 to fit the Scrum Guide 2020. Its first and most important statement is that it does not change or discount any part of the Scrum Guide. Kanban doesn't replace Scrum here; it adds a flow view on top of Scrum.
The guide asks the Scrum Team for four practices: visualizing the workflow, limiting WIP, actively managing items in progress, and inspecting and adapting the Definition of Workflow. For measurement it uses the four metrics of this series: WIP, Cycle Time, Work Item Age and Throughput. The Definition of Workflow (DoW) belongs to the Scrum Team, is not dictated from outside and is not limited to a single Sprint; items can cross the Sprint boundary, and so does the DoW. The guide also describes the SLE (Service Level Expectation) as a duration and probability computed from historical cycle time; without data, the team starts with a guess.
There are also things the guide leaves out on purpose. Yeret writes that concepts like cost of delay and flow efficiency were not included in this minimum set, because they are not required for a Scrum Team to improve its flow. Like The Kanban Guide, the guide is short and minimal.
Flow on Top of the Events
The most practical part of the guide is the section that describes how flow is added to each Scrum event:
The Sprint itself doesn't change. The Sprint remains a feedback loop for inspecting and adapting the DoW and the flow metrics, and the Scrum Team keeps producing at least one usable Increment every Sprint.
In Sprint Planning, historical throughput is capacity information about how many items can go into the Sprint Backlog. It can replace velocity directly: instead of a story point total, you look at how many items finished in recent Sprints. The SLE helps here too: an item that looks bigger than the SLE is split before it enters the Sprint.
The Daily Scrum takes place around the board and focuses on where flow is lacking: blocked or slow items, Work Item Age, items at risk of missing the SLE, and WIP limit breaches. This is the Scrum counterpart of the right-to-left, oldest-first meeting from post 06.
In the Sprint Review, flow metrics feed the conversation about progress toward the Product Goal. Throughput, together with the Monte Carlo from post 05, gives a probabilistic answer to "at this pace, when do we reach the Product Goal?"
In the Sprint Retrospective, the team inspects the flow metrics and analytics and adapts the DoW for the next Sprint. The guide says the CFD (Cumulative Flow Diagram) is useful at this point; the cycle time scatterplot from post 04 fits here too.
The Bookstore Catalog Team: Adding Flow to Scrum
Instead of dropping Sprints, the catalog team tried the guide's path. In the first Sprint they wrote a DoW for their board like the one in post 02: the started point is when an item is pulled from the Sprint Backlog into In Dev, the finished point is the production deploy. They set WIP limits of 4 on In Dev and 2 on Code Review.
The first retro showed the problem wasn't the Sprint but the team starting all nine items in the first two days of the Sprint. Every developer opened two or three items, and all of them piled into Code Review and test at the same time in the last days of the Sprint. The half-finished items at the end of the Sprint were a direct result of high WIP inside the Sprint. The WIP limit fixed that: items started finishing one by one throughout the Sprint, and the "last day rush" at the end of the Sprint faded.
In Sprint Planning they started looking at the throughput of the last three Sprints instead of story points. At the Daily Scrum they look at the aging chart every morning. The Sprint Goal stayed exactly as it was; Kanban didn't touch it. The Scrum Guide 2020 never mentions velocity and leaves it to the team how to forecast the Sprint Backlog; so moving from story points to throughput is not leaving Scrum but making a choice Scrum leaves open in a different way. The details of the story point approach are the subject of the upcoming Estimation and Planning series.
The Decision: Scrum, Kanban or Both
Which one for which team? There's no hard rule, but the nature of the work is a good hint:
| Team type | Nature of the work | Reasonable start |
|---|---|---|
| Support and operations | Continuous, unpredictable demand, mostly small work, frequent urgent items | Kanban: DoW, WIP limits, SLE, expedite policy |
| Platform team | A mix of requests from other teams and its own improvement work | Kanban, serving requesting teams with an SLE; a periodic review if needed |
| Product team | Work moving toward a Product Goal that needs discovery | Scrum plus flow metrics from the Kanban Guide for Scrum Teams |
| Newly formed team | High uncertainty, no rhythm yet | Scrum's events build rhythm; flow metrics are collected from day one |
At Bookstore the support team works in Kanban and the catalog team in Scrum plus flow, and the two choices don't contradict each other. Because both teams compute the same four metrics the same way, managers can talk about both teams' flow in the same language; but they don't add the two teams' throughput together, because their item definitions differ.
In Production
Don't mix velocity and throughput on the same chart. Tracking both numbers during a transition makes sense, but don't try to convert one into the other ("1 item = 5 points"), and say clearly which one you're looking at in Sprint Planning.
Don't reset cycle time at the Sprint boundary. If an item didn't finish by the end of a Sprint and rolled over into the next one, its cycle time keeps counting from the day it first entered In Dev. Updating the start date because it was "replanned" into the Sprint erases the longest-running items from the measurement.
Keep the DoW in the Scrum Team's hands. The guide explicitly says the DoW should not be dictated from outside. A PMO (Project Management Office) imposing the same columns and the same WIP limits on every team forces each team's different work into the same mold.
Common Pitfalls
The biggest pitfall is dropping structure under the name "Scrumban": dropping the Sprint without adding a WIP limit, dropping the Sprint Goal without replacing it with anything, dropping the retro and never improving at all. The result is neither Scrum nor Kanban; the catalog team's original suggestion carried exactly this risk. If you drop something, write down what will provide what it provided (rhythm, focus, improvement).
The second pitfall is treating the Sprint as the enemy of flow. The Sprint is a rhythm for planning and inspect/adapt; items finishing in a batch at the end of the Sprint is a result of WIP inside the Sprint, not of the Sprint. The catalog team solved this problem without dropping Sprints, just by limiting WIP.
The third is seeing Kanban as a "board tool" inside Scrum. The Kanban Guide for Scrum Teams asks not for a board but for a DoW, WIP control and active management; switching the board to Kanban view in Jira changes nothing on its own. This is the Scrum counterpart of the warning in the first post of the series.
The fourth is replacing the Sprint Goal with a throughput target. "We'll finish 15 items this Sprint" is not a Sprint Goal; the Sprint Goal says why you're working, throughput says how much you finished. The two are used together; neither replaces the other.
A Small Experiment
★☆☆ For each of your team's last three Sprints, count how many items were left half-finished at the end of the Sprint and how many items were started in the first two days. Do you see a relationship between the two numbers?
★★☆ At the next Sprint Planning, put the throughput of the last three Sprints next to the story point total and compare the Sprint Backlog size each method suggests. Which one turned out closer to reality at the end of the Sprint?
★★★ Fill in the decision table in this post for your team: which row does the nature of your work resemble? Justify the model you choose with a one-page note showing what replaces each Scrum or Kanban piece your team drops.
The Kanban series ends here: from the board to the Definition of Workflow, from WIP to Little's Law, from the four flow metrics to Monte Carlo forecasts and daily active management. Flow is about making work move the right way; it doesn't say what should be moving. That question, building the right thing, is the subject of the Introduction to Product Management series.