How to Manage Features and Epics 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 Agile 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):

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.

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 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.

Wait time
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.

Block time
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

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 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.

Scenario 2: All User Stories Can Be Executed in Parallel.

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.

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 Kanban 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 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 known 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.

In Summary

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:

• Improve process cycle efficiency
• Distinguish and measure data more precisely for different workflow structures
• Identify blockers that slow down the whole work process