Scrum vs Kanban vs Scrumban
| Scrum | Kanban | Scrumban | |
|---|---|---|---|
| Iterations | 1-4 week sprints | Continuous work alongside releases shorter than one week or bigger iterations like goals | Continuous work with short cycles for planning and longer cycles for release |
| Work routines | Push and pull principle mixed with early binding to team members | Pull principle with late binding to team members | Pull principle with late binding to team members |
| Scope limits | Sprint limits total work amount | Work in progress limits current work amount | Work in progress limits current work amount |
| Planning routines | Sprint planning | Release/iteration planning, demand planning | Planning on demand for new tasks |
| Estimation | Must be done before start of sprint | Optional | Optional |
| Performance metrics | Burndown | Cumulative flow diagram, lead time cycle time | Average cycle time |
| Continuous improvement | Sprint retrospective | Optional | Short Kaizen event as an option |
| Meetings | Sprint planning, daily scrum, retrospective | Can be avoided | Short Kaizen event |
| Roles | Product owner, Scrum master, team | Team and other work specific roles | Team and other work specific roles |
| Team members | Cross-functional team members | Cross-functional team members, specialization is allowed | Specialization or preference to tasks |
| Task size | The size that can be completed in sprint | Any size | Any size |
| New items in iteration | Forbidden | Allowed whenever queue allows it | Allowed whenever queue allows it |
| Ownership | Owned by a team | Supports multiple teams ownership | Supports multiple teams ownership |
| Board | Defined/reset each sprint | Persistent | Persistent |
| Prioritization | Through backlog | Optional | Recommended on each planning |
| Roles | Scrum master, product owner, team | Not defined, may vary | Not defined, may vary |
| Rules | Constrained process | Only a few constraints, flexible process | Slightly constrained process |
| Fit for | Enterprise maturity for teams working on product or especially project which is longer than a year | Support and maintenance teams, continuous product manufacturing | Startups, fast-pace projects, continuous product manufacturing |
Kanban Board example
A classic Kanban Board should contain essential entities:
- Colored kanban cards to symbolize and describe work
- Columns to define and describe process flow to work completion
- WIP limits to define throttling or discover bottlenecks
- Swimlanes to separate work by additional aspect, like priority, project group, work category or similar
Kanban Boards are the most visual technique to represent work and related information. Main goal to use colors and layout is to reduce informational overload and amount of text to comprehend which is common to classical project and work management systems.
Kanban Boards are universal and can be used by any industry. Each industry can define unique templates for process specifics.
