Agile, Scrum, and Kanban — when to use what

Agile is a mindset for building software when requirements change, feedback matters, and learning beats guessing. Scrum and Kanban are two popular ways teams put that mindset into practice—but they solve different problems. Definition of Ready (DoR) and Definition of Done (DoD) are the quality gates that keep either approach honest: clear enough to start, complete enough to ship.

The confusion usually starts here: a company renames its project plan "sprints," keeps fixed scope and fixed date, and calls it Agile. Or a team adopts daily standups without empowered product ownership and wonders why nothing improves. This article separates the ideas, compares the frameworks, names common mistakes, and explains when waterfall (plan-driven, sequential delivery) is still the right call.

WavePillars treats Agile delivery as disciplined empiricism: frameworks are tools, not badges—what matters is whether work is visible, inspectable, and shippable against explicit readiness and done criteria.

Agile — the mindset behind the frameworks

The Agile Manifesto (2001) states four values—individuals and interactions, working software, customer collaboration, responding to change—and twelve supporting principles. None of them mention sprints, story points, or Jira boards.

Agile thinking favors:

• Iterative delivery — Ship small increments early; learn from real usage instead of long specification phases.
• Feedback loops — Product, customers, and engineering inspect outcomes and adapt the plan.
• Empowered teams — People closest to the work decide how to deliver value within agreed goals.
• Embracing change — Late-arriving requirements are expected; the cost of change should drop as you iterate, not rise.

Agile is not a process. Scrum, Kanban, XP, and Lean product practices are methods that implement Agile ideas with different rules and rhythms. You can be Agile without Scrum; you can run Scrum ceremonies without being Agile if management overrides every decision.

Scrum — fixed iterations and empiricism

Scrum is a lightweight framework built on empiricism: transparency (work is visible), inspection (check progress regularly), and adaptation (adjust based on what you learn). A Scrum Team delivers a Done Increment every Sprint—a time box of one month or less, usually two weeks.

Accountabilities

Scrum has no Project Manager role. Coordination happens inside a self-managing, cross-functional team that has every skill needed to deliver value each Sprint.

Events

The Daily Scrum is not a status report to managers. The Sprint Review is not a performance review. Each event has a specific inspect-and-adapt purpose.

Artifacts

Work that does not meet the Definition of Done is not part of the Increment. Partially finished features do not count, even if "almost done."

When Scrum fits

• Product development with a roadmap and stakeholders who can review increments regularly
• Cross-functional team that can deliver end-to-end value within a Sprint
• Need for rhythm — planning, demo, and retrospective cadence helps the organization learn
• Predictable planning horizon — team can forecast a Sprint's worth of work with reasonable confidence

When Scrum is a poor fit

• Interrupt-driven work — production support, on-call, ticket queues where priorities shift hourly
• No empowered Product Owner — backlog owned by committee or project manager with no authority to say no
• Team cannot honor Sprint boundaries — constant mid-Sprint scope injection from outside
• Individual contributors on many teams — context switching destroys Sprint commitments

Kanban — flow, limits, and continuous delivery

Kanban (from Lean manufacturing) optimizes flow: work moves through a visual board from "requested" to "done" with explicit policies at each stage. The Kanban Method emphasizes six practices:

1. Visualize the work
2. Limit work in progress (WIP)
3. Manage flow
4. Make policies explicit
5. Implement feedback loops
6. Improve collaboratively, evolve experimentally

Unlike Scrum, Kanban does not prescribe Sprints, roles, or specific events. You can start where you are: map your current process, expose bottlenecks, add WIP limits, and measure cycle time (start to finish) and throughput (items completed per period).

Key ideas

• Pull, not push — New work enters when capacity exists, not because a calendar says "Sprint start."
• WIP limits — Cap items in "In Progress" so the team finishes before starting more; reduces context switching and hidden queues.
• Classes of service — Urgent production fixes may bypass normal queue rules; policies make that explicit instead of chaotic.
• Continuous delivery — No requirement to batch work into two-week boxes; releases happen when items meet Done criteria.

Scrumban

Many mature teams blend both: Sprint Planning and Retrospectives from Scrum, plus WIP limits and flow metrics from Kanban. Scrumban is common when a team outgrows rigid Sprint commitments but still wants regular reflection and stakeholder rhythm. There is no single official Scrumban guide—teams adapt deliberately.

When Kanban fits

• Unpredictable inbound work — support tickets, SRE incidents, internal requests, bug triage
• Maintenance and operations — keeping a live system healthy alongside small improvements
• Bottleneck is visible flow — work piles up in code review, QA, or deployment; lead time is the pain
• Continuous deployment culture — shipping one item at a time is normal and desirable

When Kanban alone may not be enough

• No regular stakeholder feedback — without Reviews or equivalent, the team can optimize flow toward the wrong outcomes
• WIP limits ignored — a board with columns but no limits is wallpaper, not Kanban
• Product direction is unclear — flow optimizes execution; it does not replace product discovery and prioritization

Scrum vs Kanban — decision guide

Start here:

