Before you can implement Scrumban, you need to understand the Kanban thinking it borrows from. The most important idea is one that feels backwards until you see it work: doing less at once makes you faster overall.
Learning Objectives
- Explain Little's Law and why it matters for software teams
- Define Work-in-Progress (WIP) limits and describe how they improve flow
- Distinguish between push-based and pull-based work systems
- Identify common flow problems on a visualised board
Little's Law — The Math Behind the Magic
Little's Law is a queuing theory formula from the 1960s that applies perfectly to software teams:
Average Cycle Time = Average WIP ÷ Average Throughput
In plain English: the more work you have in progress simultaneously, the longer each piece of work takes to complete.
If a team has 3 developers and each is working on 1 story, average cycle time might be 2 days. Add more parallel work — each developer juggling 3 stories — and that same 2-day story now takes 6 days, because context-switching, coordination overhead, and waiting for others all compound.
The counterintuitive implication: Starting fewer things finishes more things, faster.
Work-in-Progress (WIP) Limits
A WIP limit is a constraint placed on a workflow column that caps how many items can be in that state at once.
Example board columns with WIP limits:
| Column | WIP Limit | What the limit enforces |
|---|---|---|
| In Analysis | 3 | Never analyse more than 3 stories at once |
| In Development | 4 | Team swarms on blocked work rather than starting new |
| In Testing | 3 | QA doesn't accumulate a queue of "ready to test" items |
| In Review | 2 | PRs don't sit unreviewed for days |
When a column hits its WIP limit, no new item can enter until one exits. This is the pull system in action: work is pulled from the previous stage only when there is capacity to receive it.
What happens when WIP limits are violated?
The most common reaction when teams first introduce WIP limits is frustration: "I'm blocked on this story — what should I do, just sit there?" The answer is no — you should help unblock another item that's stuck in a downstream column. This creates a culture of swarming and collaboration rather than individual "busy-ness."
Push vs. Pull Systems
Push system (traditional Scrum sprint):
- Work is assigned at Sprint Planning and "pushed" to developers
- A developer is responsible for their stories regardless of what else the team needs
- A developer who finishes early either pulls more work (if the process allows) or waits for the sprint end
Pull system (Kanban / Scrumban):
- Developers signal "I'm ready" by pulling from the backlog
- Work moves through stages only when the receiving stage has capacity
- Bottlenecks become immediately visible because work piles up in front of them
In Scrumban, the sprint cadence provides the planning rhythm (push), but the daily execution uses pull — team members take what's next only when they have capacity.
Flow Efficiency — The Hidden Metric
Most teams measure throughput (how many stories per sprint). What they rarely measure is flow efficiency:
Flow Efficiency = Active Time ÷ Total Lead Time × 100%
A story might be "in development" for 5 days — but if the developer only actively worked on it for 6 hours, and the rest was waiting for review, waiting for environments, or waiting for a decision, the flow efficiency is 15%.
Teams that visualise and measure this find that most of the time, work is not being worked on — it's waiting. WIP limits force this waiting to become visible and create the pressure to resolve the bottlenecks causing it.
Common Flow Problems on a Board
| Visual pattern | What it signals | What to do |
|---|---|---|
| Cards piling up in "In Testing" | QA is the bottleneck | Developers help with testing; no new dev starts |
| Cards stuck in "In Review" for days | Review culture is broken | Pair programming, mob review, or time-boxed PR review |
| Long lead time for small stories | Too much handoff overhead | Reduce stages, use feature teams |
| Everything marked "urgent" | Prioritisation doesn't exist | Implement explicit classes of service |
Pro Tip: The first time you put WIP limits on your board, set them higher than you think you need — just to make the constraint visible without causing too much pain. Then tighten them over time. A limit of ∞ is the same as no limit — but a limit of 10 at least starts a conversation.
Summary
- Little's Law explains mathematically why doing less at once is faster
- WIP limits are constraints that enforce focus and reveal bottlenecks
- Pull systems move work based on capacity, not assignment
- Flow efficiency is often far lower than teams expect — most time is waiting, not working
- Scrumban uses these concepts inside a sprint cadence to manage both planned and unplanned work