Kanban and Scrum: Their Similarities and When to Use Them

Scrum + Kanban, Sittin’ in a Tree…

It’s a shame that parallel lines never meet. They have so much in common!
– Anonymous

If you’re here, you’re likely a Kanban fan. And do you also have Scrum in your shop? 

Scrum and Kanban have a lot in common and work well in combination. Many organizations have learned the benefits of a mix ‘n’ match approach, freely selecting Scrum or Kanban by design for specific, often related, workflows. The two are similar enough that there’s a lot of commonality in concepts and language.

You may have encountered the simplifying attitude that standardizing on a single framework is important. This is supposed to bring benefits of common language and easy transfer of people among teams. There’s some truth in this, although frequent reassignments are an anti-pattern, as they inhibit high performance in teams. More significant in this case is that the skills and mental habits of the two frameworks are close enough that they transfer readily.

Combined uses can generically be termed Scrumban and are of two types. Mixed designs configure multiple teams such that some use Scrum and some, Kanban. Blended designs combine attributes of both into the operations of individual teams. Such blending follows from the observation that elements of Scrum can often be usefully added to Kanban practice to support quality throughput. Experience has shown that Kanban teams can benefit from many of the same roles, events, and concepts that provide benefit to Scrum teams. 

Similarities of Scrum and Kanban

Let’s consider some of the similarities between these two Agile workflow frameworks.

• Pull-Based: Work items are pulled by the team as their capacity allows, they are not pushed onto the team by a scheduling authority. This is fundamental to the reduction of waste and the optimization of throughput. As the authority to pull reflects the autonomy of the team, it can also have a significant beneficial effect on the psychological atmosphere.
• Process Policies: Policies state the criteria under which an item of work is permitted to advance from one state to another. Policies generally reflect a quality bar. In Scrum, they typically show up in the form of Definition of Ready and Definition of Done. Teams establish policies by agreement; this is, again, autonomy.
• Incremental and Iterative: By handling work in small pieces or small batches, both approaches make it natural to build on an early version of a feature with progressive improvement. Kanban is not intrinsically iterative. However, due to the provision for continuous input queuing, a response to feedback concerning a completed work item is easily incorporated in a future work item. This is explicit in Scrum in the expectation that sprint review feedback influences the future product backlog. These approaches allow both for new direction due to learning and for prioritization over time of successive improvements.
• Kaizen: Continuous process inspection and improvement is built in as a foundational expectation.

Making a Choice

Many characteristics of a workflow or team context will suggest whether Scrum or Kanban may be a better choice for the team or teams in that situation. Here are some general guidelines.

Scrum is Good When…

A sprint cadence provides helpful discipline: A regular sprint cadence serves to help teams develop good habits of defining, completing, and demonstrating small units of work that can be accomplished within the sprint length. This forcing function is not present in Kanban. The sprint cadence can also simplify some cross-team planning situations and support regular engagement of the stakeholder community.

Story size is not too big: A product backlog item needs to be completed within the timespan of a single sprint. Where some units of work seem to be inherently too big for this without awkward or expensive partitioning, Kanban may be a better choice. Note, though, that requirements often arrive in large units of functionality, and learning to break stories down to consumable size can take practice.

Work items are practical to estimate: It’s important in Scrum to be able to know enough about an item of work that it can be sized to a reasonable approximation before scheduling. Relative sizing methods are generally used for this, and they deliver good results. Another approach to this is to break stories into units that are so small they are all about the same size and can simply be counted. One type of work unit for which either method is problematical is the defect. In the general case it’s notoriously difficult to know ahead of time even the approximate size of the job of resolving a given defect. Defect flows are difficult to accommodate within a planned Scrum backlog, but sometimes this is desirable or necessary in order to keep the fix responsibility with those who generated the issue.

And when the organization is ready for a significant step: Succeeding with Scrum can require significant shifts in role expectations, management style, planning, requirements definition, and the working relationship between a software development organization and its business stakeholders. To help you implement Scrum, check out our Scrum board templates. 

Kanban is Good When…

There is a continuous flow of work item input: The continuous flow of work through a Kanban team is best matched by a continuous flow of arriving work requests. This is often different from the large batch arrival of work typically seen in larger projects, which may be more suited to a Scrum context.

Work items tend to be:

• Smaller and/or repetitive: Although a workflow of items of this kind can be handled in Scrum, a Kanban flow seems ideal for maximizing throughput in this situation. Control chart analysis will yield better predictability when items are repetitive or similar than when the workflow has a lot of variation. Predictability is key to being able to establish service level expectations with stakeholders.
• Bigger than a sprint and hard to partition: In some situations it may not be possible to break stories down into small units that can be completed within a sprint. These can be handled in Kanban without process stress. Note, however, that many items that look big have simply not been split yet. Also, if your workflow items persistently range over a considerable range of sizes, consider segmenting them into classes for metrics purposes.
• Emergent, date-driven, or expected quickly rather than at sprint boundaries: Very quick turnaround is not natural to Scrum, where planning and delivery occur at intervals of a sprint length, typically 1 to 3 weeks. Kanban is oriented to delivering items immediately as completed. Emergent date-driven items can easily be given priority in Kanban, whereas this can be achieved but is less natural in Scrum. 
• Subject to rapidly shifting priorities: Changing priorities is difficult on short notice in Scrum, where plans are expected to be firm for the duration of a sprint. In Kanban, it is easy to shift priorities in an intake queue; there is no pre-commitment to the next work item to be started.
• Difficult to estimate: Defect flows, for example, due to the typical uncertainty within many or most items, are difficult to schedule in Scrum but easy to handle in Kanban. Kanban does not require planning based on an estimate of size or duration.

And when organization change needs to be taken in small increments: Kanban is less prescriptive than Scrum. In some cases it may be more practical for an organization to begin with a Kanban approach built closely on existing practices, then gradually apply improvements as the bottlenecks in the workflow become visible.

Conclusion

Scrum and Kanban can be mixed and blended to suit your needs. There’s no need to be limited to a single tool. Once you understand how these frameworks deliver value, you can be creative in designing a solution to meet your needs.