Kanban can help your Scrum implementation

Scrum is a wonderful way for teams to start with product development – or more broadly what the scrum guide describes as “complex” problems or work. It’s worth reviewing the Scrum Guide if you haven’t already – particularly if you’re using Scrum! One of the great things about scrum is that it’s a lightweight framework that you can use. One of the drawbacks about scrum is that it’s a lightweight framework – and doesn’t necessarily describe how you can solve a number of problems teams and organisations tend to face when dealing with complex or even a mix of complex, complicated or simple problems.

This is where Kanban can help so many teams. There is a lot of advice in the Kanban community for how to deal with a variety of problems – many of which scrum teams run into. You can enhance the capability of your scrum team by applying some Kanban over the top of it (given that Kanban applies over the top of your existing process). This article will describe a number of circumstances where Kanban can help your scrum process.

Understanding your process better

Often scrum teams start with a basic board such as the one below:

As you can see, you get a basic idea of the work, but it’s not quite what I’d describe as a Kanban board – just a basic visualisation of work. We can see more details about what’s going on during the sprint when we breakout more detail of the process involved in the knowledge work:

Unbalanced Load

We can now see when a particular part of the process is getting overloaded. A common situation I’ve seen with teams is when in the above example testing gets overloaded. This assumes a two week sprint:

As you can see, there isn’t a very even flow of work for the testers. They are waiting for most of the sprint for the work to get to them and then they get everything within the last few days of the sprint.

However, by applying Kanban’s WiP limit practice over the top of your scrum process, you can start to resolve this problem. In this case we’ve applied a WiP limit of 2 items over development and 2 items over testing :

In this example testing was started much earlier in the sprint and allowed things to move to done more rapidly creating a less stressful situation for the team (as well as better product outcomes).

Understanding handoffs better

Also, given that we’ve outlined the process in a more descriptive way above, we can now have better conversations in our retrospectives about “what does it mean to be done with development”. The scrum framework talks about the “Definition of Done”, but this relates to the process for the Product Backlog Items (PBIs) and not necessarily to the process they take. Creating a definition of done for development can lead to cleaner handoffs with testers, less defects and a smoother transition through the process.

Different types and urgencies for work

As a product matures, or at least after the first release, there’s often additional types of work that the team need to deal with. These can be disruptive to product and sprint goals unless you take them into account and build them into your system of work. This is where Kanban can deal with different types of work and how they relate to each other and the capacity of the Development team. Here’s an example:

Oftentimes, even though we know of a different type of work, we sometimes have different urgencies for work. Luckily, with Kanban we can make our policies explicit with how we deal with these so as to minimise the disruption to our product and sprint goals, but still meeting the customer and market needs.

Work overflowing from one sprint to another

We often see teams that can’t get all of their commitments met or work done during a sprint. Often work overflows from one sprint to another – teams sometimes try to “hide” this with the tooling, closing out the tasks that are not done for the current sprint and creating new ones for the next. It’s best not to do this, however, as it doesn’t really show up you’re problems so that you can deal with them – which really doesn’t align with scrums values around empiricism of transparency, inspection and adaptation. With kanban implementations, we also seek transparency – plus we use metrics to help us improve. Capture the actual lead times of your PBIs and bring them into the retrospective for examination and improvements. Here’s an example lead time distribution chart showing us the items that are keeping us from meeting our sprint and product commitments:

As we say in Kanban, we can look to “trim the tail” of these lead times.

Refinement work creating overload for Product Owners

Another common problem is that the practice of Product Ownership becomes a “dark art” and not very well understood by anyone except the product owner. This isn’t particularly good for a scrum team because the Product Owner becomes a single point of failure in the system of work. Other problems that scrum teams also can experience is starving for work as this bottleneck becomes apparent. You can apply Kanban practices to the Product Backlog and refinement process to help ensure work flows smoothly to the Development team to become realised as a valuable product increment.

Notice how we’ve visualised this process to create the transparency that scrum values. We’ve also defined WiP limits to create the focus that scrum values. Plus we have definitions of Ready / Done through the process so that everyone can see how things are supposed to work – upholding the value of Respect for both the Product Owner and the Development Team.


These are just some of the ways Kanban can help your scrum implementation. In order to improve in this way, you really need to apply the Scrum value of courage: it can take real courage and leadership to make these changes for the benefit of the team and the product. If you want to learn more about how you can apply Kanban to your Scrum implementation, check out our Scrum Better with Kanban course.