Scrumban | Agile Scrum Master
Scrumban is a hybrid approach that blends Scrum planning cadence with Kanban flow control to handle changing priorities while protecting focus. It is often used when teams want less rigid timeboxing, stronger WIP discipline, or a transition path between Scrum and Kanban. Key elements: visual workflow, explicit WIP limits, pull-based commitment, on-demand planning and replenishment, optional Sprint events as needed, and metrics such as cycle time and work item aging. Scrumban keeps improvement continuous by inspecting flow and adjusting policies.
When Scrumban fits
Scrumban combines elements of Scrum and Kanban to help teams manage work when demand is variable (interrupts, mixed work types, shifting priorities) but coordination still benefits from a regular rhythm. It is useful when timeboxed “commit-to-scope” planning creates thrash, yet the team still needs predictable review points, clear priorities, and a shared way to make trade-offs visible.
Scrumban is not a fixed standard with one correct configuration. It is an evolving work system: make work and constraints visible, apply explicit policies (especially WIP limits and pull criteria), inspect flow and outcomes, and adapt the policies based on evidence. The goal is not to be “half Scrum, half Kanban,” but to improve decision quality and flow while protecting quality and focus.
Core Elements of Scrumban
Scrumban uses a visual workflow and explicit WIP limits to reduce multitasking and shorten feedback loops. The workflow should reflect reality, including waiting states, review/test steps, and blocked work, so queues and constraints are visible rather than hidden in status updates.
- Cadence as a coordination tool - Keep a rhythm for review and improvement, but let commitment be driven by pull and capacity rather than calendar-driven scope locking.
- Visual workflow - Show work states, queues, and handoffs so the team can see where flow slows and why.
- WIP limits - Limit active work per workflow step to protect focus, expose bottlenecks, and increase finishing rate.
- Pull policies - Define explicit entry criteria for starting work, and pull only when capacity exists to complete, not just to start.
- Blocked work rules - Make blockers explicit, time-box escalation, and prefer unblocking and finishing over starting something new.
- Quality built into the workflow - Define acceptance and verification expectations per state so work does not “advance” without meeting quality criteria.
- Policy improvement - Treat policy changes as experiments and keep what measurably improves flow, quality, and outcomes.
Scrumban becomes effective when WIP limits are real (not optional), when pull criteria are respected, and when the team uses flow evidence to adjust policies instead of debating opinions.
Scrumban planning cadence and replenishment
Scrumban planning is driven by readiness and capacity, not by committing to a full timebox scope. Replenishment becomes the primary decision point: what is the next best option to pull, given priorities, constraints, and what the system can realistically finish.
- Replenishment - Decide what to pull next using ordering criteria, readiness, and available capacity, and record the rationale when trade-offs are non-obvious.
- On-demand planning - Plan when the ready queue drops below a threshold or when new information changes priorities materially.
- Daily coordination - Coordinate around flow, aging work, blockers, and finishing, not around individual status.
- Review cadence - Inspect delivered outcomes with stakeholders and update priorities based on feedback and observed impact.
- Improvement cadence - Review policies regularly and change a small number of levers at a time so learning is attributable.
Scrumban planning should make priority changes explicit and bounded through policies, so the team can respond to change without constantly disrupting in-progress work.
Scrumban metrics and forecasting
Scrumban relies on flow metrics to understand capability and risk. These measures are most useful when treated as learning inputs that reveal constraints and guide policy changes, not as targets to optimize locally.
- Cycle time - Measure time in progress to reveal bottlenecks and the real cost of multitasking.
- Lead time - Measure responsiveness from request to delivery to manage stakeholder expectations and service reliability.
- Throughput - Track completed items per period to support forecasting and capacity conversations.
- Work item aging - Detect risk early by highlighting items that exceed typical age for their class of work.
- Flow stability - Inspect variability and its causes to improve predictability through system changes, not pressure.
Forecasting improves when work items are sliced thinly, classes of work are explicit, and the team updates expectations frequently using historical flow rather than converting estimates into certainty.
Scrumban relationship to Scrum and Kanban
Scrumban borrows Scrum elements when they create clarity of intent and stakeholder feedback, and borrows Kanban elements when they improve flow control and transparency. Teams keep, adapt, or drop specific practices based on whether they reduce decision latency, improve flow, and increase the rate of validated learning.
Scrumban should preserve empiricism: make work visible, inspect outcomes and flow, and adapt policies based on evidence. If meetings, boards, or metrics do not change decisions or improve flow, they are overhead.
Scrum Practices in Scrumban
- Intent and goal focus - Use a goal-like focus when it helps alignment, while keeping scope negotiable as constraints and learning change.
- Review for feedback - Use regular stakeholder reviews to inspect what was delivered and what was learned, then update ordering.
- Retrospective for system change - Identify the biggest constraint, change one or two policies, and verify impact using flow and quality signals.
- Role clarity - Keep decision rights explicit so prioritization and acceptance decisions are fast and transparent.
Kanban Practices in Scrumban
- Workflow visualization - Visualize real states and waiting so constraints are observable.
- WIP limits - Limit concurrent work to improve finishing rate and reduce hidden queues.
- Explicit policies - Define pull criteria, blocked work handling, and replenishment rules so the system is predictable and improvable.
- Flow metrics - Use cycle time, lead time, throughput, and aging to guide decisions and improvement experiments.
Implementing Scrumban incrementally
Scrumban is commonly implemented by starting from an existing Scrum or Kanban system and adding missing controls. Implement it as a series of small experiments: establish a baseline, change one constraint at a time, and inspect whether outcomes and flow improved.
- Assess the current system - Map how work actually flows today, including waiting, rework, and handoffs.
- Design a real workflow - Include review/testing and blocked states so delays are visible and discussable.
- Set initial WIP limits - Place limits where work ages and queues grow, then adjust based on evidence.
- Define replenishment rules - Make explicit how items enter ready, how priorities change, and who can make those changes.
- Baseline flow metrics - Start tracking cycle time, throughput, and aging so improvement is evidence-based.
- Establish review and improvement rhythms - Keep a stakeholder review cadence and a policy review cadence to sustain learning.
- Adapt policies deliberately - Change a small number of policies, observe impact, and keep what improves flow, quality, and outcomes.
Common misuse and practical guardrails
Scrumban is often used as justification to remove discipline: no explicit WIP limits, unclear pull criteria, and irregular stakeholder feedback. This creates hidden queues, constant reprioritization, and low predictability while still “looking busy.”
- Unbounded WIP - Looks like starting more work to feel productive; it hurts by increasing cycle time and delaying feedback; do instead: enforce WIP limits and swarm to finish.
- Reprioritizing in-progress work - Looks like changing direction daily; it hurts by creating thrash and unfinished work; do instead: protect in-progress work and change ordering at replenishment points.
- Skipping real feedback - Looks like flowing work without stakeholder review; it hurts by optimizing output without validating value; do instead: keep a reliable review cadence tied to outcomes.
- Quality as a downstream step - Looks like moving cards forward without verification; it hurts by creating rework and unstable flow; do instead: make quality criteria explicit in workflow policies and verify continuously.
- Board decoration - Looks like renaming columns instead of changing policies; it hurts because constraints stay unchanged; do instead: evolve explicit policies and validate improvements with flow evidence.
Scrumban is a hybrid approach combining Scrum cadence with Kanban flow and WIP limits to improve adaptability, reduce bottlenecks, and evolve ways of working