Tachometer to find perfect flow

How do you obtain a ”perfect flow” of work tasks passing through your software development team? That question have been in my head for quite some time. I can start by admitting that I don’t have a solid answer to that question (yet). However, I have instead thought of a way to visualise if you are having ”perfect flow” or not. How? I’m thinking of a tachometer!


Tachometer to find perfect flow

First of all, this is just an idea that popped into my head (this is actually the first encounter with the ”outside world”, so please bear with me). The idea is however to use a tachometer to indicate ”perfect flow” on a kanban board for a development team. Just like a tachometer is indicating if you are using the sweet-spot of your engine at any given moment.

My little example is a kanban board with three columns:

  • Design – Given the value 1
  • Development – Given the value 2
  • Test – Given the value 3

The values are used to calculate the position of the needle in the tachometer. I will now give you three examples that hopefully explains it all!

Example 1 – ”Too early”


In this example three tasks are in the ”Design”-column, giving a ”tachometer value” of:

1 + 1 + 1 = 3

Thus indicating that we are ”too early”, and that the later steps in the flow (”Development” and ”Test”) are not utilised. The analogy with a car would be to ”gear up” meaning that the team needs to take the ongoing tasks to the later steps of the process.

Example 2 – ”Too late”


In this example three tasks are in the ”Test”-column, giving a ”tachometer value” of:

3 + 3 + 3 = 9

Thus indicating that we are ”too late”, and that the team soon will run out of things to do. The similarities with a car would be to ”gear down” and for the team to put focus on feeding in new tasks to the kanban board.

Example 3 – ”Perfect flow”


In this example the three tasks are evenly spread between the columns, giving a ”tachometer value” of:

1 + 2 + 3 = 6

Thus indicating that we have a ”perfect flow”, and that the steps in the process are utilised in the best possible way!


I understand that the mathematical formula behind this idea must be improved if this should become a reality. There are also cases where a tachometer like this will not be useful, for example if the team has just started. Maybe this can act as a challenge to manufacturers out there of digital kanban tools to add a tachometer in their product!

All the best,
Tomas from TheAgileist

Planning with multiple timelines

You should all know by now that I’m very fond of visualisations, to say the least. 🙂 Recently I’ve told you about how we did a ”retrospective with timeline”. That thought stayed in my mind when we needed to do some more detailed planning for multiple projects spanning multiple products. This blog post describes what we came up with. Here we go!


The idea is simple, the timelines highest up on the whiteboard are projects (or larger initiatives, whatever you like to call them). The other bottom half (or whatever suits your needs) are products or components within a product (depending on the level of details you want to plan for). Usage:

  1. The project timelines shows major activities and milestones. I.e. ”hard facts” that we need to consider. For example a promised customer delivery.
  2. The product (or component) timelines shall show activities (work that needs to be done) and is used to find, and sort out, dependencies (”To deliver project X on time, we need to do activity 1 in product A, before we can do activity 2 in product B” and so on).
  3. Color coding. The activities needed in products (components) have the same color as the project that need them to create traceability.


Before the actual planning meeting, you need to find a suitable whiteboard. The larger, the better. Preferably the largest one in the office! But think carefully, you may want to spend some time doing your plan, and therefore keep it up on the whiteboard for some time after the meeting to be able to make adjustments. At least I did, so I found one in a meeting room that is seldom used and started drawing.

Planning with multiple timelines

This is how the “planning with multiple timelines”-meeting was performed.

  1. Some 15-30 minutes before the meeting started, I went to the meeting room and draw the timelines for the projects that we needed to plan (with major activities and milestones). In our case two projects (larger initiatives) and two other activities that were more like dependent on the outcome of the planning. This acts as the starting point for the planning, i.e. things that we intend to deliver.
  2. The meeting started with me explaining the procedure (described above). Then the actual planning started. An example: ”We have promised to do this in that project, for that to work we need to add this in product A and that in B. Wait isn’t this needed in product C as well? Hmm, it is, maybe we should do that first then.” and so on. In this step you can spend as much time as you like, depending on the level of details you want to discuss, and the complexity in what needs to be done. The more dependencies you have the longer time to solve them out. Actually we had one first meeting to get an overview of everything, saving the details for later sessions.
  3. After the planning meeting I always take a picture of the whiteboard using my mobile phone for documentation and the possibility to communicate the plan outside of the room.
  4. As mentioned in a previous point you may want to revise your plan. Preferably you may want do it regularly as long as the projects are running, or you do it in the beginning in a couple of sessions to ”set out the course”.


