Scrum 3-5-3 vs Kanban: What Every Developer Needs to Know
Scrum = 3 roles, 5 events, 3 artifacts. Kanban is the other major Agile framework. Here’s how they compare.
Scrum: The 3-5-3 Framework
3 Roles (Accountabilities)
| Role | Job | Key Difference from Traditional PM |
|---|---|---|
| Product Owner | Maximizes value, manages Product Backlog, voice of stakeholders | One person, one accountable decision-maker |
| Scrum Master | Servant-leader, removes blockers, coaches self-management | No authority — influences through trust |
| Developers | Self-managing, cross-functional, builds the Increment | No one assigns them tasks |
There is no project manager in Scrum. That’s the biggest shock for people coming from traditional approaches. The Scrum Master is not a manager — they’re a coach and facilitator.
5 Events (Ceremonies)
All events are timeboxed and exist to enable empiricism (inspect and adapt).
| Event | Timebox | Purpose |
|---|---|---|
| Sprint | 1-4 weeks | Container for all other events |
| Sprint Planning | max 8h (1mo) | What/How/Why for this Sprint |
| Daily Scrum | 15 min | Sync on Sprint Goal, plan next 24h |
| Sprint Review | max 4h (1mo) | Demo Increment, collect feedback |
| Sprint Retro | max 3h (1mo) | Inspect process, plan improvements |
The Retrospective is the most important event. Skip it and you stop improving.
3 Artifacts (And Their Commitments)
| Artifact | Commitment | What It Is |
|---|---|---|
| Product Backlog | Product Goal | Ordered list of everything needed |
| Sprint Backlog | Sprint Goal | Selected items + plan to deliver |
| Increment | Definition of Done | Usable product that meets quality bar |
The flow: Product Backlog → Sprint Planning selects items → Sprint Backlog → Developers build → Increment → Sprint Review → feedback back to Product Backlog.
Kanban: The Flow-Based Alternative
Kanban looks completely different:
| Aspect | Kanban |
|---|---|
| Roles | No fixed roles — team-based, self-organizing |
| Rhythm | Continuous flow — no Sprints or iterations |
| Events | Replenishment (pull work when WIP drops), Daily Standup (track flow), Service Delivery Review (cycle time analysis) |
| Artifacts | Visual board (To Do → Doing → Done) with explicit WIP limits |
| Change | Work can be reprioritized anytime — no frozen scope |
The core idea: visualize your workflow, limit work-in-progress, and optimize flow.
Scrum vs Kanban: Quick Comparison
| Dimension | Scrum | Kanban |
|---|---|---|
| Timebox | Fixed Sprints (1-4 wks) | Continuous flow |
| Change | Scope frozen mid-Sprint | Reprioritize anytime |
| Metrics | Velocity (story points) | Cycle time / throughput |
| WIP | Implicit (Sprint scope) | Explicit WIP limits |
| Ceremonies | 4 mandated events | Flexible / event-triggered |
| Best for | Product development | Ops / support / maintenance |
Why Scrum Over Kanban for Software Teams
Software product teams use Scrum. Sprint Planning, Daily Scrums, Sprint Reviews, Retros — that’s the standard rhythm for product development teams.
Kanban is taught as the comparison because you’ll still see it (or hybrid “Scrumban” approaches) in the wild. But Scrum is the foundation.
Learn the 3-5-3 cold, and you’re ready for any Scrum team.
Diagram and post based on the 2020 Scrum Guide.