In a typical portfolio Kanban implementation, the Epics live on a portfolio Kanban board and are being broken down into user stories that live on separate, team Kanban boards.
For example, we can have a single Portfolio Kanban board and three team Kanban boards – Development team 1, Development team 2 and Development team 3. A sample structure is shown on the image below:
Having this setup helps a great deal with visualization and transparency, but there is a big issue that is often overlooked. One of the biggest problems occurs a bit later in the process and it’s a form of waste called “scatter”.
Scatter can be defined as the actions or inactions that make knowledge and information ineffective by disrupting its flow.
What does this mean in reality? In nine out of ten companies, team 1 won’t know what team 2 or team 3 are doing. Teams usually operate in silos and they rarely have information what happens outside of their bubble.
This is not going to be a problem if the teams work on different Epics, but as soon as two or more teams start working on the same epic, things change dramatically, almost always for the worse.
Imagine a situation where four teams work on the same Epic and each team has to contribute one story. If you go ahead and measure the cycle times for each story and compare it to the cycle time of the epic, you will almost always discover something like this (not real numbers):
|User Story #1||12 days|
|User Story #2||7 days|
|User Story #3||9 days|
But wait! How come the sum of the user story cycle times is 28 days (approximately 1 month), but the Epic took 4 months to complete?
Well, this is scatter – information and knowledge are so dispersed across the teams, that the flow on the Portfolio Kanban level is disrupted.
These are often synchronization issues, miscommunication, a lot of expedited stories and so on. To tackle this issue, we need to look into a metric called Flow Efficiency.
What is Flow Efficiency?
A very brief definition of flow efficiency is “the ratio between value-adding time and the total cycle time”. Value-adding can be defined is any non-waiting, non-blocking time. To make things simpler, let’s take this example:
If you need 8 hours to complete a certain task, but you work on it only for two hours during the day (value-adding time), then the flow efficiency would be 2/8*100 = 25%.
Process Cycle Efficiency[%] = Value-added Time / Cycle Time*100
We mentioned non-waiting and non-blocking times, so it makes sense to define them too.
The time a given card on your Kanban board spends waiting on something. Waiting is one of the most widespread sources of waste in most companies.
The time a given card on the Kanban board spends in a blocked state. A card is blocked, when it cannot proceed traversing the workflow for some reason. A typical scenario would be a defect, lack of hardware resources, lack of team capacity, etc.
To accommodate for the block time in the formula above, we should note the following:
Value-added time = Cycle Time – Wait Time – Block Time
Flow Efficiency on the Portfolio Kanban Level
The formula for calculating flow efficiency on the portfolio level is still the same. However, the definition of wait and block times changes.
Calculating wait times becomes a bit more complex, because we have different scenarios, depending on whether the user stories can be executed in parallel or not. Let’s examine the different scenarios one by one.
Scenario 1: All user stories have to be executed sequentially.
In this scenario, any delay to start the consecutive story immediately after the predecessor has been completed is wait time. Also, blocks in any of the user stories directly affect the cycle time of the entire epic, so it is also considered block time for the epic.
Any wait time on the user story level accumulates wait time for the entire epic, so it is considered as wait time too.
Scenario 2: All user stories can be executed in parallel.
Ideally, in this scenario, the cycle time of the entire epic should be equal to the cycle time of the biggest user story. So, non-value adding time would be the time between the actual cycle time of the epic and the ideal cycle time of the user story with biggest cycle time.
Scenario 3: Some user stories cannot start before others, but some can be executed in parallel.
In practice, this (and its variations) is the most common scenario. Calculating wait times here is similar to the concepts of critical chain project management (CCPM). These are the different cases:
- Any delay starting a story, which cannot start before another one is completed is considered wait time
- Any block on a non-parallel story is considered block time
- Any block on the biggest parallel story is considered block time
- Block on a parallel story, which is not the biggest one, might or might not be considered block time, it depends on whether it can “hide” behind the biggest story or not.
- Any wait time on the user story level accumulates wait time for the entire epic, as long as they are on the “critical path”.
Why is Flow Efficiency Important on the Portfolio Kanban Level?
Imagine a real-life scenario, where a RnD department works on 50+ epics. These epics are broken down in 200+ user stories. These 200 stories are being worked on by 5+ teams. This is a really hard situation to manage and most of the time, nobody knows where things are and why they are taking so long to complete.
If we are not managing for Flow efficiency on the Portfolio Kanban level, then a team can start the first story of an Epic, while another Epic could have been finished, had the team knew about it.
The lack of synchronization on the portfolio level can lead to monstrous inefficiency and delays. That is why, when we manage for Flow efficiency on the portfolio Kanban level, we can easily gain 300% improvement and sometimes even more.