Kanban for Scrum Teams: How to Improve Flow Without Losing Scrum

Many Scrum Teams reach a point where Scrum works, but not as smoothly as it could. Sprints end with several items almost finished. Urgent requests disrupt plans. Estimation meetings drag on. Work waits quietly in review. Kanban practices can help with all of these, without replacing Scrum. This guide explains what changes and what stays the same when a Scrum Team adds Kanban, how each Scrum event benefits from a focus on flow, and how to get started.

Key takeaways

• Scrum Teams can add Kanban practices while keeping all of Scrum's accountabilities, events and artifacts.
• Kanban adds a visible workflow, WIP limits, active management of work items and flow metrics.
• Every Scrum event can use flow data: throughput for Sprint Planning, work item age for the Daily Scrum and forecasts for the Sprint Review.
• Limiting WIP within the Sprint helps teams finish items one after another and reach the Sprint Goal more reliably.
• Start small: visualise, limit, measure, then improve.

Why Scrum Teams add Kanban

Scrum provides structure: accountabilities, events and artifacts that create a regular rhythm of planning, delivery, inspection and improvement. What the Scrum Guide does not prescribe is how the Developers manage the flow of work within the Sprint. That is deliberate; the Developers are self-managing. Kanban offers practices many teams find useful in that space. Common reasons teams adopt them:

• Too much started, too little finished. Many items are in progress by the middle of the Sprint, and several are still unfinished at the end.
• Hidden queues. Items wait for review or testing without anyone noticing.
• Unpredictable work. Urgent requests arrive during the Sprint and disrupt the plan.
• Estimation fatigue. Long debates about story points add little value.
• Forecasting questions. Stakeholders want to know when larger pieces of work will be ready.

For an introduction to Kanban itself, see our complete Kanban guide.

What stays the same

Adding Kanban practices does not change Scrum. The Scrum Guide states that the Scrum framework is immutable: implementing only parts of it is possible, but the result is not Scrum. A Scrum Team using Kanban practices still has:

• Three accountabilities: Scrum Master, Product Owner and Developers
• Five events: the Sprint, Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective
• Three artifacts and their commitments: Product Backlog and Product Goal, Sprint Backlog and Sprint Goal, Increment and Definition of Done

Kanban practices sit alongside these. If a team drops parts of Scrum, it is moving towards a hybrid such as Scrumban, which is a different choice.

What Kanban adds

Scrum.org published The Kanban Guide for Scrum Teams, written with Daniel Vacanti and Yuval Yeret, to describe how Kanban practices complement Scrum. The core additions are:

• A defined, visible workflow. The Sprint Backlog is shown on a board with the real stages work goes through.
• Limiting work in progress. Explicit WIP limits so the team finishes work before starting more. See WIP limits explained.
• Actively managing work items. Watching for blocked and ageing items and acting quickly.
• Flow metrics. Work in progress, throughput, cycle time and work item age. See Kanban metrics explained.
• A Service Level Expectation. A forecast of how long a single item usually takes, based on past cycle times.

The Definition of Workflow

A Definition of Workflow is the Scrum Team's shared agreement about how work flows. It typically covers:

• What counts as a work item
• Where work starts and where it finishes
• The stages work moves through
• How WIP is limited
• Explicit policies, such as when an item can move to the next stage
• The team's Service Level Expectation

The Definition of Workflow does not replace the Definition of Done. The Definition of Done describes the quality an Increment must meet; the Definition of Workflow describes how work moves toward it. Our article on Scrum artifacts explains the Definition of Done.

Flow in each Scrum event

Sprint Planning

Sprint Planning still answers three questions: why the Sprint is valuable, what can be Done and how the work will get done. Flow data helps with the second question. Instead of adding up estimates, the Developers can look at their recent throughput, for example 8 to 12 items per Sprint, to judge how many items are realistic. The Sprint Goal remains the focus. See Product Goal and Sprint Goal explained.

Daily Scrum

The Daily Scrum's purpose is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog. A board with flow data makes this concrete. Many teams walk the board from right to left and ask:

