Remote Retrospective using Lean Coffee

Do you have any problems with your retrospectives? Is there a few people with “strong voices” that gets their saying every time, talking about what they consider to be the problems, whilst others remain silent (and no light is shred on what they think is wrong)? We had that problem, and it kept me busy thinking for a better approach to perform retrospectives, where we discuss what everyone in the team agrees are the most important.


Lean Coffee & remote team

Since I’ve been attending a few Lean Coffees arranged in Stockholm, I thought that would be a good format to use, also for a retrospective. I fired off some searches on the interwebz, that made me confident that it would work (more information to be found here and here)!

However, there was one more challenge to solve. The team was a remote team, with two individuals not working from the main office. How to solve that nicely? Since I’m a huge fan of digital boards, my solution was a shared board in Favro!


(Digital Kanban board in Favro with four columns: ”To Discuss”, ”Discussing”, ”Done” and ”Actions”)

Introduction to Lean Coffee

If you don’t already know about Lean Coffee, I will now shortly introduce you to that. So, what is Lean Coffee?

”Lean Coffee is a structured, but agenda-less meeting. Participants gather, build an agenda, and begin talking. Conversations are directed and productive because the agenda for the meeting was democratically generated.” –

It was created 2009 in Seattle by Jim Benson & Jeremy Lightsmith. If you happen to be in Stockholm and wants to experience the real thing, you can click here for more information.

How does a remote retrospective using Lean Coffee work?

Preparation prior to the retrospective meeting

  1. In your favourite digital tool (we use Favro), set up a simple Kanban board with four columns:  ”To Discuss”, ”Discussing”, ”Done” & ”Actions”. See the picture above for how it can look like.
  2. Provide access to the digital tool for all the meeting participants.
  3. If several of the meeting participants sit together (in a meeting room), bring a laptop and share the screen on a TV/projector.
  4. Use Skype/Slack/other phone conference solution for audio.

During the retrospective meeting

  1. Generating topics – Each meeting participant starts to write 1-2 sentences on for each topic in the past time period (scope of the retrospective) that they would like to discuss. Either they add the ”stickies” directly to the digital board themselves (using their laptop), or the meeting moderator can take the physical stickies and write them into the digital board, using his or her laptop. Remote participants will of course add to the digital board directly. A set amount of time is spent on this step (like 3-5 minutes for a one hour retrospective). All ”stickies” are placed in the ”To Discuss”-column.
  2. Presenting topics – Each topic is shortly introduced by the one who wrote the ”sticky”.
  3. Dot voting – Each participant is given three ”dots” to freely distribute amongst the topics. On the digital board dots (.) (or better *) can be added after the describing text. For convenance, it’s easier if one or two meeting participants do this at the same time (to avoid conflicts and confusion).
  4. Order the topics – The topics are ordered in the ”To Discuss”-column, most ”dots” comes first.
  5. Start to discuss – The topic with the most ”dots” is selected to the ”Discussing”-column. It’s discussed for 8 minutes (a timer is set).
  6. When time is up, participants vote with their thumbs:
    – ”Thump up” – Continue to discuss the topic for 3 more minutes (then vote again).
    – ”Thump side” – We can go on with this topic or take the next, it doesn’t matter for me.
    – ”Thump down” – This topic is discussed enough and set to the ”Done”-column. Move on to the next.
    (Participants in the meeting room uses their physical thumps, remote participants can just say what they are voting, or paint a thumb on the shared screen, this is possible in Slack).
  7. Documentation – During the discussions the meeting moderator shall write comments & actions in the digital Kanban board directly, this information can be taken further.
  8. When to end – Discussion continues until meeting time or topics are out. But what about meeting time ends before all topics are discussed? Well, the team have voted and what they considered the most important topics are hopefully already sorted out. If not, call for a new meeting, or let the topics stay in the ”To Discuss” column for next retrospective (maybe it then gets the votes needed to be discussed, if not, well it’s not that important after all, the team has considered).

After the retrospective meeting

If you (I assume you are the meeting moderator 🙂 ) have played your cards well, you don’t have to do anything afterwards! Actions are nicely put in the ”Actions” column to take further. For reference the topics with detailed comments can be transfered to a more permanent storing in a wiki or Confluence-page.


