Let's start with a basic Kanban board with items nicely flowing through. The team grows, the product evolves and it becomes harder and harder to see the big picture and align strategy with day-to-day execution.

In Jira, there are company-managed and team-managed projects. We love team-managed projects for their simplicity and empowerment of autonomous teams that don't depend on a Jira Administrator. However, there are caveats and one of them is the inability to view Epics on Kanban boards (same for Sprint boards).

Still, you can use Epics in the backlog as a "container of items" and probably will end up with many of them stuck in "ToDo" or "In Progress" status because there is no flow of Epics. The name doesn't really matter, it can be an Epic, or preferably something that is more customer or business-friendly.

Another place to use Epics is Jira Portfolio. But not only it doesn't solve the problem it actually makes things even worse -- the introduction of "artificial" due dates that aren't aligned with actual delivery capacity sets incorrect expectations. Let's just stop here.

As part of our advanced Kanban Boards, we introduced the ability to display Epics as an actual item in team-managed projects.

As we can see, it becomes evident what is going on on a higher level. Most likely, for the first time, there will be too many items because nobody ever resolved any Epics and you will need to do some cleanup.

What the flow of epics gives us? A bigger picture plus all the benefits of Kanban.

For example, work in progress -- teams can't work on everything simultaneously. This view should lead to a reduction of WiP. As we know, in stable systems, the lower the WiP, the higher throughput and/or shorter lead time. This is even more important at the Epic level than at the team level.

Another implication is an organic (or evolutionary) invitation to clarify what happens before committing to delivery, or in other terms the Upstream Kanban.

This is where you may want to explore the steps from the "raw idea", to a defined set of outcomes, to something that can go to delivery/implementation. At this stage, an often scenario is to break down the work into smaller pieces.

What is really important with Upstream is that it clarifies the desition making process, where raw ideas (options) get a little bit of "shaping" just enough for stakeholders to decide whether to commit resources or not (not now or even never) which results in greater effectiveness.

We should mention backlogs here. A short buffer is okay, an endless "black-hole" kind of backlog that only grows and emits a little bit of "radiation" is not. Remember, we are looking for the flow of Epics, not a static list.

To put it back into practice, from a flat workflow like this

it may evolve into something like

Whereas at first stages you work more at Epic-level and then break it down into smaller items deliverable within days or weeks.

Note a single end-to-end workflow, which is generally better than multiple boards because everyone can see the whole picture and stay on the same page. In case you are getting worried about the length of the board: just collapse the columns that you don't want to see 😀.

To summarize, this technique allows scaling Kanban systems vertically with Epic hierarchy and horizontally with Upstream and flow of Epics.