In the early days we promoted agile only for small teams because that was where it originated. We had plenty of experience to say that agile worked well on seven- to ten-person teams. We were also quick to learn the techniques that allowed agile to scale up to around 20-40 people.
These days, though, there are many truly large projects being done with agile. In preparing for this posting I started counting on my fingers the number of 100+ person projects I’m aware of. I quickly ran out of fingers. I’ve been involved in a couple of 500+ person projects and am aware of three projects that each have over 1,000 people. We are truly at the point of doing large scale agile.
Unfortunately, the charts and tools we use for such large projects have not entirely caught up with us. For example, the time-tested Scrum burndown chart is absolutely wonderful but is really limited to showing only one thing: a single team’s rate of progress through their product backlog. This month I want to write about visualizing large product backlogs using a technique I’ve been advocating with my clients for three years but will be writing about here for the first time.
Suppose you have a very large product backlog–such as one with lots of themes (groups of related user stories) or being worked on by multiple agile teams. The best way to visualize this product backlog is with a treemap. Treemaps were invented in the 1990s by Dr. Ben Shneiderman as a way of visualizing hierarchical (that is, tree-structured) data.
The following is a simple treemap of a two-story house:
In this treemap, each rectangle is sized to represent the relative area of the room. From it you can see that the master bedroom is about twice the size of either kid’s room and a little larger than the downstairs family room. The combined green area of the downstairs rooms is slightly larger than the area of blue upstairs rooms. From this very simple treemap you can get a feel of certain aspects of this house.
To visualize a product backlog with a treemap we need to conceptualize it as hierarchical data. We can do this a couple of different ways. For example,
Rental Car Theme
- As a traveler, I can rent a car
- As a traveler, I can get collision insurance on a car rental policy.
- As a traveler, I can request a baby car seat be inside my car.
Airplane Theme
- As a traveler, I can request an aisle seat.
- As a frequent flyer, I can request an upgrade to first class.
Or we could create a product backlog as a tree with levels for
- Team
- Product Backlog Items Being Worked On By That Team
The following figure shows a product backlog as a treemap. There are five themes in the treemap. (Theme 4 is in the top left; Theme 1 is in the bottom right. You can click on it to enlarge it but be sure t come back.) Each theme is made up of a number of individual user stories. Story 4-28 (indicating the 28th story of theme 4) is in the top left. I’ve used this “theme-dash-story” notation for simplicity only for this example. I wouldn’t do that on a real project, of course.
The size of each story in the preceding figure represents the number of story points that the story was assigned when estimated. Colors can be used on a treemap to represent an additional attribute of the data. On agile projects I’ve used colors to represent whether a user story has been developed or not. One color coding we used was:
- Done
- Started but not done
- Not started but not planned to have been started yet
- Not started but it should have been started by now
- Blocked
I’ve also used color to indicate which team would work on a user story / product backlog item or whether the item was ready for development or not. Treemaps are very flexible in this regard. Check out the link to the stock market as a treemap at the end to see a great example of using color.
A good treemap is interactive–you can mouse over, click on regions of it, and so on. For example, in the treemap above you’ll notice that some of the user stories of Theme 4 are so small you can’t read them. Clicking on a part of Theme 4 should zoom the treemap in so it displays only Theme 4, meaning more room is available and more detail can be shown as below:
Sometimes zooming isn’t enough. A good treemap implementation will also display additional detail when mousing over part of it as shown in this example:
Treemaps are an excellent way of visualizing large product backlogs. To date, I’ve made use of various open source or relatively inexpensive general treemapping tools to create these on my projects or for my clients. Hopefully now some of the leading agile tool vendors begin to incorporate this type of visualization technique into their products. I would love to be able to visualize a large product backlog and interact with directly from within some of those tools. Until then, check out some of the links below for useful ways to create treemaps. The ones in this posting were created with IBM’s free Many Eyes tool.
Useful links:
- The stock market as a treemap
- IBM’s Free Many Eyes tool
- A good interactive example of a treemap
- Read news headlines as a treemap
- A simple JavaScript implementation you could add to your project homepage
Tags: agile release planning, large projects, product backlog, product owner
We’ve implemented this idea in TargetProcess about a year ago. User stories and bugs in iteration/release backlog size represent the effort and color used to show the priority.
http://targetprocess.com/Product/agile_tour/Releases_Iterations_Planning.aspx
Hi Mike,
I really love this idea, in my company we use very compelx and boring tools to control requirements. If you don’t mind, could you give a “more real” example?
Thanks…
Hi Wesley–
I’m glad you like the idea but unfortunately I don’t have time to make a “more real” example. Just go onto the IBM website and upload a product backlog of your own with a column that indicates the themes and another that indicates the story body.
If you’re struggling with what themes are, I’ll give a brief example that I almost created in the tool when I made the original examples. I wrote the Scrum Alliance website product backlog and we had a theme called “Articles” with stories like “As a user I want to read articles” and “As a user I want to see the most popular articles on the home page” etc.
great article ,
I’m definitely going to experiment with this visual representation on my next project,
although one limitation I see with this approach (and themes and user stories in general) is there’s only support for two levels in the tree.
If you use use case briefs organized into a hierarchy like as described by Alastair Cockburn in http://www.amazon.com/Writing-Effective-Cases-Software-Development/dp/0201702258 , you have the vantage of truly scaling out the concept to really large programs… (I guess you could call them uber-themes or something like that that sit on top of themes)
I talk a little bit about this approach at http://agileconsulting.blogspot.com/2008/02/can-use-cases-be-used-in-agile-way.html
Hi Jeff–
Thanks. But this approach is still applicable with multiple levels of stories/themes. The techniques can be applied recursively exactly as with narratives.
Visualizing a Large Product Backlog With a Treemap…
Mike Cohn writes about using a treemap concept to visualize product backlog. What is especially nice about this aproach it is that the estimate becomes more tangible….
Mike,
Thanks for this timely idea. We are developing a Web-based Scrum tool- ScrumPad (http://www.scrumpad.com). We implemented themes as tags, but were investigating how best to display large product backlog. This is something we would incorporate in our product soon. I agree we could organize themes at any levels, but I would say having a few level deep might make a product-backlog unnecessarily complex than it needs to be.
Hi Mike,
I like how this visualizes, but don’t you need to have a consistent scale of all your story points across the entire project? If you don’t have that, the sizes won’t be equal. With 500+ developers on a project, getting some consistency across all of those people would be quite difficult.
Hi Shawn-
Yes, you would need to have a consistent scale for all stories. There are ways to do this but since I haven’t blogged about it before I’ll try to do so soon.
Hi to all,
we implemented this great idea in ScrumDesk.
See more on page http://www.scrumdesk.com/weareworkingon.html.
Mike,
I was re-reading your excellent Agile Estimating and Planning book, and again came across your suggestion on how to establish a common basis for estimates. You mention in your previous response (July 19th) that you would blog about this topic soon; do you have new recommendations, or just the tips from the book? Thanks …
shawn.
Hi Shawn–
I’m glad you found the Agile Estimating and Planning book to be useful. The advice on establishing a common baseline that I blog about here (as soon as I can find a spare 10 minutes) will be consistent with what’s described in the book.
–Mike
Hey! thanks Mike this was great posting it will actually help to be more organized, I’m a big time management nut so, this kind falls directly into my home base visualizing allows you to look ahead and see any hiccups that may be in the road (kind of like a road map).
Mike, nice article. I can see tree maps as a useful visual tool for viewing the realtive size of themes against each other, but they don’t seem to indicate progress and projected finish time well. It seems you could do “theme burndowns” or “burndown rollups” across teams very easily. They would also be accurate as long as you have a consistent baseline for story point estimation.
Burndown charts still show progress best in most cases. Color can be used to show some degree of progress with tree maps. Usually I use them that way and if the color indicates a troubled theme, I go look at a burndown chart or talk to the product owner and ScrumMaster about it.