• Need a regular inspect-and-adapt rhythm with stakeholders → Scrum
• Need to tame a flood of varied, interrupt-driven work → Kanban
• Mature team already shipping continuously but wants retrospectives → Scrumban

Neither framework guarantees success. Both fail when teams adopt the visible mechanics and skip the underlying discipline: visible work, explicit policies, and honest inspection.

Definition of Ready (DoR)

Definition of Ready is not part of the Scrum Guide. It is a team agreement: conditions a Product Backlog item should meet before the team commits to it in Sprint Planning (Scrum) or pulls it into "In Progress" (Kanban).

Purpose

DoR answers: Can we start this item without immediate blockers? It reduces mid-Sprint surprises—missing designs, unknown dependencies, vague acceptance criteria, pending legal approval.

Typical criteria

Teams adapt DoR to their context. Common items:

• User or business value is stated clearly (user story, job-to-be-done, or equivalent)
• Acceptance criteria are written and agreed (see BDD for executable examples)
• Dependencies on other teams or systems are identified
• Item is sized or estimated enough to fit a Sprint (or within WIP policy)
• UX mockups, API contracts, or spikes completed when the work requires them
• No external approvals still pending (security, legal, architecture review)

DoR anti-patterns

• DoR so strict nothing is "ready" — Sprint Planning becomes a negotiation marathon; velocity drops to zero.
• DoR ignored — "Ready" means someone felt like starting; the team discovers blockers on day three.
• DoR as gatekeeping — Developers use it to reject product ideas instead of collaborating on refinement.
• DoR never updated — Criteria written for a monolith still apply after the team moved to microservices.

DoR is a collaboration tool between Product Owner and Developers, not a bureaucratic checkpoint.

Example DoR checklist

Adapt to your product and refinement process:

• User or business value is stated (role, goal, benefit—or equivalent framing)
• Acceptance criteria are written and reviewed with Developers
• Dependencies on other teams, services, or data are identified and tracked
• Item is estimated or sized; team agrees it fits one Sprint (or WIP slot)
• Designs, API contracts, or spikes completed when the work needs them
• No pending external approvals (security, legal, architecture sign-off)
• Product Owner confirms priority and is available for questions during delivery

Definition of Done (DoD)

Definition of Done is a formal Scrum commitment: the shared quality bar an Increment must meet. Without it, "done" means something different to every person in the room.

Purpose

DoD answers: Can we ship or integrate this work? It makes quality visible and auditable—code reviewed, tests passing, documentation updated, deployed to the right environment, monitoring in place.

Levels of done

Organizations often stack multiple bars:

1. Team DoD — merged to main, unit tests pass, peer reviewed
2. Release DoD — integration tests pass, staged in pre-production, release notes written
3. Production DoD — deployed, monitored, feature flags configured, support docs updated

Calling something "done" at level 1 when stakeholders expect level 3 creates the classic "done except…" inventory that erodes trust.

Example DoD checklist

Adapt to your product and compliance needs:

• Code merged to the main branch with at least one peer approval
• Automated tests added or updated; CI pipeline green
• No known severity-1 or severity-2 defects open against the item
• API or user-facing changes documented (OpenAPI, help text, changelog)
• Deployed to staging and verified against acceptance criteria
• Observability in place (logs, metrics, or alerts for new behavior)
• Product Owner accepts the Increment in Sprint Review

DoD anti-patterns

• "Done except testing" — Testing is part of Done, not a separate phase after "development done."
• Personal DoD — Each developer has a different bar; the Increment is inconsistent.
• DoD frozen forever — Quality expectations rise (security scanning, accessibility); DoD never updates.
• DoD only on paper — Sprint Review accepts work that clearly fails the checklist.

Strong DoD pairs well with spec-driven development when acceptance criteria and quality gates live in versioned artifacts the whole team can inspect.

DoR vs DoD

Both gates reduce ambiguity, but they answer different questions at different points in the workflow:

Use DoR to stop unclear work from entering active development. Use DoD to stop incomplete work from counting as delivered. Teams that skip DoR waste Sprints on blockers; teams that skip DoD accumulate "almost done" inventory.

Common team mistakes

These patterns show up repeatedly—in audits, retrospectives, and practice assessments. Naming them helps teams inspect honestly.

Cargo-cult ceremonies

Daily standups become status reports to managers. Sprint Reviews are slide decks with no working software. Retrospectives produce the same three complaints with no improvement actions. The calendar says Scrum; the behavior says command-and-control.

Fix: Run each event for its stated purpose. Protect the Daily Scrum for Developers. Demo real Increments. Assign owners to retrospective actions and review them next Sprint.

Fake Product Owner

The "PO" is a business analyst with no authority to prioritize or say no. The real backlog owner is a project manager or executive who overrides Sprint commitments weekly.

Fix: Give one person clear accountability for value and backlog order—or admit you are not running Scrum and choose a model that matches reality.

Velocity as a performance metric

Management compares story points across teams, sets "velocity targets," or rewards point inflation. Developers split one story into five to "score" more.

Fix: Use velocity only within the team for forecasting. Measure outcomes—lead time, defect escape rate, customer value—not points per Sprint.

