Recently I read the book "Toolbox for the Agile Coach - Visualization Examples" by Jimmy Janlen. It's filled with visualization examples for teams to improve collaboration and communication, as well as shaping behaviours. When I bought the book it contained 96 examples, but it's increased continuously. I highly enjoyed the structure, every page contains a clear visualization and a brief description. No deep theoretical explanations. Only cool visualizations you can immediately use within your own organization.

If your an Agile Coach, Scrum Master, Kanban Master etc, this is a book you want to look into. For sure it will offer you some inspiration to improve your teams collaboration as well!

My intention with this blog post is to describe my favourite 10 examples. This was quite difficult, because my first shift resulted in 32 favourites... But I've done it, see below for my top 10. In italic I've written the original description from Jimmy's book, this is done after consultation with Jimmy. In the standard format I've added some of my own thoughts.

My Top 10 Visualization Examples

1. Inbox

 "Are extra tasks frequently added by creative team members? Do you suffer from tasks introduced into the sprint by people/managers outside the team, asking specific team members for help? Does this sabotage the focus on the sprint goals? Add the Inbox policy! 

Policy: new tasks aren't added to Planned or Doing, they must be placed in the Inbox. The following standup the whole team decides if the task should be done or not, i.e. if it's valuable and aligned with the sprint's goal. If the team decides it shouldn't be done now, it goes into the Product Backlog or into the trash bin. Each Inbox should be empty by the end of the Daily Stand-up."

I think that using the Inbox helps providing transparency about the amount of unforeseen tasks. When the Inbox is continuously filled with lots of new tasks, the team will notice this soon enough. This will result in great input for a retrospective and give the team the opportunity to learn and improve.

2. Confidence Smileys

"This is a powerful alternative to a Sprint Burndown. At the end of every Daily Stand-up meeting the team asks themselves; how confident are we that we will be able to finish each User Story by the end of the Sprint? The answer is represented by a Confidence Smiley. 

The team quickly goes through each lane/User Story and updates the color of the Confidence Smiley. When in disagreement, the most pessimistic voice wins. When smiley shifts the team grabs the opportunity to discuss what they need to do, how they can help out, and if they need to alert the Product Owners and Stakeholders on changes in the forecast. 

Confidence Smileys offer an instant and simple overview of the team's sprint progress for anyone else as well."

What I like about the Confidence Smileys is it's simplicity. It's an easy way to visualize the team's confidence in realizing the Sprint Backlog. I've already used it at one of my customers and they loved it!

3. Dependency Spiders

"Draw a spider with your team in the middle. Around your team, draw your dependency sources that sometimes block your progress or force you to wait for some kind of response. On the legs of the spider you continuously add notes describing how you are currently blocked or dependent on that source.

When resolved, move the ticket to the “Resolved” area. When it’s time for a retrospective, grab Post‐its of the most common sources and analyze what you can do to reduce or minimize the pain and frequency of those dependencies. To ensure that you’re not sub‐optimizing for your team’s convenience, include the other teams or persons into the discussion.

A great tool for cross‐company (and release train) retrospectives as well."

4. Urgent lane + priority

"Not everything can be planned and foreseen during the sprint planning. To deal with urgent unplanned tasks in a structured and transparent way, add an URGENT lane.

Since urgent tasks are never planned, the “Planned” (Tasks Todo) column isn’t needed. Use that area instead to clearly state the policy that describes what counts as an urgent task. Which criteria need to be fulfilled for a task to be allowed to go straight into the urgent lane? If the criteria are not met, the task should be considered during the next sprint planning or the next Backlog Refinement session..

The urgent lane should normally be empty! Remember that every time you introduce something into that lane you create waste in terms of task switching and multitasking. With great powers come great responsibility. Don’t abuse the urgent lane."

Usually I'm not a big fan of separate lanes for urgent issues or hot fixes. Often it will be misused to add not-that-urgent unforeseen stuff to the sprint. But I like the suggestion to add a policy that describe what counts as an urgent task. This will act as a filter to prevent adding regular unforeseen tasks to the Sprint (that aren't necessary to achieve the Sprint Goal).

5. Interruption Buckets

