DataViz 101: Sparklines
Today, as a part of the DataViz 101 series (check out the previous installments: Visualization: Understated or Overrated? and Data Visualization 101: A Basic Guidance), I will write about one tiny graph which can be used as a report in agile project management, be it Kanban, or Scrum, or any custom mix of those.
What is a sparkline graph?
In the non-project management world, sparkline graphs serve as quick mini-reports featuring the dynamics of certain states or activities over time. They usually look like tiny ragged lines. Here’s the definition:
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 simple terms, sparklines are used if there’s no room, nor time, nor space for the 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:
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.
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 “a recency bias”.
Compare these 2 images:
The upper image shows the yearly dynamics, as a table. The sparkline in the lower image 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 subtler 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’d take too much space to render such a report as a table, for 2500 numbers, and for each day of the year. Plus, in this case “the recency bias” would influence the analyst’s perception. Table reports cannot cover a 365-day span with the pluses (“+”) and minuses (“-”). That’s why sparklines work better here.
Sparklines in Project Management
Let me now show how sparklines can be used in 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, because 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 at the top and at the bottom represent the max. number of user stories done or added, respectively, in 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 have been done in those 16 weeks (at the top) and how many were added (at the bottom). Same for bugs: the total fixed number is at 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 would be very helpful. With the least time spent, you’d get the maximum info. And — yes — there’s no recency bias. The whole span of 16 weeks is wrapped up in that little space.
This is 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, it’s likely that at the moment this team is working to make the release stable.
Finally, this logic which has taken me quite a bit of space to explain here, can be condensed into a mouse-over text tooltip.
I hope this short article helps you see how and why sparklines are used in data and information visualization.
Related:
Visualization: Understated or Overrated?
Data Visualization 101: A Basic Guidance
Further reading:
This story is based on an earlier article.
