"Should engineering teams use sprints or Kanban"

"Use sprints (Scrum) when your team is building planned features with predictable scope — the fixed cadence creates useful delivery pressure and stakeholder alignment. Use Kanban when your work is interrupt-driven (bug fixes, support escalations, ops work) or when scope is highly uncertain. Most mature teams use a hybrid: sprint-planned feature work with a Kanban lane for unplanned work. The biggest mistake is forcing sprints on a team whose work is 60% unplanned — they'll miss every sprint commitment and blame themselves for a process problem."

Sprints vs. Kanban for Engineering Teams: Which Works and When

At least once a month, a client asks me: “Should we be doing sprints or Kanban?” And my answer is always the same: “Tell me about your work, and I’ll tell you which process fits it.”

The methodology wars are a waste of energy. Scrum isn’t better than Kanban. Kanban isn’t better than Scrum. The question is which process matches the type of work your team actually does. Pick wrong and your team will fight the process instead of using it.

When Sprints Work

Sprints work when you can plan. That means:

Predictable feature work. Your product team has a roadmap. Requirements are reasonably well-defined before engineering starts. The team can estimate work in roughly sprint-sized chunks (1-2 weeks). You know what you’re building before the sprint starts, and it doesn’t change dramatically mid-sprint.

Stakeholder alignment cadence. Sprints create natural checkpoints. Every two weeks, you demo what was built, get feedback, and adjust the plan. For teams that work closely with product managers, sales, or executives who need visibility into progress, sprints provide that rhythm without requiring constant status updates.

Team building shared accountability. Sprint commitments create a team-level contract. The team says “we’ll deliver X by Friday” and either hits it or doesn’t — together. This shared accountability builds cohesion in a way that individual task assignment doesn’t. When one person is behind, the team swarms to help because it’s the team’s commitment, not just one person’s.

The standard sprint cadence is two weeks. One week is too short for meaningful feature work. Three weeks or longer loses the urgency. Two weeks is the sweet spot for most teams I work with.

When Kanban Works

Kanban works when you can’t plan — or when planning adds overhead without value.

Interrupt-driven work. If your team handles production support, bug fixes, security patches, or customer escalations, the work arrives unpredictably. Planning a sprint when 40% of your capacity will be consumed by unknown work is an exercise in fiction. Kanban’s continuous flow model handles variable workloads without the cognitive overhead of sprint planning ceremonies.

Ops and infrastructure teams. Platform engineering, DevOps, and SRE teams typically work in a mix of planned projects and reactive work. Kanban with WIP (work-in-progress) limits gives them a way to manage flow without pretending they can predict what next week looks like.

Highly uncertain scope. Early-stage product exploration, R&D, and prototype work often don’t fit sprint boundaries. You’re experimenting, learning, and pivoting. Committing to a two-week plan when you might learn on day three that the approach won’t work is counterproductive.

The critical Kanban practice is WIP limits. Without them, Kanban degenerates into “work on whatever you want” with no flow management. A WIP limit of 2 items per developer forces finishing before starting, which is the single most impactful process change I implement at client companies.

The Hybrid That Actually Works

Most teams I work with end up in a hybrid model, and that’s fine. Here’s the pattern:

Sprint-planned feature work goes through a normal Scrum process — planning, daily standups, retrospective. This is your roadmap work, your committed deliverables, the stuff you told stakeholders you’d ship this quarter.

A Kanban lane for unplanned work runs alongside the sprint. Bug fixes, production issues, and urgent requests flow through this lane with WIP limits. You track how much capacity the unplanned lane consumes — if it’s consistently eating more than 20-30% of capacity, that’s a signal to either staff a dedicated support team or address the root causes of the unplanned work.

Reserve capacity. I tell every team to plan sprints at 70-80% capacity, not 100%. The remaining 20-30% absorbs the unplanned Kanban work without blowing up sprint commitments. Teams that plan at 100% and then get surprised by bugs and support requests aren’t bad at estimating — they’re ignoring a predictable source of work.

The Process Smell Test

Your process is wrong if:

Your team misses sprint commitments more than 30% of the time. Either your estimates are consistently wrong (an estimation problem, not a process problem) or your work is too unpredictable for sprints (switch to Kanban or hybrid).
Ceremonies take more than 10% of total work time. If your two-week sprint includes 8+ hours of planning, standup, refinement, review, and retro, you’ve created a process tax that’s eating delivery capacity.
Nobody looks at the board. If engineers don’t update their cards and managers don’t use the board for decision-making, the process is theater. Either make it useful or drop it.
“We’re agile” but nothing ships for months. The point of any agile methodology is frequent delivery of working software. If your process has all the ceremonies but none of the output, you’ve implemented the form without the function.

The One Thing That Matters More Than Methodology

Whatever process you use, the thing that actually drives performance is finishing things. Not starting things — finishing them. An engineer who completes two tasks this week has contributed more than one who started five and finished none. WIP limits, whether formal (Kanban) or implicit (sprint commitments), exist to enforce this.

The methodology is just scaffolding. The discipline of finishing is the structure.