This is an example of a whiteboard with multiple timelines for planning.



Ok, that was some thoughts and examples on how you can use multiple timelines for planning. If you don’t have several projects (or initiatives) running simultaneously, or you don’t have a complex flora of products you don’t need this. One possible enhancement I can think of is to use a digital whiteboard tool, to be able to keep the plan stored and also to distribute it easier. But for our needs a good old whiteboard suited us just fine. Don’t make things more complex than what they have to be, remember that!

If you don’t like this at all, it feels to much like “MS Project all over again” (however I don’t agree, the key is in the interaction between people to find out dependencies in front of the whiteboard) you can use my other idea for ”visual planning”.

All the best,
Tomas from TheAgileist

The Circles – Products´ lifecycle visualization

Before the Summer I introduced the “Circle of Life” to my teams, a way to visualize the whole lifecycle for products. How did that go?

Background and introduction

The first (and most obvious) comment was that they didn’t understand and wanted me to explain more. This type of visualization is quite rare, I have not seen or heard about it anywhere else in the Agile community. Teams are used to work with boards (Scrum and Kanban) for their short-term work. This is a visualization that is much more long-term and therefore questioned. After that I have explained more, some saw the benefits and others didn’t (someone even thought it was a complete waste of whiteboard space…).

However, one person thought it was good but needed a representation of time, a timeline if you like. I remembered an old idea, the “Product radar” with circles. The circle closest to the middle represents “now” and circles further out from the middle represents “later”. I combined the two visualizations on top of each other and The Circles was born!


The Circles

The metaphor I was looking for are the tree rings seen when sawing off a tree trunk. They surely represents time! In the following paragraphs I will introduce the concepts and functionality of The Circles.

Post-its usage and colors

Try to use the same color on the post-its to group ”product families” together. Put up intended releases, with version number and intended release date, on smaller orange post-its on your products (I cut them to that size with a scissors).


We have a number of products in the example above going through different phases. Some products are ”young” and in the early phase of their lifecycle, while others are ”old” and phasing the end of their life. The way you work with them is really different depending on which phase in the lifecycle they are.

We have divided The Circles into three different phases:

  1. Build-up – Your product is brand new and you have started to build it up. You add feature by feature to make it compelling to your customers out there.
  2. Serving – Your product is so ready that you can start to make money on it, you have your first customer! You continue to add functionality to attract more customers to make even more money. You want your product to be in this phase as long as possible!
  3. Retirement / termination – For some reason it’s time to retire your product. You take it off the market, minimize the maintenance, and migrate over customers to other (new) product(s).

Movement and timespan

How does the products move within The Circles? We have set up the following rules:

1st Customer – When the product have the first customer, it moves into the ”serving”-phase.

End of Sales – When we stop selling the product, it moves into the ”retirement”-phase.

Products with releases that are planned in the ongoing quarter are placed in the “inner circle”. Things for the next quarter are placed in the “middle circle”. Product releases for the next half year are placed in the “outer circle”. This way we can visualize all product releases for a full running year! You can of course alter the timespan to suit your needs.  


This is the current version of The Circles we have visualized inside our “control room”. As you can see (with sharp eyes) we have also added team avatars (magnets) to high-light which team that is working with which product/release.  



No-one is questioning The Circles anymore! To discuss and update it is a natural and appreciated thing we do on our weekly planning & prioritization-meeting. Would you like to try The Circles? I would love to hear more about your implementation and don’t hesitate to contact me if you have any questions!

All the best,
 Tomas from TheAgileist

Circle of Life – Products life cycle visualization

Recently I re-watched ”The Loin King” with my kids. It’s a truly remarkable film! Do you remember the theme song? It’s called ”Circle of Life”, written and performed by Sir Elton John. The song, and the scene where it’s played, really effected my and I have had it in the back of my head for quite some time now.

Last week I visited ”Agila Sverige 2016” (”Agile Sweden 2016”), that is an agile conference that I have attended and written about before. I promise to write more about this years conference, but first I really need to tell you about an interesting open space called ”Visualizations for the organization” hosted by Jimmy Janlén (@JimmyJanlen) that I attended. One participant tried to remember a visualization for products she had seen at a company she visited, but she didn’t quite remember. It was some kind of spiral.

