Scrum and Kanban

 

When to use scrum and when to use kanban

 

from ScrumAlliance

Work Cycle

Scrum Kanban
- Iterations. Scrum has sprints within which the team follows the plan-do-check-act (PCDA) cycle.

- Complex, iterative work, like new product or feature development, may be better done with scrum.
- Continuous flow. In a kanban work cycle, as soon as one thing finishes, the team takes another thing up.

- Kanban is better for continuous flow work like support and services.

Work In Progress

WIP

Scrum Kanban
- WIP limits are set by the scrum team for every sprint, and new work is picked up only after all the work is completed.

- If teams need a sense of accomplishment / completion / closure, use scrum.
- WIP limit is ongoing. As soon as some work finishes, pickup new work.

- If teams keep working on one thing after another, use kanban.

Inspect and Adapt

(Empericism)

Scrum Kanban
- Every sprint is an opportunity to inspect and adapt. Work cycles through multiple sprints for improvisation, if needed.

- If the work continuously evolves and needs improvisation, use scrum.
- No specific mechanism to inspect and adapt. Work flows in one direction.

- If the work is a one-time effort, and doesn't require inspection and adaptation, use kanban.

Transparency

(Empericism)

Scrum Kanban
- Artifacts in scrum include the product backlog, sprint backlog, an increment. Respectively provide requirements, implementation, and deliverables transparency.

- If requirements need to be tracked separately from tracking the work in progress, use scrum.
- No specific artifacts for transparency. Kanban board provides some transparency. Many teams use product backlog (from scrum) in combination with kanban boards.

- If only implementation needs to be tracked, use kanban.

Planning

Scrum Kanban
- Specific events for planning the sprint and the day — sprint planning and daily scrum.

- Use scrum if disciplined planning at regular intervals is required.
- No specific artifacts for transparency. Kanban board provides some transparency. Many teams use product backlog (from scrum) in combination with kanban boards.

- If only implementation needs to be tracked, use kanban.

Responsibility

Scrum Kanban
- Accountabilities in scrum develop responsibility focus e.g. product owner for business, developers for domain, and scrum master for impediments.

- If teams need individuals focused on these responsibilities, use scrum.
- There are no accountabilities like product owner, developers, etc. in kanban. It assumes a group of individuals working on tasks.

- If the team is simply a group of individuals with some expertise, use kanban.

Client/Customer

Scrum Kanban
- Scrum has active stakeholder and customer involvement — at least once a sprint during a sprint review event.

- If the work is innovative, creative, or new and requires stakeholder and customer feedback/engagement, use scrum.
- Kanban does not provide a way to engage stakeholders or customers. Many teams adopt a once-a-month “sprint review” approach.

- If the work is mostly daily routine and does not require frequent stakeholder engagement use kanban.

Modification/Changes

Scrum Kanban
- Changes during the sprint are strongly discouraged. - Allows for changes to be made to a project mid-stream, allowing for iterations and continuous improvement prior to the completion of a project.

Measurement of Productivity

Scrum Kanban
- Measures production using velocity through sprints. Each sprint is laid out back-to-back and/or concurrently so that each additional sprint relies on the success of the one before it. - Measures production using “cycle time,” or the amount of time it takes to complete one full piece of a project from beginning to end.

Best Applications

Scrum Kanban
- Best for teams with stable priorities that may not change as much over time. - Best for projects with widely-varying priorities.

Resources

www.planview.com

www.scrumalliance.com

deck

By Dana Diotte