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