I hope you now have a way to perform democratic remote retrospectives! One thing to mention, if the team is not used to this format, is to be a bit flexible with the timer and the thump voting. The timer can be seen a bit stressful and limiting for the discussions. Usually you can ”feel” when a topic has been discussed enough, then you can go on to the next. That goes for the thump voting as well, You can ”see” the level of engagement for a topic, and thereby know when it’s time to move on.

if you have any questions don’t hesitate to contact me. Good luck with your future retrospectives!

All the best,
Tomas from TheAgileist

Top Ten List – Books

Today I visited Stockholm Lean Coffee. It was my first visit in a long time, and the discussions were very giving as usual! The question that I brought to the table was the one of tips of (new) Agile books to read. I got a few suggestions that I can come back to later, when I’ve read them. For now, I will share with you my top ten list of the most inspiring Agile/Lean/Management-books that I have read. Here it goes, in reversed order for most excitement, of course! 🙂


Top Ten List – Books

10. #Workout (Managing for Happiness)

I start off with the one and only book that yours truly have contributed to. 🙂 It’s the “#Workout”- book that Jurgen Appelo self-published. See my short review here. It has now been withdrawn from the market, and replaced by “Managing for Happiness: Games, Tools, and Practices to Motivate Any Team”. Most of the chapters from the first book was transfered over to the new one that is available for purchase.

9. Scrum and XP from the trenches, 2nd edition

My Agile journey really kicked-off by reading this book back in 2008 (it was then the 1st edition, released 2007). It gave me the understanding that it was possible to build software without using the waterfall model! The 2nd edition is annotated by Henrik Kniberg, sharing eight more years of his experience. Here is my review of the 2nd edition.

8. Creativity, Inc.

Ed Catmull is an astonishing leader! This book is his biography, but also tells you the story on how to build an innovative and creative company, like Pixar (nowadays a subsidiary of The Walt Disney Company). In his career he made art and technology come together. Here is my review of the book.

7. Soft Skills

Before I started this blog I had a strong desire of writing a book myself. But I had no idea on how to do it. Via Manning I got involved in a MEAP (Manning Early Access Program) providing feedback to this book “Soft Skills”, to get me “into the world of book writing”. It turned out that John Sonmez are a quite nice fellow! 🙂 “Soft Skills” clarifies personal kaizen.

6. This is Lean

This is my Lean-bible! It taught me the “secret sauce” of flow efficiency (work moves fast through the process) over resource efficiency (people to be busy at all times). I read this book long before I started blogging, therefore I don’t have any formal review, instead you can read this blog post that sums up my thoughts regarding this.

5. Moments of Truth

This book I first read in Swedish (then it is called “Riv pyramiderna!”). The author Jan Carlzon states that a leader of a company can’t be an isolated and autocratic decision maker. Instead, he or she must be a visionary, a strategist, an informer, a teacher, and an inspirer.The values presented in this book are well inline with the agile thinking, talking about empowered teams that are cross-functional and customer focused. Here is the review.

4. Agile Project Management with Kanban

I immediately bought this book after I heard about it, since I’m both into project management and Kanban! And yes, the book fit me like a glove! It’s a true gem, a perfect Agile book in 160 pages. Read more about it here.

Ok, we are approaching top three now…

3. The Innovators

”The Innovators” is Walter Isaacson’s followup book to the ”Steve Jobs”-biography that I think many of you have read. The book holds 500 pages plus, that covers the whole history of the digital revolution from the 19th century to present time. The main takeaway from this book is that creativity is a collaborative process. That innovations comes from smart people working together as a team, rather than from a lone genius. Here is my review.

2. Kanban in Action

This is my personal favourite amongst the books about Kanban! I’ve read it several times. It sort of changed how I see things, and even how people anticipate me, as you can read in the review that I end with: ”I can truly recommend ’Kanban in Action’ to anyone that wants to know just the slightest bit about managing knowledge work. From the first moment I started reading it, this has been my holy bible of Kanban!”.

And the winner is…

1. The Nature of Software Development

This book is written by Ron Jeffries, one of the original Agile Manifesto signatories. It was published 2015 and is a truly agile book with 150 pages full of wisdom! And questions. That can raise wisdom. If you ask me, I think this book is fantastic! Since the chapters are so short and to the point, it’s almost like reading poetry. Agile poetry. This is the ”true north” or ”guiding star” in Agile we all should aim for! Read my full review here.


I hope you liked this top ten list of books! If you did and tell me, I can make more of this type of lists in the future. It was quite fun compiling it. 🙂 Until next time!

All the best,
 Tomas from TheAgileist

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