The idea to visualize the whole life cycle for software products, together with the song kept ringing in my head when I went home from the conference dinner. Just before I got into bead it hit me, it should be a ”circle of life” for products!


Circle of Life


We have a number of products in the example above. Some products are ”young” and in the early phase of their life cycle, while others are ”old” and phasing the end of their life. We have up until now, not visualized this in any way. We have seen the products equal, but the way you work with them is really different depending on which phase in the life cycle they are.

To make it simple, I have divided the circle of life into three different phases:

  1. Build-up – Your product is brand new and you have started to build it up. You add feature by feature to make it compelling to your customers out there.
  2. Serving – Your product is so ready that you can start to make money on it. You continue to add functionality to attract more customers to make even more money. You want your product to be in this phase as long as possible!
  3. Retirement / termination – For some reason it’s time to retire your product. You take it off the market, minimize the maintenance, and migrate over customers to other (new) product(s).

Maybe you want to have more phases in your circle, that is totally fine!


How does the products move in the circle of life? You have to set up some rules for moving between phases. For example:

  • 1st Customer – When the product have the first customer, it moves into the ”serving”-phase.
  • End of Sales – When you stop selling the product, it moves into the ”retirement”-phase.

Usage and colors

Try to use the same color on the post-its to group ”product families” together. Put up intended releases, with version number and intended release date, on smaller orange post-its on your products (I cut them to that size with a scissors).

First example


Here is our first attempt on the circle of life. Maybe we’ll improve it along the way.

Other visualizations

Ok, so you like the idea to show the life cycle for your products, but not the visualization with a circle? Here are some more ideas for you!


I think this could be the visualization that the attender tried to remember on the open space.


Maybe you like waves better, and want to speak like ”this is the first wave of product A”; ”this is the second wave of product B” and so on.


Maybe you now have gotten some ideas on how to visualize the whole life cycle for products. As usual, if you have any feedback just let me know!

All the best,
 Tomas from TheAgileist

The Shooting Target – Value kanban board

What is the best way to visualize value? That question has been bugging me since I finished reading ”The Nature of Software Development” by Ron Jeffries. I first started to think about numbers. That 9 is more than 3, and thereby represents a ”higher value”. Instinctually I came to think of a shooting target.


Maybe the simplest and most commonly known variant of a shooting target is the one that goes from 1 to 10 points. Where 1 point is the lowest score in the outmost biggest circle, and 10 points is the highest score in the little center circle. I think many Swedes have used this type of shooting target in their country houses when they have been throwing darts (or ”kasta pil” as we say in Swedish).

Three ways to use the Shooting Target

I have come up with three possible ways to use the ”shooting target”-visualization. Maybe you can come up with one of your own?

Kanban board for multiple teams


There is a lot of information to take in from the picture above. Let me help you walk it through! Here we go:

  • ”Circles” – Each circle represent a phase in your process (columns in a ordinary kanban board). In this example we see, going from the outside into the circle in the center; Ongoing, Analysis, Design, Dev. (for Development), Test and Done.
  • ”Lines” – The longer lines that goes from outside the ”shooting target” and into the middle is delimiters to separate teams. In this example three teams are present, called: Team A (top left), Team B (top right) and Team C (bottom)
  • ”Slices” – The dotted lines represents ”slices” that corresponds to what is called swim lanes on a ordinary kanban board. In this example Team A and Team B both have two ”slices” (or swim lanes), whilst Team C have four. They are used to limit WIP (Work In Process). How many should you have for a team? It depends on the size of the team and how much flow efficiency you want to have.
  • Expedite (Fast lane) – From the top (urgent things usually comes from the top, right?) there is a ”fast lane” for urgent matters. It could for example be preparations for a sales demo. Members from any team can be reassigned to help out with this urgent work. 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.

Stop starting, start finishing

There is a motto ”Stop starting, start finishing” that I first read about in the excellent book ”Kanban In Action”. It means that we want to finish work we have ongoing, before we start anything new. I.e. we value ”close to be finished” work higher than work that is barely started. It’s very common in software development to have too many things going on at the same time.

With the visualization of the ”shooting target” it is very easy to see work that is close to be finished, since it is closest to the middle. Just started work is out in the periphery.

Team score

To take the analogy of the ”shooting target” even one step further we can give the different circles, different score. For example:

  • Analysis = 2 points
  • Design = 4 points
  • Development = 6 points
  • Test = 8 points.

