DataViz 101: Sparklines | Targetprocess - Enterprise Agility Solution

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:

Targetprocess Image

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

Similar posts:

Data Visualization 101: Basic Guidance

My 12 Visualization Books

Subscribe to the latest updates

Thank you!

Сheck out latest blog posts: Show all

Or contact
a sales representative

Get a live
product demo

Let one of our product specialists create your account
and shape Targetprocess for your company needs.