Resuming the DataViz 101 series started last year, I want to revisit some basics for data visualization, showing when we get value from having numbers visualized, and when such a visualization is inappropriate. One of the main reasons that data visualization exists at all — be it smooth infographics, or slick project reports — is the fact that it saves us time needed to digest some quantitative information, i.e. the information that has numbers in it. Visuals present numbers in an appealing way, making them easier to read. Sometimes, however, they use visualized numbers with no substantial ground. If no meaning is ingrained into the graphical cuteness, a visual would make no sense. Some other technique for information rendering has to be used then, such as a text.
Take a look at one such case where numbers pretend to be visualized with some meaning, while actually failing to provide real value to people who look at them.
One can see this pattern with numbers highlighted quite often on web-sites for conferences or gatherings. Such a visual is supposed, presumably, to convince potential attendees that this conference holds some value for them. However, I don’t see how it will help decide if a conference is worth attending or not. There’s no universal converter that would work for each and every individual, and translate those hours of keynotes, workshops, trainings, and the count of speakers into a meaningful answer to one question: “Will I learn something new and useful for me personally at this conference?” How are these flat numbers capable to attend to the unique knowledge landscape of any given individual? No way, they can’t do it. Those people who are looking to decide for themselves if a conference is worth attending or not, might as well skip this “hippish” part with meaningless numbers, and proceed straight on to the text piece about the speakers, keynotes, workshops and training. Bad news for someone who did this visual: they’ve wasted both their time, and the time of the site visitors.
Here’s the other example that shows how visualized numbers can help in project management:
This is a sparkline report, and while it includes numbers that seem to hold no meaning to an external observer, an insider who looks at the graph is likely to know the project context: how user stories and bugs are sized in general, how much effort does it take to have them completed, and how these numbers can be rendered into a diagnosis report on the project health. Compare the sparkline graph and this text: “This report covers the last 16 weeks. Designers had their backlog full with 13 user stories in the first week, with fewer and fewer new stories added in the next weeks. They completed 3 stories, and had 2 more added to their backlog in the current week”. Of course, the sparkline renders this info in a more compact and time-saving way.
As a summary, before we hurry to create a visual report, or an infographic with numbers, we need to consider if a user or a reader will get the info they want fast from this visual. Some information can be rendered best as a piece of text, like in this first example from a web-site of a conference. Words would have taken readers to the core of the matter faster. In the second example, it’s the other way round. It would take more time to convey the same information in words.
This article includes 42 timelines that I looked at recently. Timelines are used in education, finance, aviation, banking, news and media, in project management and what not. I hope this one-stop collection will foster a feel for good visualizations, helping you be creative with your own timelines.
There goes. Let’s start with timelines in education.
#1. Native American Timeline
The history of Native Americans is presented as a railroad with stops.
#2. Historia Timeline
Some major history events with pictures are listed here. This is rather a repeating sequence of date-text-picture pieces, not a classical timeline with x-y axes. It works well for educational purposes, nevertheless.
#3 History of the Earth
This timeline embraces 5 billion years. I like how eras are synced with water and earth stages.
#4. Microbiology Events
Here’s the explanation of specific time periods from this timeline. The layout is similar to #2.
#5. Timeline of World Religions
It would take a lot more time to retrieve the information presented on this timeline from plain text.
#6. The History of English
Same as with #5.
#7. The Growth of The Republic: Population and Economy
This is a fragment from the awesome infographic A Visual History of the American Presidency, which has several timelines incorporated into it. The growth of the republic timeline shows how population and GDP were growing with time, along more states joining the Union. You can explore this infographic online for more details, the screen below is given for quick reference.
#8. US Presidents Succession Timeline
Another fragment of the same infographic. Fluctuations in popularity are mapped over years.
#9. The Ideological Dynamics of the US House of Representatives
This timeline shows how conservatives, liberals, democrats, GOPs, etc. correlated over time. The source infographic is interactive: data can be filtered by state and by party.
#10. Kennedy Shooting
Another reference to US Presidency, a sad one. This timeline has a mix of daily and hourly distribution of events, depending on how fast they unfolded. The source timeline is interactive; bubbles with more information open by clicking on dots.
#11. Alcohol Taxes – The Tipsy Turvy Republic of Alcohol
Let’s switch from US Presidents to US alcohol. This timeline is self-explanatory (click for high-res).
#12. A Century of Motoring in America
I found this timeline in the Information Graphics book. Here’s how it’s described: “This is a history of the automobile in one image. Using the metaphor of a board game, the graphic follows the most important milestones in the first 100 years of cars. ..History is thus conceived as a timeline drawn on a fictional map.”
#13. LA – NYC Road Trip Timeline
Country roads, take me home.. That’s the feeling that I get looking at this timeline. 2 guys drove from LA to NYC for 14 days, and made 4219 miles. The color-coding in timeline shows who drove, for how many miles, which places they drove by on any given day. You can explore this timeline in more detail here.
#14. NFL — History of Current Franchises
This timeline is a bit unusual, with events going from top to the bottom. Each bar is a team, colors show which league the team belonged to throughout the history (click for hi-res).
#15. Bestselling Books
This timeline shows how the rank of bestsellers in Catalonia (Spain) fluctuated from Oct 2007 thru Oct 2008. With timelines, dotted and solid lines are used to convey more information quite often. Here, the dotted lines are used to accentuate best sellers that dropped out of top 10. The books by Catalonian authors are shown in red, the others – in blue. I included this timeline not for the sake of the info that it conveys (sorry, I don’t speak Spanish), but for the sake of showing that a timeline can be used to represent such kind of information as well.
#16. Mission to Mars
An unusual timeline showing Mars as a destination for many missions that resemble tentacles closing in on the Red Planet over a circle of time.
#17. Sleep Agony Timeline
From Mars to purely down-to-Earth matters, such as sleep. That’s a sleep timeline from a life of a parent in NYC.
#18. Sleep Bliss Timeline
Here’s how it looks. Not as cluttered as the agony one.
#19. Motown’s 191 Number One Hits
One more timeline from the Information Graphics book by Taschen. The distribution of 191 top hits released under the legendary Motown label is shown over time, with years – months intersections running by circles. Color coding refers to the most successful artists. You can look into more details of this timeline here.
#20. The Web Technology Timeline
No comments :)
#21. Transparency Productivity
This timeline explores the connection between technology and productivity. No outstanding infoviz mastery here, just a good quick-look timeline.
#22. Life Online
This high-density timeline shows how technology influences social life over time. If you want to take a close zoom-in look at it, as well as on the timelines #23 and #24, there’s only one way to do it – get this book. The timelines were created by Paul Butt.
A close-in on technology…
…overlaying with culture/media events:
…and with the count of visitors per month for major online hubs:
#23. Disk Space
The evolution of data storage and processing.
A a close-in on a piece of this circle timeline:
#24. Mobile Evolution
The evolution of mobile phones and text messaging.
#25. Timeline of MS Windows
It only traces the evolution of Windows till 2007, but the rest of Windows history can be visualized in the same fashion. The timeline overlays MS Windows versions with devices.
#26. CNN Traffic Analysis
The central spike chart demonstrates weekly page-views over time; black tags mark the ten busiest weeks, with specific events highlighted with white tags below the central axis. In the lower part, the growth of site categories is tracked. This timeline demonstrates the evidence of how CNN.com became accepted as a timely news source.
A close-in on the bottom-right part of the timeline:
#27. Airline Business Timeline
I have a special kind of love for some airlines, so I like to look at timelines related to aviation. The interactivity is here.
#28. The Flights Timeline
Powered by Hipmunk. It’s easier to pick a flight with this visualization. Expedia has no such timelines, as far as I remember.
#29. World’s Worst Plane Accidents
Look at this timeline, and fly safe, always.
#30. 3D in Focus
This timeline shows the rise in box office earnings from 3D movies, as well as a timeline of every 3D movie released in the last ten years. Created by Reuters.
#31. A History of Violence
Another timeline by Reuters. It’s the job of news agencies to deliver information to the public, in a concise and timely fashion; so it’s no wonder that Reuters produces lots of great timelines.
#32. Booms and Busts
Probably, financial timelines are the ones that we see most often. I included a couple of them to this collection. Click here for the interactive version of the Booms and Busts timeline.
#33. Oil Price Timeline
Barrels over time, by Reuters (source).
#34. Euro Zone Debt Crisis
Good job. I mean, not the crisis, but the timeline.
#35. Gantt Chart Timeline in MS Project
Rounding this list up with timelines related to project management. Gantt chart is the grandfather of such timelines. Maybe someone has forgotten already how those look? Here’s the reminder.
#36. Multiple Projects Timeline in Excel
I found this timeline here, and I can’t but admire people who manage to track their projects in Excel. However, I wouldn’t say that this timeline will work for complex projects. This Excel timeline shows personal projects, plotted over time.
#37. Basecamp Timeline
Heh, this number goes to 37 signals who recently rebranded themselves to Basecamp.I will turn on the critical mode here. This information is presented as a timeline, but to me it looks likes a feed of events. The alternation from the left to the right breaks the monotony, but probably this screen could have been used to convey some other information. When there’s too little info over too much space, it’s called “low information density” in infoviz lingo.
#38. IntelliGantt Timeline for BaseCamp
That’s a BaseCamp-based modification that someone created. Months and days are vertical lanes, horizontal lanes are people. I like it, that’s a nice timeline to see the dynamics of assignments per person on a timeline.
#39. Planning and Construction Timeline
For a change, here’s a timeline unrelated to software development. It shows when the building units will be busy or vacant, and how the construction will be planned.
#40. A Hand-Drawn Project Timeline
Anyone can draw a timeline on a whiteboard. That’s a timeline sketch that we’ve done about a year ago. At the moment, something similar to this timeline is available in our project management tool. Hand-drawn timelines can work if someone takes on the responsibility for syncing all the data from the tool with the timeline (think, how much data you have?)
#41. Product Features on a Timeline
We use digital timelines more often than the hand-drawn ones, no doubt. That’s how a timeline for features looks in Targetprocess 3.
#42. Person-Project Assignments Timeline
With a switch in settings, we will get another timeline view. I’d better stop here because I’m tempted to showcase even more timelines that we’ve made possible, but that probably would be too much.
These were my 42 timelines. I stopped at 42 because it’s the ultimate answer to anything. The whole Universe consists of overlaying timelines, if we think about it. Some timelines exist simultaneously in parallel spaces, some timelines are consecutive. Thinking with timelines not only helps us grasp information fast. It helps us embrace the whole world.
A couple months ago in the article Kanban as Multiban? I questioned the applicability of simple Kanban boards for managing complex software development projects, and suggested the concept of Multiban. This short word inherits the practice of visual project management with boards taking the baton from Kanban, and looks like a good coin term for this innovative concept to me. “Ban” stands for “board” in Japanese, Kanban is a “signboard”, and Multiban is a Japanese-English mix which means “many boards”. In this article I will tell more about the use of “many boards” for visual project management, showing how Multiban differs from Kanban, and when it’s better to use Multiban instead of Kanban. Shortly, a Kanban will work well for a small company with only so much of work items, and with a straightforward development process. For a larger organization with many teams and many projects, a traditional Kanban board will not be enough. If you want to get the best of all the project Big Data in your organization, it’s time to consider Multiban. It doesn’t matter if your development process is Kanban, or Scrum, or any other lean or agile or whichever process. The Multiban covers everything.
There are 2 basic entities that Kanban and Multiban have in common: a card and a board. Let’s look in to the differences.
How a card in Kanban is different from a card in Multiban?
A Kanban card can be pinned only to one board. No matter if the Kanban board is a physical or an electronic one, the card is tied to it and can’t live anywhere else. Besides, a Kanban card usually signifies work items only. Now take a look at the list of Multiban cards:
Pretty impressive, huh? Apart from being impressive this diversity of cards powers the very ability to visualize project work in many different ways. Here’s another crucial point of difference: one and the same Multiban card can live on many boards. If cards are available only for work items, as in Kanban, one can visualize how work streams through development states, pretty much as in material production. Software development, however, dictates the need to take many ad hoc factors into account. Big IT projects in a large enterprise company can be anything, but straightforward, unlike a car assembly line. If someone wants to control this complexity, without too much extra effort and time, a set of various cards visualized on many boards looks like a must-have gear .
How a board in Kanban is different from a board in Multiban?
With Kanban, a board is just one board to which the cards are pinned. With Multiban, a board is a slate of switchable data axes (or lanes), with custom intersections. This slate can also be converted to a list view, or a timeline view, or a card details view. Actually, it’s for that reason that one and the same Multiban card lives on many boards. With switchable lanes, it can appear in various contexts. A Multiban tool has the switcher of those axes and perspectives (see the full list of available combinations) that allows to set up any board as a custom 2D data grid in no time:
Next, given that we deal with one digital screen, the single option of using board as a pinboard will not be enough. If all you have is a visualization with a board and cards only, this will pose a limit on the versatility of visualizations. What if you need to see work items and other entities as a list? Or as a timeline? Or what if you want to zoom in on just one entity? With Multiban, the electronic slate can be tweaked. It’s now rather not a board, but a flat white space that turns into a list, or a timeline, or a board with cards. Check the purple arrows on that screen. They highlight the 3 basic switchers that are used to set up any board.
This image gives an excellent summary of the Multiban approach:
The “see data” stage is where you configure a custom visualization of any data entered to your project management tool that supports Multiban. You will want to ask yourself: “How do I need to see this?” instead of “What will this board allow me to see?” All those many boards are available, waiting to be picked by you.
Too many cards, too many boards… Do I need this?
It might seem that it’s so easy to get lost in this versatility of cards and boards. Sometimes, freedom of choice is more intimidating than no choice at all. It does take some time to get used to the switchability of everything in Multiban. Too many cards can be sorted, filtered, paginated, zoomed in or out. Too many boards can be stored in folders, as in a file management system. It might seem an overkill to use Multiban if you’re happy with a simple Kanban board for one project, with < 100 cards, and with a straightforward development process. But, for example, a fixed Kanban board will not be able to showcase a portfolio of projects like that:
If you want to learn more on when and how it’s best to work with Multiban, check out these use cases… or look into the peephole in the fence on the right.
Kanban as Multiban?
It’s interesting to trace back the origin of the trends in business and technology to the intrinsic needs that we as humans have in the changing environment. People influence technology, technology influences people, and the cynical adage that laziness drives all progress proves to be true time and again. I’ve already written an article on how Big Data trend is powered by human desire of stakeholders to dodge the responsibility of prioritizing and making decisions. Or, why the evolution of Agile movement has purely human implications. Or, why people resorted to Kanban after trying Scrum as intrinsically they related to Kanban’s “no deadline” philosophy.
Today I want to share some thoughts on the origins of the trend for visualization. Why it has taken the lead, and is getting more and more evangelists? I like to dig deep, so I’ll first take a look as far back as to the prehistoric times. This analysis might provide some food for thought, and probably will help you see how other technology trends are downright rooted in the properties of human psyche and physique. The one with knowledge is the one who is powerful, so make yourself comfortable and read on.
The Five Senses in Prehistoric Times
Ancient hunters and gatherers relied on their five senses as the devices to signal an immediate threat, or a promise of food or water. Like, a certain smell in the air might have meant something. Or, a sound of a dangerous animal moving in the forest. Or any other sign of danger. In fact, actually seeing some dangerous thing might have been too late. Some fast running predator could grab a defenseless human in an instant, leaving no option for retreat. Eyesight worked as a part of the 5-component system, and did not get extra overload as compared to the other senses. One example of a visualization from those times would be cave paintings, which the hunters would draw as a part of their ritual for success at hunting:
This picture differs from what we mean by “visualization” nowadays. It is a projected vision of those hunters who believed that if they visualize their plea, it would help them survive. I’ve singled out this particular case for the sake of showing that the sense of vision might not have meant that much to ancient humans as a sense of perception, but was more important as a sense of projection. I’m using a simplified perspective here on purpose.
The Five Senses in the Information Age
Taking a huge leap, we now move on to the Information Age that started somewhere in the second half of the 20th century and continues up til now. I’ve skipped the industrial revolution as the changes that it brought about haven’t been that drastic and lifestyle-altering as the changes coming along with the Information Age. Let’s see how the perception load is distributed between the five senses now. There’s no need to visualize this in a distribution chart (*ironic*), it goes without saying that eyesight is the most overloaded out of all our five senses. Some people perceive information via their unlocked 6th sense ESP, but my article is not about that. It’s a given that most of the signals that we receive from the external environment are coming through our eyes. This is especially true for the information technology workers.
We’re spending most of our lives looking at digital screens. Phones, laptops, TV. Hearing might have a chance competing with eyesight. But the sense of smell, taste and touch have lost their significance as compared to prehistoric times. Once I thought how great this would be if we could smell a fragrance that we consider purchasing over the web. Or touch this carpet to feel if it’s really that soft, thick and comfy. But we only have our eyesight for anything that comes from a screen (mostly). We’ve traded the other senses for more comfortable existence, and we have to deal with it, so our body wants to develop some coping mechanisms for this overload.
Visualize for Watching Less?
I consider the modern trend for data and information visualization simply a consequence of our overloaded eyesight. If you’ve studied some sources, you might have observed this trend developing in line with the growing information volumes. Our collective unconscious makes us come up with ways to limit exposure to visual signals, striving to keep all the 5 senses balanced. It’s hardly that the sense of smell, or touch, or taste would gain precedence over eyesight and hearing as the information channels, but at least some coping mechanisms can be developed. That’s why we tend to present textual information as laconic visuals if it’s too much to read (I’ve given an example of that in my recent article on the taxonomy of names in sports leagues). Or, as with data visualization, we now prefer to make sense of analytical reports presented not as a text but as a visual. It’s just too damn long to read this in a text! Have mercy on our poor eyesight, someone! That’s what the trend for visualization is about. By the way, have you noticed that most IT-people are listening to music in earphones as they work? At least, some of the time. This is yet another unconscious attempt to ease up the overloaded eyesight by shifting balance to the hearing receptors. Hearing is the only other sense that we can use as we work with computers.
No doubt, we can understand concepts and do analytics faster with visuals. Let alone quickness, a more powerful driving force for that trend is something that sits deep inside of us, humans, as we want to keep our senses in balance. Another example of imbalance in the duo of eyesight-hearing would be online text messaging. Natural communication involves hearing and speaking in a company of other people. If for the most part people “talk” by means of typing on the keyboard, this adds up to the overload that our eyesight has even without this, processing all the other kinds of information. It feels like a huge energy drain if I have to spend much time reading messages in Skype or posting comments in online discussions. That’s why I do this only when needed. I’m not sure which subliminal remedy the humans will invent for that. Will we develop some universal hieroglyphic writing as a replacement for phonetic-based written texts, for the sake of saving our eyesight from yet another overload? I don’t have answer to this question so far.
Visualization: Understated Or Overrated?
Edge of Chaos blog posts on visualization
Recently I’ve written a blog about the benefits of visual thinking. Assuming that many of you are now aware of the advantages that visuals bring to the table, I’d like to give a few tips on how to visualize work in agile project management. Visual reports would probably be the first thing that comes to mind in this context. That’s right, visualization is most commonly used in reporting. Everyone wants comprehensive reports, fast, and that’s what visuals deliver. All kinds of stats and metrics wrapped up in a nice graphical skin, just as in this process control chart:
A Process Control chart in Targetprocess
My main focus this time is not on the visual reports, though. There’s a baseline dimension for visual choices in agile project management, as we’re looking for the most convenient ways to see exactly what we want to see. We might need to view our projects from various perspectives, and we need flexibility with visualizing things. Boards, lists and timelines would cover most of such needs. Let’s now look which of those three would be best suited for which tasks.
You will want to visualize work on a board if you need to intersect 2+ properties of a card, or if you want cards grouped by any of 2+ properties. All that switchable visualization magic can only happen if your agile project management tool does the job as described in the Kanban as Multiban? blog . Unlike the classical Kanban board, this board is supposed to be a switchable 2D (or even 3D) grid of any properties of a card or a group of cards . This is a must-have prerequisite for that limitless freedom with visualizing projects on a board. I’m aware of only one tool that has this “switchability“. Let me give some examples.
You want to know who is doing what. Which person has which to do’s assigned to them. Hmm, this is not something that you would easily see on a static Kanban board. You can dial in a custom people-work grid, and here’s how it would look on the board (click to enlarge):
User Stories, Bugs and Tasks by person in Targetprocess 3. Who’s doing what?
Then, you want to know about impediments, and how are they blocking progress in your projects. Switch the grids, and see them with ruthless clarity:
Impediments by Projects and States in Targetprocess 3
Visualizing a project with any of the switchable boards makes sense for anything drag-n-drop. It’s more than moving cards between states. The switchability will allow to fit almost any change to a drag-n-drop action. That’s how one can arrange user stories on a board for estimating. The 1, 2, 3, etc. vertical lanes are points. A user story will be dropped to any of those lanes when estimated:
Estimating user stories with drag-n-drop in Targetprocess 3
You will want to visualize something as a timeline if you need an activity or a group of activities plotted on a timescale, with some explicitly marked milestones. This is called roadmapping. If time-sensitive activities are visualized on a board, with the intersected year quarters and epics as on the screen below, the feel of time would not “sink in” that well :
A workaround for roadmapping in Targetprocess 3
.. as with a roadmap shown on a timeline. The sense of time is more acute with this visualization:
Roadmapping with timelines in Targetprocess 3
Tracking work on a timeline helps get a clear picture in one look. A timeline would also work better than any other visualization if you need to see individual allocations across several projects:
Individual allocations on a timeline in Targetprocess 3
One absurd idea for using timelines, just to give you a strong anti-pattern, would be to visualize a tag as a timeline. Sounds weird. A tag is a tag, no one cares, when and why has a user story been tagged with a tag. Hmm.. However, there still can be a realistic case even for that, if one would want to see when this tag was first used, to which to-do’s was it applied, etc.
I’ve been using timeline visualizations from Targetprocess 3 in the examples above. Frankly, if you want to visualize with timelines, you’d hardly do without an electronic tool. Apart from the switchability, it takes quite some effort to draw timelines on a physical whiteboard. Guess how much time would it take to draw a timeline any time one wants to get a custom visualization?
A roadmap on a whiteboard
You will want to visualize work as a list if there are only a few to-do items, or if you need to trace the hierarchy of epics -> user stories-> tasks-> bugs as here:
A sketch of lists in Targetprocess 3
A list also comes handy if you are hastily typing in the to-do’s, especially if on the go, catching ideas before they go. With no big screen for boards and timelines around, you might want to use lists on a mobile device:
A list view in Targetprocess 3 iOS app
As a summary, your visualization choices will depend on what you want to see, or what you want to do. Switchable boards and timelines can visualize anything. If you’re still skeptical about that, check this page with even more board visualizations.
We’ve been working for several years with Kanban process, and there’s quite a bit of experience about it that we’ve shared (see the posts tagged with “kanban”). I’ve contemplated things around Kanban recently, and here’s another interesting perspective. It might help make more sense of the Kanban method as a method for managing knowledge work, and software development work, in particular.
If we look into the 6 core Kanban practices, as identified by David J. Anderson in his fundamental book “Kanban — Successful Evolutionary Change for your Technology Business“, the first practice is “visualize“. While the other 5 practices (Limit WIP, manage flow, make policies explicit, implement feedback loops, improve collaboratively) are very important, the visualization practice is the key to all of them. Taking a flashback into how Kanban evolved historically, first it was a system “to control the logistical chain from a production point of view“. Seems like Kanban as a method for software development differs from Kanban as a scheduling system for the material production in the following 2 things (mainly): non-linearity of the production process, and diversity of concepts and workflows.
I can imagine what the first sparkle that inspired software development folks about Kanban was. Some of us have this special relationship with the concept of “deadlines”, and probably Kanban — on a purely human, maybe even subconscious, level — has been seen as an opportunity to break away from deadlines and estimates. Well, might be that Kanban came later than Scrum due to the fact that people got tired of the time-boxed iterations. And there it goes, a trendy new method for software development, that says: no time-boxing! Do your work at your own pace, and don’t worry about deadlines!
That’s the most obvious advantage that laid on the surface, and that’s why software folks were so glad to switch to Kanban, intrinsically. The Kanban movement started back in ’09-10, and the 5 Wrong Reasons to Apply Kanban and 5 Right Reasons to Apply Kanban posts in our blog are the evergreens that can provide some practical advice even now (especially as they resonate with the current NoEstimates movement).
Now, if the flow and no estimates aspect is a woo in Kanban as copy-pasted from the material logistics model, we’re having a bumpy issue with the visualization core practice. The easiest way to go would be to copy-paste the visual production flow from logistics, as a stock of parts in the warehouse (the backlog) reduces, and then sequentially goes through the In Progress and Done states:
Looks as easy as a pie, right? But, remember, software development is a knowledge work. While some part of it, such as work items (user stories, tasks and bugs) can indeed go through this simplistic flow sequentially, there’s a bunch of non-material related concepts and dependencies that those work items carry along with them. They are the non-linear “sticky fish” that might hinder the movements of this big whale called “software production’. Visualizing this knowledge work is not something confined solely to workflow and limiting WIP. Working with Kanban as a method implies visualizing various concepts about processes. Kanban is ultimately a “signboard”. One straightforward Kanban board often lacks all those multiple perspectives that we need to monitor processes and to make them explicit. Obviously, a part of this limitation can well be addressed by swimlanes, when Kanban is not a board with just columns, but a grid of switchable columns+swimlanes. It’s quite hard to get such a level of visualization on a physical board, too cumbersome to maintain. Fixed swimlanes on an electronic board (or, even switchable swimlanes but with some limitations) would not be enough. Kanban in the context of knowledge work requires unlimited columns+swimlanes combinations, with a plethora of custom 2D data grids. And we need to switch them fast, in a few clicks. Well, we can use tags to add another optional dimension for work items, but sometimes tags are not enough.
What we need from our Kanban boards for software development projects would look like this:
Any data from the project could be extracted from the database and visualized in an instant. The teams-work items grid above is just one example. This sketch implies fast swapping of the vertical and horizontal lanes and visualizing the same data in a different way, with even more sophisticated filtering for the lanes available, if required. For example, you’ve created a 2D grid that shows user stories grouped by features. You only need to see the stories from the “open” features, to unclog the grid (features are represented by the horizontal lanes):
Here’s the list of possible properties (“the sticky fish”) that can go along with a user story:
- Iteration: if you see the upcoming iterations, you can move the stories to the grid cells, and create an iteration plan.
- Release: same as above, for a release.
- State: this would be a classical Kanban board.
- Priority: user stories can be prioritized similarly to how the states are changed.
- Effort: same as above, but for effort.
- Feature: that would be a story map backlog.
- Person: a work-by-person grid.
- Project: user stories broken down by projects.
- Team: user stories broken down by teams.
- Tags: even more flexibility.
- Custom fields: same as above.
That’s the diversity of 2D visualizations that we could have with just one swimlane. But it’s not only about swimlanes. Both the horizontal and vertical lanes could be tuned in the same fashion, unveiling thousands of custom 2D views.
So, what we would have here is not just one Kanban. It’s a “Multiban” — many boards on one screen, where boards are switchable 2D data grids, and the data itself remains intact. Another example of such a data view is this:
Imagine this freedom. With such unlimited ability to visualize anything, the Kanban method would make much more sense. Any concepts, any perspective that you need could be visualized. If we have the first visualization core practice for Kanban handled that well, we would be able to take advantage of the 5 other Kanban core practices, mentioned above, and utilize Kanban as a process to manage software production (the knowledge work) more fully. That’s what we are coming up with in the next version of our project management tool, and in this post I tried to provide some “behind the scenes” reasons for that.
Stuck with Kanban? Consider Multiban
In this installment of the dataviz series, I will tell about some visual reports that might be of interest for Kanban practitioners.
We all know Kanban as a process that has production flow visualized on a board. The to-dos (or work) get started in Backlog (or in the Planned or Open state), then they get to In Progress (or to any other variety thereof), and end up in Done.
So, yes, we all know about Kanban, but some of you might be less familiar with the reports that go along with it. If Scrum comes with only 2 visual reports (the iteration and release burn down charts), Kanban has several of them, and you will see now how those visual reports can be of help.
Cumulative Flow Diagram
…is the first and foremost report. It shows how work “accumulates in flow” (hence the name) with time.
What can you get out of this visual? First, the correlation between the ToDo (or Planned) work, the In Progress work, and the Done work broken down by weeks. The diagnosis for the team that has such a sleek CFD is nothing short of utopian, by the way. The light blue layer is ToDo, the green layer is Done, the beige layer in the middle is Work In Progress. You can see that if the blue To Do layer gets too thick, this means that the backlog needs good grooming (maybe some part of it shouldn’t be in the ToDo state, but in some other pre-production state, similarly to what I’ve described in my recent 3D Backlog Management post). If the beige In Progress layer gets too thick, someone has to set reasonable Work In Progress limits. Well, the only layer of those three that looks good when it’s fat is the green one. A point to note about CFDs: they work well if you want the bottomline diagnostics report for only 3 states. If your Kanban process includes some sub-varieties of them, the report would get too clogged and would make no sense.
CFD reminds me of the tectonic layers and the Earth formation process. An easy way to memorize the logic of this report would be this: the more rugged the outline of the layers is, the more turbulent the process, the more bottlenecks it has. Ideally, this report would have all the surfaces even, where the blue layer (the ocean surface) remains serene and almost untouched, this means just a few to do’s are added, the seabed layer (the work in progress) is reasonably thin, and the solid baseline layer of the Done work (the Earth crust) is getting thicker and thicker (but that’s utopian…).
Lead and Cycle Time Report
… is another visual report that is so vital for Kanban. Actually, the lead time report is not that helpful for software product development, as it covers the time that work seats in pre-production state (read, in any of the backlog states), whereas the cycle time is a pure “work in progress” span. The lead time would have more meaning for hardware production, where people look at it as the measure of how long the storage space is occupied with the parts, for instance, and they need to adjust their process accordingly. For software development, no warehouses and storage spaces are needed, that’s why only the cycle time report would matter *unless the work items are requests that come from customers. In this case, a short lead time would suggest that those requests are implemented fast.
The cycle time report above shows an abrupt spike of completed user stories in November. This probably means that the team worked full gear to get as much as possible done for some major milestone. Later on it went back to a rather even development flow. Besides, the correlation between completed stories and bugs is supposed to show, ideally, if it was a quality work. April looks very well, as it had 12.4 user stories completed with only 3 bugs. You get the idea.
Process Control Chart
… feeds on lead and cycle time reports. It shows if the development process is healthy and under control. Take a look:
If most user stories are scattered around the median line, it means that all is well with the process, and most of the user stories are done within the average time to complete. You can also identify any “odd sheep”, like the story that took 34 days to complete, or even 80. At this point, the process control chart has nothing more to say, and we need to click this odd bubble to find out the reasons for its oddity. This is our next report:
It indeed uncovers some of the reasons, as you can see from the screen above (the red boxes at the bottom are bugs). This story has been thrown back and forth from state to state, it had a suite of bugs, and not all of them were fixed… what an unfortunate user story.
Lead and Cycle Time Distribution
Finally, there’s one visual report for Kanban that can give a forecast. While all the other reports just diagnose how things were going in the past, this one predicts how likely it is that some user story will be released in any given amount of days. If we look under the hood, this report is powered by the historical data from lead and cycle time reports:
You can read more about some practical uses for lead and cycle time distribution chart here.
If you need those reports for your work, feel free to look into the peephole on the right :)
Today, as a part of the DataViz 101 series (check out the previous installments: Visualization: Understated or Overrated? and Data Visualization 101: Basic Guidance), I will write about one tiny graph that can be used as a report in agile project management, be it Kanban, or Scrum, or any other custom mix of those.
What is a sparkline graph?
In the non-project management world, sparkline graphs work as quick time-span mini-reports featuring the dynamics of certain states or activities. The sparkline graphs usually look like tiny ragged lines. Here’s the definition, the direct quote:
Sparklines are data-intense, design-simple, word-sized graphics… Sparklines mean that graphics are no longer cartoonish special occasions with captions and boxes, but rather sparkline graphic can be everywhere a word or number can be: embedded in a sentence, table, headline, map, spreadsheet, graphic.
Edward Tufte, Beautiful Evidence
Why sparkline graphs are good?
In a few words, sparklines are used if there’s no room, nor time, nor space for visual bells and whistles. What would be the best graph for a broker to track the stock dynamics with one brisk look? Or, for anyone who tracks stocks in newspapers? Exactly, a sparkline graph. This one pretty much explains itself:
*the image is taken from the book “Beautiful Evidence” by E. Tufte
Next, take clinical tests. A patient is recovering from some bad health condition, and doctors need to assess the recovery dynamics by taking just one look at some data. That’s where sparklines can help, too. Anything that goes beyond the grey strip, at the bottom or at the top, is alarming, not within the norm.
*the image is taken from the book “Beautiful Evidence” by E. Tufte
What else is good about the sparklines, apart from their extraordinary time- and space-saving qualities? They are very effective in tackling the phenomenon that Edward Tufte calls “recency bias“.
Compare these 2 reports:
*the images are taken from the book “Beautiful Evidence” by E. Tufte
The upper report shows the yearly dynamics, as a table. The sparkline part of the lower report covers more than 2500 numbers! Thus, it reduces this very recency bias as the year-long daily history (from the last year) makes the analyst pay attention not only to the yearly fluctuations, but to more subtle daily movements in the context of the whole year. If an analyst were to look at the daily dynamics in a table format, she would have missed it. It would be possible to track the dynamics by week, or by day, but it would just take too much space to have such a report as a table, for 2500 numbers, and for every day of the year, hence “the recency bias” would come in charge with a table report for fewer days. They are not able to cover such a huge 365-day span with the pluses (“+”) and minuses (“-”). That’s where the sparkline really helps.
Sparklines for Agile Project Management
So much for the intro to sparklines, let me now show how they can be used for agile project management. Take a look:
On the left you can see the list of teams, along with the avatars of people from those teams. Here’s the logic behind the sparklines for user stories and bugs:
-Any sparkline covers a time span of 16 weeks. Why 16 weeks? It’s convenient in terms of iterations and releases, as in agile project management iterations usually take 2 weeks. So, this stands for ~ 8 most recent iterations. If you count each tiny sub-bar, this would total to 16 (in the sparkline for Designers and Philadelphia Flyers teams. The Support team has less than 16 weeks history, most likely). The 16 weeks time-span seems to be working well for iterationless development, too, as in Kanban.
-The zero line is the vague blue line in the middle (or, the red one, for bugs).
- The actual numbers shown on the top and on the bottom represent the max. number of user stories done or added, respectively, at any given week out of those 16. If you see the max. number, for a week that goes shortly after the 4th week, then you get an idea of how many user stories have been done in the previous or in the following weeks. There’s no need to show the numbers for each week, as it would make this tiny graph too clogged. The same logic stands true for bugs.
-The numbers on the very right, in the sparkline, relate to the current week.
-The “total” numbers show how many user stories were done in those 16 weeks (on the top) and how many were added (at the bottom). Sames for bugs: the total fixed number is on the top, and the total added — at the bottom.
If you’re a stakeholder, or a Scrum Master, or VP of Development, or anyone who wants to keep an eye on how those several teams are doing, this report is indispensable. With the least time spent, you get the maximum info. And – yes – there’s no recency bias. You are able to embrace the whole span of 16 weeks in that little space.
It’s not only about the counts of bugs and user stories. For example, if you see that your sparkline for user stories is keeping low, close to zero, and your bug numbers are pulsating with action, this means that this team is currently working to make the release stable (most probably).
Finally, this logic which has taken me quite a bit of space to explain here, is condensed to a mouse-over text tooltip.
“Where can I take a look at this sparkline in action?” you may ask. This is something we will release in a newer version of our tool. I tried to explain here why we decided to introduce sparklines, and why we consider them a useful metrics for agile project management.
Data Visualization 101: Basic Guidance
My 12 Visualization Books
In my previous Visualization: Understated or Overrated? post I mentioned that sometimes people pass on the tremendous benefits of using data visualizations because they lack education in this subject. It might seem too heavy to get yourself know more about data visuals. You might think: I need to attend a conference, or a training, pay $$$ for that, etc. Not at all. A unique individual research and self-training can yield far better results, than taking a formal stance and attending one conference, sitting in for a couple of days, and then going back home.
I can suggest 3 reliable options to learn the basics of data visualization, depending on how much time you are ready to invest into those studies. The more, the better, of course. Remember, you don’t need to sign up for classes, nor get loans for studies, nor pay for a training or a conference. There’s no time-boxing. All you need is the real desire to learn, and some chunks of your free time.
We have a number of posts about visualization in our blog, scattered here and there, and I aggregated them into a learning framework. You can consider this a FREE intro to data visualization powered by Targetprocess.
Option #1. Over Medium
Study the books from this list of 12 books on data visualization, compiled and annotated by Michael Dubakov. Take notes and read them thoughtfully. This approach is called “over medium” because you will not only get hold of the dataviz concepts and principles, but see why these principles have evolved like that.
Option #2. Over Easy
The second option would be to study only the 3 books (shortlisted by Michael). These books are included to the 12 books list, and you can find their descriptions there as well. Why these 3 books have been singled out? They are fundamental as they cover some key principles and concepts, and if you understand those core principles, you will be able to look at data visuals with confidence. They will start making sense to you. Sometimes we spend a lot of time poking around and looking for a good bottomline book on some subject. You don’t need to spend time poking around. This has already been done by experts, and all you need to do is pick up this condensed knowledge.
These are the 3 books:
1. Semiology of Graphics: Diagrams, Networks, Maps by Jacques Bertin
2. Visualizing Data by William S. Cleveland
3. Visual Explanations: Images and Quantities, Evidence and Narrative by Edward R. Tufte
Option #3. Easy
Study just 2 articles. You can even print them out on a color printer, and put on a wall as posters. These articles are good not only for their content, but for the visuals. If you see the prints all the time, you’ll get used to such charts, and you will be more likely to use them in your work.
These are the 2 articles:
1. Patterns for Information Visualization. This image can be regarded as a mindmap:
2. Visual Encoding
There are soo many nice visuals in this article. It provides an engaging introduction to visual encoding, showing how it helps to present data in a meaningful way.
To train your eye, and develop a taste for good data visualizations, it’s worth to take a look at the infographics by New York Times Visualization lab. They are amazing. Speaking of paying for studies, you can check out this interesting visualization about the dynamics of Student Debt of Colleges and Universities Across the Nation.
One of these 3 options would be enough to get you started. In the future posts, I will show how data visuals can be used in agile project management.
Visualization: Understated or Overrated?
DataViz 101: Sparklines
My 12 Visualization Books
The Paradigm of Project Management Tools