Done is fictively 10 points, but is not used for calculations, see more below. Now the team can start to use this to calculate a ”team score” to work towards better flow efficiency. Some more samples in which all of them he team is currently working on three stickies:

  • Scenario 1 (”score too low”) – Two stickies in analysis and one in design, giving a ”team score” of 2 + 2 + 4 = 8. As you can understand it will take a while before any work is completed and ”delivered to done”. We have a team score that is ”too low” for good flow efficiency.
  • Scenario 2 (”score too high”) – Two stickies in development and one in test, giving a ”team score” of 6 + 6 + 8 = 20. Work will soon be completed but after that there is nothing more coming. We have a team score that is ”too high” for good flow efficiency.
  • Scenario 3 (”perfect score”) – One sticky in analysis, one in design & one in test, giving a ”team score” of 2 + 4 + 8 = 14. We have a team score that is ”perfect” for flow efficiency!

I hope you get what I’m after. The discussions should not be around the exact team scores, but to trigger information to the team (”We have a high score, meaning we will soon run out of work, we better do something about it”). The ”perfect score” to aim for will be within a range (between X and Y). The team will have to experiment to find this out. I guess this ”team score” can also work as a sort of WIP limit.

Visualize Value

In Ron Jeffries book it is said that we shall focus on value and that ”value is what we want”. That is very good, but I’m struggling to make it more concrete. What I first want to do is to determine value, then visualize it.

Determine value

How do you determine value? I think it is very subjective and individual. Different stakeholders will have different views. For example an administrator would get delighted over the possibility to sort his favorite search, whilst the executive gets excited if the product is twice as fast as the competitors (or whatever other examples of what they want). 


The picture above presents a theoretical model to calculate value. Two simple principles are presented below.

1. Criteria/parameters given a score

Parameters #1, #2 and #3 are given a score between 1-3.
Example: 3 + 1 + 2 = 6

2. Weighted values

Maybe you think criteria #1 shall count more than the other, then you can use weighted values.
Example: (3 x 2) + (1 x 1) + (2 x 0,5) = 6 + 1+ 1 = 8

What parameters should you use? It’s all up to you and your business. It could be something like:

  • ”Business value” (how well the business is appreciated; gain marked share, save cost etc.) – Scoring 0 – 3 points
  • ”Customer value” (how well customers are appreciated – killer feature that give them competitive advantage etc.) – Scoring 0 – 3 points
  • ”Technical value” (how well the people are working with the product is appreciated – cool new technique, reduce technical debt etc.) – Scoring 0 – 3 points
  • ”Gut feel/magic wand value” – A feeling that ”this is something we must do” can be rewarded this ”extra point” to overrule the other 3 so to speak – Scoring 0 – 1 point

Visualize value

Now you can rank your features/stories using these variables, then you can visualize them on a ”shooting target” (score from 1 to 10). For example:

  • ”Super feature” = 3 + 3 + 3 + 1 = 10 points (maximum, this feature will be in the ”bulls eye”)
  • ”Medium feature” = 1 + 3 + 1 + 0 = 5 points (will be done, but later)
  • ”Mediocre feature” =  0 + 0 + 0 + 0 = 0 points (why do we even bother about this? Remove or discussed a renewed scope to gain value!)

The team starts to works with things that are in the bulls eye (center), that has the highest value. Value decreases further away from the middle (just like a ”shooting target” scoring from 1 to 10).

Ordinary kanban board

The ”shooting target” visualization can of course also be used for one team as their regular, however cooler, kanban board! Take a while to think how you should use ”circles” and ”slices” described above to build the best ”shooting target” for your team! Use ”slices” to separate between different products the team is working with, or if a large product, between components within the product.


The picture above shows a ”kaizen board” put up on a whiteboard, with three steps: To-Do, Doing and Done. It is used to keep track of continuous improvements in three teams + one ”slice” for common / generic improvements.


I hope I have given you some new ideas on how to visualize value by using the ”shooting target”. If you have any feedback or comments. please feel free to contact me. Vendors of Kanban tools have found interest in my previous visualizations. My challenge to you now is if you can have the ”shooting target” inside your tool? The concept of ”team score” would be very easy to calculate and visualize within a digital tool!

Did you like this blog post and are interested in my other 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.
  • The Volcano – Is your choice if you have multiple products and multiple teams.
  • Product Radar – Instead of showing your product roadmap along a timeline, why not use a radar?

