How Kanban can help Scrum teams
We know a lot about Scrum and Kanban, but sometimes we don’t know how to use instruments from other methods to help us. We may think that mixing different frameworks and methods is not about Scrum, and we can disrupt the values of Scrum and Agile by doing it. Let’s prove it wrong.
To start with, what are Scrum and Kanban?
Scrum is a ready-made guide on how to organize iterative-incremental development in an ambiguous environment. All elements of Scrum are interconnected with each other, and when implementing Scrum, nothing can be left out of what is specified in the Scrum Guide. All of these conditions are designed to maximize the best value for launching and maintaining the product.
While Kanban is more like a box full of instruments where you can choose one or all of them, it’s only up to you to decide. Every instrument can be useful for you.
How can these nearly absolutely different approaches can work together and not disrupt everything?
The thing is, when a team implements Scrum and adheres to the values, we can even increase productivity and maturity by utilizing several instruments from the Kanban method and increase predictability, transparency, and continuous self-improvement.
Find and deal with unusual cases
One of the Agile principles says:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Thus, Agile wants us to always go back to our recently completed work and gain some insights that will bring us to the greater good.
Mostly, teams are really doing this on sprint retrospectives, where the team reflects on the recent sprint and tries to find new insights about how to make their work better in different ways.
But what if we go even deeper into the past than one sprint?
How to analyze?
One of the most crucial metrics in Scrum is Velocity. Velocity is a certain number that you should rely on when evaluating the capacity per sprint. To determine this number, we use a Velocity Chart which shows how story points and items were estimated and how many story points were really completed.
Unfortunately, the Velocity chart does not answer the question of how long it took to complete the item; it only shows if the item was completed in a sprint or not.
In that case, it’s hard to reflect on the stories that were not completed by the end of the sprint. Or maybe two sprints. Or even three.
We can call this situation a dysfunction because it’s not a usual case, and normally it should not be repeated on an ongoing basis. And even if you’re sure that this situation will never happen again, it’s still worth a shot to find these items and discuss them with the team.
For instance, you can collect historical data on the execution time of the items for a couple of months. As a result, you will obtain a metric that’s called Lead Time for the Kanban method.
Next, sort those items that were completed in more than a sprint. All the items that fall under this condition are good items to discuss with the team why this is so.
Let’s say we have historical data for a couple of months on completed tasks of the Story type. Based on this data, we can build a graph. The x-axis is the item execution time, and the y-axis is the number of completed tasks.
The graph shows us how many tasks were completed in what time. For example, one item was completed in four days and two items were completed in 15 days. Let’s say that the team has a 2-week sprint as well.
These two items that were completed in 15 days are exactly what we want to bring to the team to understand what’s happened with these items and what we can do about it.
There can be a lot of reasons why the item was not completed since we live in an uncertain reality where everything can change, but this will give you an additional opportunity to reflect on specific items and find new ways to improve.
Improve estimations
Stabilization is the new IT word for 2022 and 2023 as well. Many companies faced that issue, and many teams shifted their focus from making new features to stabilize the existing.
For example, we have two teams: A and B. Both of them are using Scrum properly, inheriting the Scrum values, and working according to the Scrum guide. The first team, team A works on a product with many stories, each of which will bring value to the company; bugs and technical debt practically do not appear in sprints. They can always estimate all the incoming work from their product backlog and take the stories based on their capacity.
While team B works on a product that mostly contains tech debt, they are cutting the monolith structure into microservices and often face bugs in their work. Unfortunately, stories do not frequently make it to the sprint backlog. As a result, the team often fails to meet the sprint goal, the items are rolled over from sprint to sprint, the morale of the team is decreasing.
Familiar situation, right? But how can we help this team make their work more predictable and comfortable?
For example, instead of expert forecasting based on story points, we can use historical data about the work of the team and apply a probabilistic forecasting approach. Using this approach, it is possible to understand your possibilities better.
What is needed to do this?
Firstly, collect historical data about the closed items from sprint to sprint for some amount of time. For example, 5 sprints. The time can range from 5 weeks to 5 months (1–4 week sprints) depending on your sprint timebox.
Secondly, try to understand what type of work the team does the most during the sprint. Bugs, technical debt, defects, or stories are all examples.
Thirdly, you can differentiate the number of completed items by their type and understand how much a team can complete different types of items in the real world. That is, how many bug items the team can do, how many tech debt items, how many story items, etc.
For example, you can see that the team can easily cope with 10 bugs per sprint, but they will not be able to take out the 11th bug. In addition, the team completes an average of 7 tasks for tech debt in addition to bugs, but also cannot complete anymore.
Based on this, the next sprint planning can become more predictable, and the team will not be overburdened with tasks.
Resolve blockers in the product
Scrum itself has a timebox for all the items in the sprint — it’s the sprint itself. But what happens when we do not complete the item during the sprint because of internal or external blockers? Most of the time, we’re trying to reflect on this during the retrospective, but it seems difficult to understand properly how could we avoid this situation?
A blocker is any reason why a team cannot continue working on a task. The reasons may be different — or we are waiting for a response from the customer, or a specific specialist, or an accident, and so on.
Generally, when we bunch into a blocker, most of the item’s lead time is spent in blocked status. The work itself doesn’t take a lot of time compared to resolving a blocker.
While we may believe that each blocker is unique and cannot be reproduced, we may discover that almost all of the blocker’s reasons can be clustered.
For instance, we may collect the data for all the cases when the work was stopped every month, analyze these cases and group them by reason.
As a result, we will have several blocker clusters. It can be external and internal, such as:
- Waited for approval
- Waited for another team
- Waited for the test environment
- Etc.
Why should we do it?
It can help us understand where we get the repeated and systematic issues in the team. As a result, it may lead us to several insights about how to deal with these blockers and help resolve them before they happen again.
All in all, the Kanban method can help Scrum teams at least in 3 ways:
- Find and deal with unusual cases
- Improve estimations
- Gain insights from blockers in the product to revolve it
The main thing is to use the tools correctly and not be afraid that in this way the values of Scrum can be spoiled. When using such tools, we will not spoil the values of Scrum, but on the contrary, we will complement Scrum itself and its values.
In the end, each such item can improve the maturity of the team, improve their predictability, and fix some recurring problems.
