To Scrum, to Kanban or to Scrumban, that is the question

Many organizations are implementing scrum, but wonder if Kanban isn’t a better option? Or they are using Scrum for a while, but they aren’t sure if that’s really the best way of working for their teams. These organizations might consider Scrumban as an alternative.

What is Kanban?

Kanban is a method for organizing work, by making the process and the flow of the process visible. This enables a team to continuously optimize the flow of the process and to quickly identify bottlenecks, thereby decreasing cycle time. The focus of Kanban is mainly on efficiency (doing things right).

To do this a Kanban board is used that contains the process steps in vertical column and the backlog items and tasks on horizontal lanes. An important practice of Kanban is the Work-in-Progress (WIP) limit. A WIP limit means that each column has a maximum number of tasks that can be in this process step. When that maximum is reached, no new items can be pulled into this process step, until one of the items is first moved to the next column or put on the backlog. This practice keeps flow in the entire process, by avoiding tasks stockpiling at certain process steps creating bottlenecks.

What is scrum?

Scrum is an agile framework for organizing work, with a focus on efficiency (doing the right things). Key is the product backlog that is continuously being prioritized on business value to ensure that teams are always working on backlog items with the highest business value. In addition, the teams work in sprints with a fixed duration to deliver one or more shippable products at the end of that sprint. Every sprint 4 events are held to support the sprint.

Though not explicitly mentioned in the Scrum guide, most teams working with Scrum have a sprint board visualizing the status of the items that are to be delivered in the current sprint. This sprint board is actually a Kanban board and that means that Scrum and Kanban are effectively already combined. This make sense as the value of Kanban of visualizing the process adds a focus on efficiency to the Scrum approach which has a focus on effectivity (doing the right things right).

What is Scrumban?

Scrumban is a combination of Scrum and Kanban, where a Kanban board is used to visualize the work and flow of the process including WIP limits per process step. It also makes use of the Scrum principle of backlog management and prioritization on business value. However, the biggest difference between Scrum and Scrumban is that the latter doesn’t work with sprints. Work can be continuously pulled by the team as long as the WIP limits of each process step are respected. This way flow is created as work continuously flows through the process.

It makes sense to have the scrum roles in place in Scrumban and there is also value in keeping the scrum events in place. The sprint planning can be used to regularly refine work on the backlog, making it ready to be pulled into the process. A regular review with stakeholders is also still valid, to get feedback from users and to discuss priorities. Finally, the retro can be used to discuss the way of working and ways to improve that. The teams can decide on the duration and frequency of these meetings.

When can Scrumban be a useful approach?

Scrumban can be a useful way of working for teams that have focus on maintenance tasks. As these teams are regularly fixing bugs there is usually an urgency to release more frequently than after every sprint. Scrum is not restricting teams to release during a sprint, but a focus on creating a potentially shippable product in a 2 week sprint, is not the right frame of mind when dealing with a number of high priority bugs that need immediate fixing.
In addition, bugs are unplanned work that disrupt sprints. Of course a team can reserve a fixed amount of time per sprint for unplanned work, but when a lot of the work is unplanned, this approach doesn’t seem very valid. It then makes much more sense to work via a Kanban board allowing the team to pull work into the process any time.
Finally, it is often hard to define a sprint goal for teams doing a lot of maintenance work as the items the teams works on often don’t have a common goal. In Scrumban a sprint goal is not relevant as there are no sprints.

Scrumban can also work well for teams that depend heavily on other parties for getting their work done. Reason is that due to these dependencies it is often difficult for the team to estimate when the work can be ready, making it hard or even impossible to commit to delivering a set of backlog items in a sprint. IT departments responsible for managing third party software, for example are dependent on the supplier for implementing changes and the contractual agreements made with this supplier. Working in sprints then isn’t helpful. Scrumban can be more helpful then by keeping track of the status of items and to focus on monitoring the cycle time of the requests.

Have you been considering Scrumban? What are your experiences with the value of Scrumban for your team?