• What is closest to done, and what does it need?
• What is blocked, and who can help?
• Which items are older than our Service Level Expectation suggests?
• Are we at or over any WIP limits?

The Developers still choose the structure of their Daily Scrum; flow questions are simply a useful option.

Sprint Review

The Sprint Review inspects the outcome of the Sprint and discusses progress toward the Product Goal. Flow data helps answer stakeholders' questions about timing. A Monte Carlo forecast based on throughput can show, for example, an 85% chance that the next set of items will be Done within two Sprints. That is often more useful than a single estimated date.

Sprint Retrospective

The Retrospective inspects individuals, interactions, processes, tools and the Definition of Done. Teams using Kanban practices also inspect their Definition of Workflow: are WIP limits right, where do items wait, which policies need changing? Cycle time and throughput trends show whether previous improvements worked. See how to run a Sprint Retrospective.

Product Backlog refinement

Refinement is an ongoing activity, not a Scrum event. Teams using flow often practise right-sizing: checking whether an item is small enough to finish within their Service Level Expectation. If not, they split it. This can replace detailed estimation for many teams.

Velocity or throughput?

Many Scrum Teams track velocity, the number of story points completed per Sprint. Teams using Kanban practices often add or switch to throughput, the number of items finished. Both have supporters:

• Velocity accounts for item size and is familiar to many teams, but depends on estimates that can be inconsistent and time-consuming.
• Throughput needs no estimates and is simple to measure. When items are right-sized, it is often just as good for forecasting.

The Scrum Guide does not require either. It notes that practices such as burn-downs, burn-ups and cumulative flows can be useful for forecasting, but do not replace the importance of empiricism. Choose the measure that helps your team inspect and adapt.

Handling unplanned work during the Sprint

Scrum says no changes should be made that endanger the Sprint Goal, and scope may be clarified and renegotiated with the Product Owner as more is learned. Some teams use a Kanban-style expedite lane for genuinely urgent issues, limited to one item at a time, with a clear policy agreed with the Product Owner. If urgent work arrives so often that the Sprint Goal is regularly at risk, that is worth discussing in the Retrospective: the team may need to plan capacity for it or reconsider its approach.

An example Sprint board with WIP limits

As an illustration only:

Sprint Backlog	In progress	Review	Testing	Done
Selected items, ordered	Limit 4	Limit 2	Limit 2	Meets the Definition of Done

With the Sprint Goal written at the top and an expedite lane limited to one item. For more on board design, see how to set up a Kanban board.

A worked example Sprint

As an illustration, consider a team of six Developers with two-week Sprints:

• Before: by day four, eleven items are in progress. At the end of the Sprint, seven items are Done and five are almost done, and the Sprint Goal is only partly met.
• After adding WIP limits: in-progress work is limited to four, review to two. Developers help each other finish items before starting new ones.
• Result over the next few Sprints: items finish in a steadier stream, fewer items are left half-done at the end, and the team can see from its cycle time data that most items now finish within a few days.

The numbers in any real team will differ. The pattern, fewer items started and more items finished, is what teams usually report.

The Scrum Master and Product Owner

The Scrum Master is accountable for the Scrum Team's effectiveness, so helping the team adopt useful flow practices fits naturally within the role: facilitating a Definition of Workflow session, coaching the team to respect WIP limits and helping stakeholders understand probabilistic forecasts. See what does a Scrum Master do?

The Product Owner benefits from flow data when ordering the Product Backlog and talking to stakeholders. Throughput-based forecasts help set realistic expectations, and right-sized items make the backlog easier to plan.

Flow and the Sprint Goal working together

Some teams worry that a focus on flow will distract from the Sprint Goal. In practice, the two support each other. The Sprint Goal tells the team which items matter most this Sprint; flow practices help the team finish those items one after another rather than all at once. A useful habit is to order the Sprint Backlog so that items most important to the Sprint Goal are pulled first, and to ask at every Daily Scrum whether current work in progress is moving the team toward the goal.

Right-sizing explained

