Kanban or Scrum sprints: choose the delivery rhythm that fits the work

Start with the shape of the work

Kanban and Scrum both help teams make work visible, limit overload and improve delivery. The important difference is their rhythm. Kanban manages a continuous flow of work; Scrum works in fixed-length sprints with a planned goal and review point.

The right choice depends less on whether a team calls itself product or engineering, and more on how work arrives. A team maintaining live services may receive urgent incidents, support requests and small fixes throughout the week. A product team building a coherent new capability may benefit from protecting a short period of focused work.

Neither method removes the need for good product decisions, engineering quality or collaboration. They are ways of organising decisions about what starts, what finishes and when the team learns.

Kanban suits continuous and variable demand

Kanban visualises the path work takes from request to completion. The team pulls the next appropriate item when capacity is available rather than committing a batch of work to a timebox. Work-in-progress limits prevent every person from starting something new while existing work waits for review, testing or deployment.

It is often a good fit for operations, maintenance, platform work and teams with frequent unplanned demand. The team can prioritise an urgent item without pretending that a two-week plan will remain unchanged.

Flow needs active management. If new requests can enter at any point without a clear policy, urgent work becomes a permanent excuse for never completing important improvement work. Set service classes, escalation rules and explicit policies for what can interrupt the normal queue.

Ready  →  In progress  →  Review  →  Test  →  Done
             WIP: 3         WIP: 2      WIP: 2

Policy:
  - Pull only when the next column has capacity.
  - Expedite work is reserved for a defined production or legal urgency.
  - A blocked item is made visible and discussed daily.

Scrum suits work that benefits from a short commitment

Scrum uses a timeboxed sprint, usually one or two weeks, in which a cross-functional team works towards a Sprint Goal. The goal is more useful than a collection of individually assigned tickets: it gives the team a shared outcome against which to make trade-offs during the sprint.

A sprint can protect focus long enough to build, test and demonstrate a meaningful increment. Planning, a review and a retrospective establish regular points to align on priorities, gather feedback and improve how the team works.

The sprint is not a promise that no learning will occur. If a critical incident or new evidence changes the value of the goal, the team and product owner should make that decision openly. Treating every planned ticket as untouchable can turn the timebox into a local optimisation rather than a product-delivery tool.

Use measures that reveal the real constraint

For Kanban, lead time, cycle time, throughput, work-item age and blocked time show whether work is flowing. A growing number of items in review may indicate a testing or decision bottleneck, not a lack of developer activity.

For Scrum, inspect whether Sprint Goals are met, whether the increment is genuinely usable and what routinely carries over. Velocity can support near-term forecasting for one stable team, but it is not a productivity score and should not be compared across teams.

In either approach, measure outcomes alongside flow: defects, support demand, deployment confidence, user feedback and operational reliability. Moving tickets faster is not success if the work creates more rework or fails to solve the underlying problem.

Avoid the common failure modes

Kanban fails when the board is only a status display. Without WIP limits, pull policies and attention to blocked work, it simply makes a large queue more visible. Teams then feel busy while cycle time lengthens.

Scrum fails when planning becomes ticket allocation, stand-ups become status reporting to a manager and retrospectives produce no change. A sprint with no clear goal can become a batch of unrelated work that happens to share an end date.

Do not combine the rituals indiscriminately. A team can use a board and WIP limits during a sprint, or use regular replenishment and reviews in Kanban. The point is to adopt practices that solve a known flow or feedback problem, not to accumulate meetings.

Choose deliberately, then revisit the decision

Choose Kanban when demand is continuous, priorities legitimately change often and the team needs to reduce waiting time across a visible workflow. Choose Scrum when the team can protect a short goal, needs a predictable review cadence and is delivering coherent increments of product value.

Some teams use both modes for different work. For example, a product team may use sprints for planned feature delivery while a small rotating group handles urgent live-service work through a separate Kanban policy. Make the capacity split explicit so interruptions are not hidden.

Review the method after a few cycles using evidence. If the team regularly abandons its Sprint Goal because urgent work is normal, a flow-based approach may fit better. If a Kanban team struggles to create focus for a larger outcome, a timeboxed goal may provide the missing structure.

• Choose based on demand pattern and feedback needs, not a label
• Use Kanban WIP limits and explicit pull and expedite policies
• Use Scrum Sprint Goals rather than treating a sprint as a ticket container
• Measure flow, blocked work, quality and outcomes
• Keep planned and unplanned capacity visible
• Change the process when the evidence says the work has changed