Scrum and Kanban: how to use both approaches together
Quick summary: what each side contributes
Scrum contributes structure: accountabilities, a Product Backlog, Sprint Goals and a fixed rhythm of planning, review and retrospective.
Kanban contributes execution visibility: a board that mirrors the real workflow, WIP limits that prevent overload and flow signals that expose blockers early.
Together they answer both questions a team faces: what should we pursue this cycle, and how is the work actually moving today.
Before diving into reading:
This article is the practical recipe for running both approaches at once, complementing the broader discussion in how Kanban relates to Scrum.
Nothing here requires abandoning either framework — that is precisely the point.
1) Not competitors, but layers
Scrum and Kanban operate at different layers. Scrum structures time and responsibility: who decides priorities, what the goal is, when the team plans and reviews. Kanban structures execution: how work becomes visible, how much runs at once, how flow problems surface.
Because the layers barely overlap, combining them is mostly addition, not negotiation. A Scrum team adds Kanban practices; nothing of Scrum is removed.
2) What Scrum contributes
The Sprint gives work a heartbeat and a goal; Planning turns priorities into a concrete forecast; the Review collects stakeholder feedback on real product; the Retrospective reserves time to improve the system. The Product Owner keeps one ordered backlog, shielding the team from priority chaos.
This structure answers the questions Kanban deliberately leaves open: who owns value, what the cadence is, when inspection happens.
3) What Kanban contributes
The board makes the Sprint Backlog a living picture instead of a list read once at Planning. WIP limits turn "everything in progress" into "a few things finishing". Explicit blocker marking, aging awareness and flow metrics — cycle time, throughput — give the team execution data Scrum does not generate on its own.
This answers the question Scrum leaves open: how is the work actually flowing between Planning and Review?
4) The Sprint Backlog on a board
At Sprint Planning, selected items become cards in a To Do column; the remaining columns mirror the team's real stages — for example In Development, In Review, In Testing, Done. The Sprint Goal sits visibly at the top of the board.
From that moment, the board is the single source of truth for the Sprint. Anyone — team member or stakeholder — sees the same reality without asking for a status.
5) WIP limits inside the Sprint
Add limits to the active columns: perhaps three In Development, two In Review. When a column fills, the team swarms to finish instead of starting more — which is exactly the behavior a Sprint Goal needs.
The effect on Sprint outcomes is direct: items finish throughout the cycle instead of stampeding into the final days, and a genuinely Done increment becomes the norm rather than the hope. Details in the WIP limits article.
6) Flow metrics in Scrum events
Velocity says how much a Sprint delivered; flow metrics say where time went. Cycle time per item, throughput per week and the age of in-progress cards feed the Daily ("this card has been in Review four days"), the Review ("our forecast reliability") and especially the Retrospective ("Review is our bottleneck — what do we change?").
Retrospectives grounded in flow data produce sharper experiments than retrospectives based on recollection.
7) A Sprint in the combined model
Planning: items become cards, the goal goes on the board, limits are checked. Daily: walk the board right to left, finishing first, blockers named. Mid-Sprint: an urgent item enters only by explicit swap decision, visible on the board. Review: the Done column is the demo agenda. Retrospective: the board's history — accumulation, aging, violations — sets the agenda for improvement.
Teams describe the result simply: Scrum tells them why and when; Kanban shows them what and how, every single day.
8) Conclusion
Use Scrum to organize accountability, goals and cadence; use Kanban to make execution visible and controlled. They were never in conflict — they complete each other.
Start your next Sprint on a board with one WIP limit. If the combination fits, deepen it gradually — or explore its formalized cousin, Scrumban.