"Do you suspect that most of your interruptions have a common origin and source? Do you have a growing frustration towards someone or something? To turn that frustration into a data driven insight and data driven decision to change something, collect your interruptions on Post‐its and sort them according to category.

Do this for a couple of weeks and then bring the notes to a workshop where you analyze and discuss how you can reduce the frequency or pain of the interruptions. Or, instead of having a time‐limit, whenever there are 5 or more notes in a bucket – call for an interruption reduction workshop."

I've worked for quite a few teams that would have loved this tool! Getting continuously interrupted was one of their primary frustrations, it prevented them to get a good development flow. But we never really made the kind of interruptions transparent and therefore couldn't act on it properly. The Interruption Buckets are a great way to visualize it and hereby offer the opportunity for improvement.

6. Team Rhymth/Cycle

"Many teams who use Kanban still experience value from having a rhythm. For example, backlog refinement every week, demo and retrospective every second week, and so on.

Visualizing this rhythm, and where in the cycle the team is, helps focus and provides a sense of structure to an otherwise response and pull driven work environment.

The cycle can be visualized in many ways: a clock (example A), a road (B), a game board (C). Pick whatever you like and find amusing."

Having a sustainable pace is important for teams to get into the desired flow. Visualizing the rhythm or process hereby is a good practice, using the given examples (clock, road or a game board) makes it even a fun good practice!

7. Pair Programming Matrix

"Are you trying to do more pair programming in your team? Would you like to visualize how much you pair during a week? Try putting up a Pair Programming Matrix.

Whenever you’ve done a pairing session, make a tick in the corresponding box. You need to agree as a team how much pairing is required for a tick.

Set a date when you review and talk about the results. If you want to continue tracking your pairing, reset the matrix and agree upon a new review date."

Quite a lot of teams use pair programming to improve the developers productivity and the quality of code. But when I ask a team how much pair programming they do, the answer is often a guessing game. Tracking it with the suggested matrix is a nice way to make it more transparent. You might even want to create something cool like the "Pair Programming Award" :)

8. Pre-printed Done checklists

"A simple way of making it easy to remember the agreed upon Definition of DONE is to print cheat checklists. Put them in a box or hang them on a nail.

When you start working on a new User Story, grab one of the pre‐printed Definition of DONE checklist. As your work progress, you tick the boxes.

Tip: Don’t print too big batches. The Definition of DONE has a tendency to change a lot over time."

These pre-printed Done checklists are a great tool to support the team members in living up to the agreed upon quality criteria. The checklist ensures the status of every User Story is continuously clear. This transparency also enables team members to collaborate with each other to get items Done efficiently.

9. Hourglass Scrum Wall

"A Scrum wall doesn’t need to be in the shape of a grid. The Hourglass Scrum Wall replaces a User Story lane with an Hourglass where tasks flow downwards. It provides two natural dimensions for limiting work in progress; the number of concurrent User Stories, and an upper limit of two active tasks per User Story. If a story is too small to be broken down into tasks (i.e. the team can finish the entire story within a day) it simply occupies the whole Hourglass.

Not separating “Work in progress” into “Coding”, “Reviewing”, and “Testing” and so on also enforces cross‐discipline collaboration and knowledge sharing."

Limiting the amount of Work in Progress can help the team keep a steady pace and make sure no one is ever overwhelmed. A WIP-limit will help you manage and achieve a good workflow. Using the Hourglass Scrum Wall not only looks cool, but it's actually an important practice every team should master.

10. Time Invested

"Would you like a lightweight approach for presenting to your stakeholders how you have been investing your time?

At the end of every week, sprint or month, roughly estimate how you have spent your time. Each member draws ten bars. Each bar represents 10% of the invested time. The time is distributed into categories such as; feature development, bug fixes and maintenance, technical investment and quick/panic fixes.

The historical summary is then communicated to stakeholders."

This lightweight approach to visualize the time invested is easy to create and results in valuable information for stakeholders. It reminds everyone that product development includes different types of work, not only features, but also technical innovation, support and technical debt.

Wrap up

In this blog post I've listed my 10 favourite examples from the book "Toolbox for the Agile Coach - Visualization Examples" by Jimmy Janlen. I highly enjoyed the book and look forward to put the visualization examples in practice!

If you've read the book as well: what are your favourite visualization examples?