Scrum and Kanban — Stronger Together

Over the years I’ve been at the forefront of creating productive mashups of Scrum, Kanban, SAFe, LeSS, and other approaches. Mashups can be very attractive — but they can also be an excuse for taking what you like from each approach and leaving behind the hard stuff.

The goal is always the smallest set of practices that is still cohesive, comprehensive, and brings the best of the Scrum iterative world together with the Kanban flow-oriented world.

Why Combine Scrum and Kanban at All?

Scrum and Kanban address different but complementary problems.

Scrum provides structure: a clear team rhythm (the Sprint), defined roles (Scrum Master, Product Owner, Developers), and explicit events for planning, review, and retrospection. It excels at creating a cadenced, self-organizing team that consistently delivers.

Kanban provides flow visibility and management: a clear picture of where work is, how fast it moves, where it gets stuck, and how much is in progress simultaneously. It excels at exposing systemic bottlenecks and creating the discipline of finishing before starting.

Used together, you get a team with:

• Cadence and structure from Scrum (Sprint rhythms, clear accountabilities)
• Flow transparency and management from Kanban (WIP limits, cycle time tracking, continuous improvement of the workflow itself)

The combination is not a compromise — it is genuinely stronger than either alone.

What Does Scrum Miss That Kanban Adds?

Scrum is deliberately incomplete. It is a framework, not a methodology. The Scrum Guide leaves many questions unanswered by design — how to manage workflow within a Sprint, how to track flow, how to handle different types of work with different urgency.

Kanban fills these gaps without replacing Scrum’s structure:

Workflow visualization — an explicit board showing each step of your development process, not just “To Do / In Progress / Done.” This reveals where work accumulates and where hand-offs create delays.

WIP limits — explicit constraints on how much work can be in each stage simultaneously. In Scrum, a team might commit to 30 items in a Sprint and start all 30 on day one. WIP limits force the team to finish work before starting new work.

Flow metrics — cycle time, throughput, work item age, and WIP tracked over time. These give Scrum teams the data to answer questions like “how predictable are we?” and “where are our slowest steps?” that velocity and sprint burndown alone cannot answer.

Service Level Expectations (SLEs) — explicit commitments about how long different types of work should take. These replace vague “we’ll try to get to it” conversations with data-driven expectations.

What Does Kanban Miss That Scrum Adds?

Pure Kanban is non-prescriptive about roles, events, and cadence. This gives teams maximum flexibility — but can also leave teams without the scaffolding they need to self-organize and continuously improve.

Scrum provides what Kanban leaves open:

A learning cadence — the Sprint Review and Retrospective create a regular forcing function for reflection and adaptation. Without this, Kanban teams can flow indefinitely without ever examining whether they are flowing toward the right outcomes.

Clear accountability — the Product Owner role ensures someone is responsible for prioritizing the right work. The Scrum Master role ensures the team’s process is healthy and improving. These accountabilities can exist in Kanban-only environments but are often implicit and unclear.

Shared commitment — the Sprint Goal creates a shared micro-objective that aligns the team around delivering something coherent rather than just completing independent tasks.

What Is the Professional Scrum with Kanban (PSK) Training?

Working with Steve Porter, Dave West, and others at Scrum.org — as well as Daniel Vacanti of Actionable Agile — we co-developed the Professional Scrum with Kanban (PSK) training to formalize the integration.

PSK is built on four key practices that Scrum teams can add as concrete experiments:

1. Visualizing the Sprint Backlog with a multi-step workflow board (not just three columns)
2. Applying WIP limits to Sprint Backlog items in flight simultaneously
3. Using flow metrics (cycle time, throughput) alongside Sprint metrics
4. Conducting a flow-focused Retrospective using data from the Sprint’s flow

The course does not replace Scrum — it shows Scrum teams how to add Kanban practices in a way that is cohesive with the Scrum framework and evidence-based.

How Do You Start Combining Scrum and Kanban?

The practical starting point is not a training course or framework decision — it is a single experiment. Pick one Kanban practice and try it for one Sprint:

Experiment 1: Visualize your workflow. Redesign your Sprint board to show the actual steps your work goes through — Design, Dev, Code Review, QA, Ready to Deploy — rather than a generic three-column board. Observe where work piles up.

Experiment 2: Add a WIP limit. Agree that no more than three items can be “In Development” at once. See what happens when you hit the limit. The conversations that emerge are exactly the kind that improve your process.

Experiment 3: Track cycle time. For one Sprint, record when each item starts and finishes active development. Calculate the average. You now have a baseline — the starting point for meaningful improvement.

These experiments require no permission from outside the team and can be started in the next Sprint.

Frequently Asked Questions

Should you use Scrum or Kanban? For most software teams: both. Scrum provides the cadence, roles, and review structure that create a high-functioning team. Kanban provides the flow visibility and management practices that help the team get better over time. The Professional Scrum with Kanban (PSK) approach is a well-developed path for combining them without creating an incoherent hybrid.

Is Scrumban the same as Professional Scrum with Kanban? Not quite. “Scrumban” is an informal term for various combinations of Scrum and Kanban, often used when teams are transitioning from one to the other. Professional Scrum with Kanban (PSK) is a specific, formally defined approach with a course and guide published by Scrum.org. PSK is designed to add Kanban practices to a Scrum foundation in a cohesive, empirically-grounded way.

Do WIP limits break Sprint commitments? No — WIP limits complement Sprint commitments. A Sprint commitment is about what the team will deliver by the end of the Sprint. WIP limits are about how the team manages flow within the Sprint to make that delivery most likely. Teams that add WIP limits typically find they complete their Sprint Goals more reliably, not less, because they focus on finishing rather than starting.

Can you do Kanban without Scrum? Yes. Pure Kanban — without Scrum’s Sprints, roles, or events — is a legitimate approach, especially for operations work, support teams, and contexts where the work arrives continuously in unpredictable ways. The Kanban Guide for Scrum Teams and the PSK course are specifically for teams that want to keep Scrum’s structure while adding Kanban’s flow management capabilities.

What is the Kanban Guide for Scrum Teams? The Kanban Guide for Scrum Teams is a brief (7-page) guide published by Scrum.org that defines the minimum set of practices for integrating Kanban into Scrum. It was co-authored by the PSK working group, including Yuval Yeret, and provides a formal reference for what “Scrum with Kanban” means.

Interested in bringing Professional Scrum with Kanban to your team or organization? Get in touch or explore the PSK training course.