It is always a challenge to make the correct priorities! Which one of work A, B or C shall you do first, and why? We have been using Kanban for some time now, and have found out that visualization is the key to get the priorities straight. Gradually when we have grown our Kanban initiative, the need has emerged for a solution that could serve both multiple products and multiple teams. One day we introduced ”swim lanes” inside our priority pyramid and cut off the top and The Volcano was born!
Benefits of The Volcano
The benefits of The Volcano are 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.
- Visualize capacity allocation between different products.
- Visualize priority between work in different products. Individual positioning of the stickies can for example show that two Product A stickies are more important than the highest for Product B.
- It is an enterprise kanban board that can cover the whole value chain of a company.
A disadvantage of The Volcano is that it requires quite a lot of whiteboard space. We are using three normal sized whiteboards (1.4 x 1.6 meters) placed together on a wall in our “control room”. It can also be tricky to implement The Volcano in a online Kanban tool, but I know that it’s possible in at least some of them (for example in Favro).
Let’s look at the actual volcano in the middle
Work priority levels
The Volcano is horizontally divided into three separate priority levels:
- ”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 working on it, for example by including a clear and understandable DoD (Definition Of Done). A set of criteria should be fulfilled (like specifying a DoD) before moving work into ”next”.
- ”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 up to the ”next” state, it has to be prepared as stated above.
- ”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.
Priority and capacity allocation between products
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 a work item and a ”swim lane” is free (capacity available), a new 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.
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). Let’s 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, maximum one per week etc.
Columns (the process steps)
The steps (columns going vertically) presented in the picture are Analysis, Design, Development, Test & Done. 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. This is called mob programming. This may or may not be practical in reality, the risk is that some 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).
DoD (column criterions)
Each column/step in the process has a written Definition of Done (DoD) with the criteria 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:
- Person A: ”Have you tested this?”
- Person B: ”Yes, yes.”
- Person A: ”Have you written any automated test cases?”
- Person B: ”Hmm, well no…”
- Person A: ”Please write the automated test cases before we can move this task further.”
How to operate The Volcano
These are the steps needed for working with The Volcano:
- 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 ”Next”-section.
- When a team complete a story (capacity is available) they ”check out” a new one from “Next” and move it to the empty ”swim lane” as an ”ongoing” activity. It will be an empty spot in “Next”, but that doesn't matter, as long as the meeting in 1) is held regular enough, not to let the whole “Next”-section become empty.
- 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.
Learnings
Here are some acquired knowledge after using The Volcano:
- We are using The Volcano in combination with a visual plan. The visual plan covers our main product. The visual plan is discussed regularly (weekly) and then work is fed into 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, for us 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 favoured.
- 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.
Summary
I hope you by now have a better understanding of what The Volcano is and how it’s operated. It is a great tool to prioritize work for multiple teams working with several products. If you are interested in more of my visualizations, you can find them here:
- 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.
- Product Radar - Instead of showing your product roadmap along a timeline, why not use a radar? Things that are close to the center as almost certain that they will become available in your product in the near future.
About the Author
Tomas Rybing lives in Stockholm, Sweden and has been working in IT since 1996, starting as a consultant and programmer. From 2007 his focus has switched to team leading, project leading, product management and development methods. He has a wife and two kids. His main interests are sports, music and traveling. You can reach Tomas via his email, blog or twitter handle.