All the best,
 Tomas from TheAgileist

Trello as ”whiteboard simulator”


I’m very into Kanban and really proud of the visualizations we have made on our physical whiteboards. Nevertheless, I’m curios about online Kanban tools. I follow their development and debate about them on Twitter. One day I saw the following.



I thought for a while, and then it all of a sudden hit me. That’s brilliant! Now I had an idea on how to solve the remote workshop I was planning for! It was at the end of the year, and the annual budget restrictions have made traveling impossible. We had participants from three different locations that needed to attend the workshop. I wanted the workshop to be vivid, I’ve read somewhere that the best form of communication is between persons discussing in front of a whiteboard. Now I had an idea on how to do this, without having all the participants together in the same room.

This is how we did it

First of all, I must explain the one thing that makes it possible to use Trello as a “whiteboard simulator”. That is the automatic update function. If I move a card on my laptop screen, that update is shortly thereafter visible on the screens of the others looking at the Trello board. This happens without any form of manual reload or refresh. It also works in the iOS and Android clients.

Second, you must of course have some kind of sound for your meeting participants to complement the Trello board. For example Skype or a phone conference.

Third, make sure all meeting participants are on Trello and can see your ”whiteboard simulator” board before the meeting. You don’t want to spend valuable meeting time on technical connectivity issues.



As for any successful meeting, proper preparation is needed. When I use Trello as a “whiteboard simulator” I prepare two things:

  • Lists – The lists shall represent some initial structure of the topic to be discussed. In the example I’ve provided, the discussion should be about product requirements. It made sense to have a list for ”Business requirements”, and another for ”Technical requirements”. One list is used to store action points that comes up during the discussion, I call that list ”Further actions”. If a card can be ”closed” on the meeting, it’s moved to the ”Done” list.
  • Cards – To get the discussion going, you can provide some cards (sub-items)  to begin with. It should be the obvious ones, to use as starters. I put them in a own list called ”To discuss”.

One other good thing to think about before the meeting is the following two roles:

  • ”Discussion facilitator” – One person that facilitate the discussions.
  • ”Trello updater” – One person that listens to the discussions and update the Trello board to reflect it accordingly.

The two roles can be handled by the same person if he or she can handle that. To keep flow in the discussions though you want to avoid pauses for updating the Trello board. If that can happen ”seamlessly”, it’s to be preferred.

During the meeting


During the meeting the ”Discussion facilitator” talks much and try to steer the discussion with the other participants. For example: ”Have we thought about this requirement? No, so let’s add it as a technical requirements then”. The ”Trello updater” then adds cards to the Trello board accordingly. But also to move the cards around, update them with comments, sets labels (color marking), add members (avatars) to show responsibility etc.

After the meeting


If you have played your cards well (pun intended) before and during the meeting, there is not so much to do afterwards! No protocol is needed since the discussion have been captured on the board. Further action points should also have been made as cards. What you may want to do, is to move or copy the “action point “-cards from the ”Whiteboard simulator” board to a ”Project board”. This is very easy using Trello. You just select a card, choose move or copy and put it on the destination board.

Advanced option (to create hierarchy or dependencies)

Shortly after I published this blog post Cristiano Basso (@csbasso on Twitter) reached out to me. He wanted to inform me that it’s also possible to link a card to another in Trello. If you click on a card, and use the ”Share and more…”-option, you can copy the link to the card. That link can you put on another card to ”create” a dependency between the cards, or if you want to make a hierarchy between cards. You can either put the link as an attachment to the card, or as part of a checklist as in the picture below.



These are the benefits of using Trello as a ”whiteboard simulator”:

  • Get interactive meetings even with remote participants.
  • No protocol is needed afterwards, it has already been done during the meeting and is visible to all participants.
  • No action points needs to be prepared after the meeting, they have also been done.
  • It’s very simple to get started.

The disadvantage is of course that you can’t draw pictures as on a physical whiteboard. However, pictures in digital format can be added as attachments to cards.


I hope I have convinced you of a new usage of Trello as a ”whiteboard simulator.” Let’s try it out on your next remote workshop and get back to me with your feedback! Also, I do think Trello has a lot more to offer apart from being only a “whiteboard simulator”. Maybe I will come back to that in later blog posts.

All the best,
 Tomas from TheAgileist

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