Visualizing the Big Picture

September 18, 2012

 

Agile is all about “whole team” experience. We plan together, code together, and retrospect together so that everyone in the team is all on the same page. Nevertheless, once your team or your project grows bigger, teams start to get lost in pile of user stories and it gets harder for everyone to see that same big picture. This blog discusses various ideas to visualize this big picture. Not for just product owner, or managers by for everyone.
 
In ideal scenario, an Agile team is supposed to be crystal clear about the iteration and only have a rough plan for the rest of the release. What actually happens many times is team rushing to get the current iteration done with little idea of what is coming. They simply lose the big picture. Often, this picture is kept in a head of a single role like team lead, business analyst, project manager or even a ScrumMaster if he or she does not really push for self-organizing. Many teams do not know much about anything beyond the current iteration and they often do not care. This is probably fine in some context like  in small short-length projects but in many cases, this will lead to bad ending as the team might have no idea that they are getting off the track even their progress seem to be on track. 
 
When you are working with hundreds of user stories, it is easy to get lost in details.  Release burndown chart is a classic progress visualization tool in Agile team and it is very effective to portray team progress in term of speed and progress. It can nicely show the summary based on story points and status of these hundreds stories. It has its own unique beauty but it may not be enough. What if you arrive on time but you find out that it is the wrong destination! The burndown chart can tell WHEN it will be done but not WHAT has been built.
 
 
How do we visualize this big picture? In the attempt to find this answer, I have stumbled upon a few articles.
 
The first visualization is the “Relative-Size” Parking Lot Diagram mentioned in Parking Lot Diagrams Revisited – Using Area to Show Effort by Mike Griffiths written in 2009.
 
 
The traffic light color-coding here represents the urgency e.g. red means it already missed the schedule while green means it meets the deadline. Most of the items are still in yellow since it is still progressing toward the deadline. The relative size is the improved version of the original same-size Parking Lot diagram. The bigger the box the bigger estimate (in story points) it has.  This diagram is quite easy to understand but it is very tedious to manually produce by PowerPoint as the author pointed out. The blog also mentions a few other ideas including a simple scaled bar chart which is easier to produce with Excel or coding.
 
 
Another visualization which I find making very much sense to capture large and complex data set is from Visualizing a Large Product Backlog With a Treemap by Mike Cohn written in 2008. Despite it was written many years ago, Mike’s recent comment still confirms his believe that it is still the best way to visualize large project.
 
Yes, I do still think this is the best way to visualize a large product backlog. Treemaps have stood the test of time for things like visualizing the stock market so I don’t expect them to be replaced as a good technique for us any time soon [Mike Cohn, May 11, 2012].
 
This treemap below is derived from current backlog of Eidos beta release drawn by Google Chart Tools API. The darker green the block,  the further the epic has progressed and their areas are relative by Epic size (sum of story point of all its stories). This treemap tells us that Eidos is almost ready for beta since many big Epics are complete. 
 
 
These pictures give us a good snapshot of today but it does not tell us anything about the past or the future since there are only two dimensions of the data here e.g. Epic size and status. There is no dimension of time.
 
The dartboard-like diagram bellows, mentioned in Epic Visualisation for a Product by Nicholas Muldoon, visualizes “planning” of each Epic represented by each section. Each square note is a story. The inner circle is the current release and the next 4 outer circles are the next 4 releases. The notes outside the circle are the unplanned stories. The traffic light color-coding represents readiness of the stories ranging from red, to yellow and eventually green.
 
 
Though this diagram shows the dimension of time, it does not really show the relative efforts among stories. Perhaps, it can easily be enhanced by making the size of each note reflects its relative size.
 
For Eidos, we are researching on how to effectively visualize the big picture. One additional idea to what already mentioned is the Stacked Area Chart below. This chart does not only show relative size and status but also their progress through time. For example, you can see that we have worked on the Storyboard and StoryCard epics from the beginning but we just starts putting in IterPlan and Attachment in iteration 6.
 
Another idea is to show the Epic progress under the burndown chart as shown in the original Eidos screenshot below.
 
 
What do you think about these visualizations? Do you like the parking lot, the treemap, the dartboard, the stacked area chart or epic progress under burndown? How do you visualize the big picture of your project? We love to hear your thoughts.
 

 

  • http://www.facebook.com/suthep Suthep Sangvirotjanaphat

    In short, I like the treemap.

  • http://twitter.com/kontulai Ilmari Kontulainen

    stacked are chart reminds me of cumulative flow diagram, which is better than burndown chart