Scrum on a Kanban problem

A support team runs two-week Sprints while tickets arrive continuously. Every Sprint fails because production incidents eat the forecast.

Fix: Switch to Kanban with WIP limits and SLAs for urgent work. Reserve optional Sprint-like cadences for improvement work, not ticket firefighting.

Kanban without WIP limits

The board has columns—To Do, In Progress, Review, Done—but twenty items sit "In Progress" and cycle time grows every month.

Fix: Set WIP limits low enough to hurt slightly. Finish before starting. Measure cycle time weekly.

Missing or weak DoR and DoD

Backlog items enter Sprints as one-line titles. "Done" means "merged to a feature branch." Half-finished work carries across Sprints; stakeholders lose confidence in forecasts.

Fix: Write DoR and DoD collaboratively; review them in Retrospective when pain appears. Enforce Done in Sprint Review—do not accept partial Increments.

Agile in name only

Fixed scope, fixed date, fixed price contract—with "two-week sprints" pasted on top. Change requests require change-control boards. The team is "Agile" on slide 4 of the vendor deck.

Fix: Match the delivery model to the contract. If scope truly cannot change, plan-driven phases with explicit gates may be more honest than fake Scrum. If the domain requires learning, renegotiate the contract or accept high risk.

When waterfall still makes sense

Waterfall—sequential, plan-driven delivery with distinct phases (requirements, design, build, test, deploy)—is often mocked in Agile talks. It still fits certain contexts. The mistake is treating it as universally wrong, not as a trade-off with known costs.

Waterfall fits when

• Requirements are stable and well understood upfront — regulatory specifications, fixed RFP responses, hardware-software coupling with frozen interfaces
• Correctness and documentation outweigh time-to-first-feedback — safety-critical systems, medical devices, aerospace, nuclear (often with formal verification phases)
• Contractual fixed scope, price, and date — some government and enterprise procurement where change is legally expensive
• Heavy dependency chains — downstream teams cannot start until upstream artifacts (schemas, physical designs, compliance sign-offs) are complete
• One-shot delivery with no ongoing product — data migration with a single cutover weekend, event software tied to a fixed date, replacement of a legacy system with a defined end state

In these cases, iterative discovery may increase risk if stakeholders cannot tolerate partial delivery or mid-project scope negotiation.

Hybrid reality

Many organizations run Agile inside waterfall gates: architecture and budget approved in phase gates; Scrum teams execute build increments between milestones. This can work when gates are real decision points, not theater. It fails when teams must be "Agile" for reporting but cannot change scope or technical direction.

When waterfall fails

• Unknown domain — nobody has built this before; learning is mandatory
• Frequent priority shifts — market, regulation, or leadership changes direction monthly
• Long feedback loops — users cannot validate requirements until software runs in their environment
• Software product with ongoing evolution — a one-time specification phase cannot predict year-two needs

Here, iterative delivery reduces the cost of being wrong early—which is most commercial software.

Practices that work

1. Pick the framework for the work shape — Product roadmap → Scrum or Scrumban; interrupt queue → Kanban. Revisit when the work changes.
2. Write DoR and DoD together — Product Owner and Developers own refinement quality; Done is non-negotiable for Increments.
3. Inspect outcomes, not ceremonies — Ask whether stakeholders saw working software and whether the team improved something concrete last Sprint.
4. Measure flow honestly — Lead time and defect escape rate beat vanity metrics. If you use story points, never compare teams.
5. Protect the Product Owner role — One ordered backlog, one accountable person for value.
6. Adapt policies in Retrospective — WIP limits, DoR strictness, and DoD bars should evolve as the product matures.
7. Name your model honestly — Fake Agile wastes everyone's time; plan-driven delivery with clear gates is better than cargo-cult Scrum.

Summary

Agile is a mindset: iterate, collaborate, respond to change. Scrum adds Sprints, defined accountabilities, and regular inspect-and-adapt events—strong for product teams with stakeholder rhythm. Kanban optimizes flow with WIP limits and continuous delivery—strong for unpredictable, interrupt-heavy work. Definition of Ready clarifies when work can start; Definition of Done clarifies when work counts as shippable. Neither replaces judgment; both make judgment visible.

Choose the method that matches how work actually arrives—not the label your tooling vendor prefers. And when requirements are truly fixed, risks are well understood, and contracts demand sequential assurance, waterfall (or gated plan-driven delivery) can be the honest choice. Agile is not a moral victory; shipping the right thing with appropriate quality is.

Practice your knowledge

Test your understanding of Scrum roles, events, artifacts, Agile values, and Definition of Done with the free practice assessment:

• Agile & Scrum — Free — 20 questions on Scrum fundamentals, Sprint events, and delivery commitments
• Jira — Free — backlogs, boards, and Scrum vs Kanban in Jira
• All assessments — full WavePillars catalog

Related reading

• What is behavior-driven development (BDD)? — acceptance criteria as shared, executable examples before development starts
• What is spec-driven development (SDD)? — specifications as source of truth for plans, tasks, and quality gates