"What is the status?" - a question that managers always hear. Find out how to answer it by learning how the flow of portfolio epics is managed in Kanban.
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 in the image below:
Having this setup helps a great deal with visualization and transparency, but a big issue 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 about 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?
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.
A very brief definition of flow efficiency is “the ratio between value-adding time and the total cycle time”. Value-adding can be defined as 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 to traverse 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
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.
In this scenario, any delay in starting the consecutive story immediately after the predecessor has been completed is a wait time. Also, blocks in any of the user stories directly affect the cycle time of the entire Kanban 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.
Ideally, in this scenario, the entire Kanban epic's cycle time 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 user story's ideal cycle time with the biggest cycle time.
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:
Imagine a real-life scenario where an RnD department works on 50+ Kanban epics. These epics are broken down into 200+ user stories. These 200 stories are being worked on by 5+ teams. This is a tough 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.
Tracking and managing flow efficiency globally is an important prerequisite for successful and efficient work processes. Measuring flow efficiency on a Portfolio Kanban level allows you to:
During the 30-day trial period you can invite your team and test the application in a production-like enviroment.