Right-sizing means checking whether an item is small enough to finish within the team's Service Level Expectation, rather than estimating its exact size. For example, if the team's SLE is "85% of items finish within 8 days", then during refinement the team asks of each item: "Do we believe this can be finished within 8 days?" If yes, it is right-sized. If no, the team splits it. Right-sizing turns long estimation debates into a quick, practical question, and it makes throughput a more reliable basis for forecasting, because items become more similar in size.

Forecasting a release with throughput: an example

As an illustration, a Product Owner wants to know when 40 right-sized items will be Done. The team's throughput over the last eight two-week Sprints has been 9, 11, 8, 12, 10, 9, 13 and 10 items. A Monte Carlo simulation samples these values thousands of times to simulate future Sprints. The results might show that finishing all 40 items takes four Sprints or fewer in about half the simulations, and five Sprints or fewer in about 85% of them. The Product Owner can then tell stakeholders: "We are about 85% confident these items will be Done within five Sprints." As each Sprint finishes, the forecast is updated with new data. See Kanban metrics explained for more on Monte Carlo forecasting.

Flow in remote Scrum Teams

Remote teams benefit even more from explicit flow practices, because nobody can glance across the room to see who is stuck. A single digital board with visible WIP limits, clear blocked markers and automatic recording of dates gives everyone the same picture. Walking the board together in the Daily Scrum keeps the conversation focused on finishing work rather than individual status updates.

Signs flow practices are helping

• Fewer items are left unfinished at the end of each Sprint.
• Cycle times are shorter and more consistent.
• Blocked items are noticed and resolved within a day or two.
• The Sprint Goal is met more often.
• Stakeholders find the team's forecasts reliable.

Helping stakeholders accept probabilistic forecasts

Stakeholders used to single dates may find "85% likely by 14 March" unfamiliar. A few approaches help: explain that the forecast is based on the team's actual delivery history, show how it changes as new data arrives, and compare it over time with what actually happened. When stakeholders see forecasts proving reliable, trust grows. It also helps to explain that a single date hides risk, while a probability makes it visible so better decisions can be made.

Questions to ask about flow in your next Retrospective

• Where did items wait longest this Sprint, and why?
• Did we respect our WIP limits? If not, what happened?
• Which items took much longer than usual, and what can we learn from them?
• Is our Service Level Expectation still realistic?
• What one change to our workflow should we try next Sprint?

Common questions from Scrum Masters

Will flow practices take the team's focus away from the Sprint Goal?

Not if the Sprint Goal remains the reference point. Ordering the Sprint Backlog by the Sprint Goal and pulling in that order keeps flow and focus aligned.

Do we need a separate Kanban meeting as well as the Daily Scrum?

No. The Daily Scrum can use the board and flow questions; adding another daily meeting is unnecessary.

How do we introduce this without disrupting the team?

Start with visualising the workflow and recording dates, which change very little. Add WIP limits once the team sees the data.

Common pitfalls

• Dropping Scrum events. Kanban practices complement Scrum; removing events means the team is no longer doing Scrum.
• WIP limits nobody respects. Limits only help if the team stops starting new work when they are reached.
• Measuring without discussing. Metrics should inform the Daily Scrum, Review and Retrospective.
• Forgetting the Sprint Goal. Flow matters, but the Sprint Goal is still the focus.
• Using metrics to judge individuals. Flow metrics describe the system, not people.

How to get started

1. Visualise the real workflow of your Sprint Backlog, including waiting stages.
2. Agree a first WIP limit for in-progress work, close to today's level.
3. Record start and finish dates for every item.
4. Use the board in the Daily Scrum, focusing on finishing.
5. Review flow data in the Retrospective after two or three Sprints.
6. Write down your Definition of Workflow and revisit it regularly.

Learn more

For the Scrum side, see our complete Scrum Master guide and the five Scrum events explained. For a comparison of the two approaches, read Kanban vs Scrum. If you want to build and demonstrate Kanban skills, Kanban Management in Systems Plus covers flow, WIP limits and flow metrics; the exam is taken online on ExamVault by CertExpert with three attempts included, and the certificate and digital badge are valid for two years.