The Volcano – Enterprise kanban board

We have been using Kanban over a year now, and things are really progressing well. I have written two previous blog post about our visualization work, and they have both become very popular:

  • Priority pyramid – Is a great way to prioritize your personal work, or to be used for a small team.
  • The Arrow – Is the ideal way to go if you have one product backlog and one team.

Gradually when we have grown our Kanban initiative, the need emerged for a solution that could serve both multiple products and multiple teams. I thought for a long time on how to solve this, but I couldn’t really come come up a good visualization. A colleague of mine kept saying that priority must be ”from top to bottom” if it should work (i.e. done vertically). That kept ringing in my head. One day it just hit me, why don’t have ”swim lanes” also inside the pyramid? We cut off the top of the pyramid, and The Volcano was born!


An introduction to The Volcano

The purpose of The Volcano is the following:

  • Prioritize work for multiple teams.
  • Prioritize work for multiple products. In the picture above three ”swim lanes” are present for Product A, Product B & Product C.
  • Indicate capacity allocation between different products.
  • Indicate priority between work in different products. Individual positioning of the stickies can for example show that two stickies for Product A are more important than the most important for Product B.
  • Can visualize a futurelog.
  • Is an enterprise kanban board that can cover the whole value chain.

Zooming in on the actual volcano in the middle


The Volcano is horizontally divided into three separate priority levels:

  • ”P1 – Next” – In this level work is placed that are ready for the teams to take on as the ”next” thing to do. The work must be prepared and in such a state that a team can start to work on it, for example by including a clear and understandable DoD (Definition Of Done). A set of criterions should be fulfilled (like specifying a DoD) before moving work into ”next”.
  • ”P2 – Soon” – In this level work is placed that shall take place ”soon”. It could be plain text with ideas on the stickies. However, for work to move on to the ”next” state, it has to be prepared as stated above.
  • ”P3 – Later/Maybe” – In this level we place work that may or may not be done ”later”. As we do in the  ”soon level” there is no need to specify this work in detail, it is kept here as a wish list or to not forget about it.

The volcano is vertically divided into ”swim lanes”, one for each product it should support. The width of the ”swim lane” is used to steer capacity allocation between the products. A narrow ”swim lane” indicates low capacity allocation, while a wide ”swim lane” indicates high capacity allocation. In the picture above all ”swim lanes” have the same width, indicating that the three products have the same capacity allocation.

The work flows out of the volcano (shown by the four arrows in the picture) and into the team’s respective kanban boards. When a team has completed work and a ”swim lane” is free (capacity available), a work item is fetched from the volcano into a free ”swim lane” as an ongoing activity. It works best if the work items are of approximately the same size, we use stories (represented by ”larger” stickies). When the team starts to work with a story, they usually call for a planning meeting to break it down into tasks (represented by ”smaller” stickies) that then flows through their kanban board.

How do you initialize the volcano? One way can be to have a visual planning meeting.

Team’s kanban boards


The picture above shows one of the four team kanban boards (in this case for ”Team 3”, but they are all similar). Lets start to look on the board to see what’s included.

Expedite (Fast Lane)

Sometimes the shit hits the fan and the team has to work with something that was not planned. To minimize discussions of the type ”We are working with other things that are not on the board”, this urgent work also needs to be visualized. It could for example be preparations for a sales demo. A dedicated ”swim lane” above the others, is used for this fast lane (to indicate the importance). You should be aware of that putting work here will delay all the other work that are ongoing, so this fast lane shall be used with caution. You should have rules that put limits on the usage of the fast lane, for example only one task at a time in the fast lane, max one per week etc.

Columns (the process steps)

The steps (columns going vertically) presented in the picture are Analysis, Design, Development, Test & Deployment. These columns shall reflect the steps you have in your process (i.e., they may not be the same as in this example picture). How do you find out what columns to use? You have to take a few stories and discuss the way they take through your process.

”Swim lanes”

This example shows three ”swim lanes” per team (lanes going horizontally). The ”swim lanes” are used to limit WIP (work in process). How many ”swim lanes” should you have for a team? It depends on the size of the team and how much flow efficiency you want to have. One ”swim lane” will give you the highest flow efficiency, then the whole team will be working on one story at the time. You can also call this mob programming when the whole team is only doing one thing at the time. This may or may not be practical in reality, team members will be idle. On the other hand, if you have the same amount of ”swim lanes” as you have members of your team, you will end up with a group of individuals working with their own thing, with little or no interest in functioning as a team! One word of advice is to have fewer ”swim lanes” than you have team members to encourage collaboration. We have started with two persons per story and the team holds six team members, i.e., three ”swim lanes” (the same number that this example shows). To limit the number of ”swim lanes” hopefully also gives a mindset of using the capacity of the process with caution. Don’t let a story take up a ”swim lane” if it isn’t ready for it. For example if needed information is not present to perform the analyze, the story will not ”move forward” in the flow, and a ”swim lane” will be ”blocked”. We are wasting capacity.

