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.
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.
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.
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
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