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. For most software teams, the answer isn’t Scrum or Kanban—it’s both. Scrum provides the cadence and structure, while Kanban provides the flow visibility to help the team improve over time.

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. The Scrum Guide leaves many questions unanswered by design—how to manage workflow within a Sprint, how to track flow, and how to handle urgent work.

Kanban fills these gaps without replacing Scrum’s structure:

Workflow visualization — an explicit board showing each step of your development process. 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. 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 because they focus on finishing rather than starting.

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 designed to add Kanban practices to a Scrum foundation in a cohesive, empirically-grounded way. While “Scrumban” is often an informal term for various hybrid transitions, PSK is a specific, formally defined approach. It is supported by the Kanban Guide for Scrum Teams, a concise reference co-authored by the PSK working group.

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

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. Observe where work piles up.

Experiment 2: Add a WIP limit. Agree that no more than three items can be “In Development” at once. 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. While pure Kanban (without Scrum’s Sprints or roles) is legitimate for operations or support work, most development teams benefit from keeping Scrum’s structure while adding Kanban’s flow management.

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