DoD (column criterions)

Each column/step in the process has a written Definition of Done (DoD) with the criterions that needs to be fulfilled before a task can move into the column. See it as a checklist, this and that needs to be done before moving the task. Using this approach will prevent tasks from moving further down in the process without being ready for it. An example:

  • ”Have you tested this?”
  • ”Yes, yes.”
  • ”Have you written automated test cases?”
  • ”Hmm, well no…”
  • ”Please write the test case before we can move this task further.”

Classes of service (shown beside the volcano in the first example picture)

By categorizing the work into classes of service the kanban board will radiate even more information. In this example three classes of service are used:

  • Green – System improvements (technical or maintenance driven)
  • Yellow – Features (customer or roadmap driven)
  • Pink – Bugs (errors in existing functionality, found internally or by customers)

Policies can be created, for example that X% of the work have to be system improvements. Other things can also be spotted, if the pink stickies (bugs) are dominating we may have a problem with quality, and so on. 

How to operate The Volcano

These are the steps needed for working with The Volcano:

  1. A regular meeting (we do it weekly) with all relevant stakeholders present to discuss the content of the volcano and decide what activities to move into the ”P1 – Next” section.
  2. When a team complete a story (capacity is available) they ”check out” a new from P1 and move it to the empty ”swim lane” as an ”ongoing” activity. It will be an empty spot in P1, but that doesn’t matter, as long as the meeting in 1) is held regular enough, not to let the whole P1 section become empty.
  3. The ”swim lane” of the product in the volcano is completely owned by the product owner. The product owner can at any time add or change the priority of the activities. But only in his or her ”swim lane”. Coordination, priority between activities for different products, takes place on the regular meeting in 1).

The volcano clearly states the difference between the ”what” and the ”how”. The stakeholders (management) decides on what shall be done, the teams decide how it should happen.

In depth details of The Volcano

It’s said that a picture says more than thousand words. So instead of more written text, I have prepared a presentation on how work flows using The Volcano. You find it below:



This version of The Volcano is put up on three whiteboards (1.4 x 1.6 meters). The volcano part in the middle serves four team kanban boards, one to the left, two on the right, and one on the other side of the room (see the arrows coming out of the top of the volcano). The team on the left is actually using a mirrored kanban board to fully visualize the flow of the work out from the volcano and in and through their kanban board :).

Here are some learnings after using The Volcano for some time:

  • We are using The Volcano in combination with a visual plan. The visual plan covers one of our products (we have three different products). The visual plan is discussed regularly and then ”feed in” work to the volcano. For another product we have a more formal process with a product owner that fills up that ”swim lane” with work items.
  • The Volcano works best if the work items have approximately the same size (we have a rule of ≈10 working days, corresponding to a story). This makes prioritization easier. You could in theory have features alongside with bugs in the volcano, but then the short term work will probably always be favored.
  • We update The Volcano at least once a week on a weekly planning and priority meeting. It’s very important to find a person that can host this meeting and lead a fruitful priority discussion. It should be someone with mandate and insight in all products. We have not quite got this in place yet, we are still struggling with this.


I hope you now have a better understanding of what The Volcano is and how it’s operated. If you have any feedback or comments, please feel free to contact me. One last thing, maybe you wonder why it is called The Volcano? It is because it’s a priority pyramid with the top cut off that ”shoots out” work to the teams, just like a volcano 🙂

Blog post update:

Here are some comments from the agile community about The Volcano:


All the best,
 Tomas from TheAgileist


  1. Pingback: Volcanizing Kanban
  2. Hi Tomas, thx for this article, really interesting. Do you know any online tool which manage this kind of approach (Volcano, Shooting Target, etc) ? Cause there is many Kanban tools (open source or not) but none with those specificities.


    1. Hello Julien, thanks for your comment! There was an open source project a few years ago (I have forgot the name) that was about to make a more flexible online Kanban board. I don’t know what happened with that. You can visualise parts of Volcano, The Arrow etc. in the online Kanban tools that exist today (using columns and swim-lanes), but it is correct that you can’t get the overview. You should influence the Kanban tool manufacturers to make this happen 🙂


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s