Advantages of story-trees

There are several benefits of using story trees, and they’re primarily in two areas –

Backlog (or Master Story List) creation:
Mind maps, which can be used to create the story trees in the first place, make for an excellent tool for facilitating brainstorming sessions within the team
– They’re also a fundamentally intuitive tool for thinking about things, and this in itself make things very easy

During development:
– It is easy for a developer to look at a story title in the context of its tree and understand the workflow it belongs too, and the business context in which it was created
– It is an easy, visual way to see what stories are connected to what other ones, and how the dependencies might turn out. It also helps in managing those dependencies across those stories, because of its visual nature.
– Speaking of how things are related, it is also easy to see areas or pieces of functionality that are impacted by change in a particular area. Not always, but this is useful many times.
– By color coding the nodes and leaves of the tree, say based on status, priority, size (t-shirt sizes or story points) or whatever else makes sense, one can render different view of the story tree, which can communicate different things in a very easy to understand manner
– It is a very useful tool with which to have meaningful conversations with the customers. When asked things like where scope-growth was occurring, or where they might look to trim scope, the tree becomes a useful talking aid. It can be color-coded to show times ranges when certain stories were added, etc.
– Finally, story trees are useful because they always pitch the topic of conversation (say about a set of stories) in the context of the entire graph of requirements and business work-flows. This perspective is often lost, and is extremely useful when having certain kinds of conversations (the important ones).

Requirements management, user stories, mind-maps, and story-trees

For those who’ve been following along, I recently started a new project team that’s working on pretty much a green-field type of a project. I’ve been using mind-maps to kick things off, in various areas of the teams’ initial effort, and have now extended it as a way to build the functional backlogs that the teams will work on.

Essentially, what that means is this – imagine that we, along with an analyst (or a team of analysts) sit down to brainstorm an area of the application. We always start with the high-level ‘project’, lets call it Todos2Go. Just to retain context, lets also go ahead and list out the high-level functional areas of the application. These include modules we already discussed and elaborated, they certainly include new modules we want to include in our system. So in our example, Todos2Go would start with the basic todo-list creation module. It might also have a collaboration module, a search module with advanced search options, a calendar integration piece, an RSS generation module, an email interface module, a tagging and tag-browsing piece, and others. The analyst team doesn’t worry about trying to capture everything at any given point of time, knowing that they will be revisiting these requirements (the mind map) whenever they need to. So at this point, here’s what we have –


Remember, we’re only capturing functionality from a business requirements perspective right now. Things like config-management, architecture, etc. are somewhat orthogonal areas. They’re captured in a different mind map. Also, we’re not concerned with scheduling right now – as in, when a particular piece might get built. Those decisions will be made based on business priorities, technical dependencies, and developer estimates. So, onward! Lets continue following the analyst team as they keep using the mind map to go further and further into details.

The analyst team picks one module that they’re going to focus on for the moment. They decide that since they’re just starting the project, they might as well pick the one they know best (from previous versions of the software, or from market research) – a basic task-management feature – the Todolists module. So they start to discuss the things the user might want to do, and/or how they would like to break the functionality down for development. Here’s something they might come up with –


The idea is simple. Keep breaking things down as you go down a path of functionality. In other words, go ahead and do plain ol’ functional decomposition. Again, remember to view things from a business requirements perspective. This means that ‘design database schema’ is probably not something that ought to appear on this mind map. The numbers next to the items are simply ID numbers, for tracking purposes, and will be of use later on. This view is what I’ve started to call Story Trees, thanks to a colleague – Roger Marlow.

Also, since most people use Excel to track projects (so do I, and I will continue to do so until Mingle launches), here’s how I capture this meeting artifact (it’s usually a whiteboard thing) in a spreadsheet –


The Parent ID column is simple. It is just the ID of the bubble in the mind map that is a ‘parent’ of a given bubble. This way, a simple script can be written to reconstruct the mind map if needed. The reconstructed version of the mind map can sport color-coding based on status, priority, or whatever else one might consider useful. More on this script (or my version of it) in another blog post.

So, I do hope this was useful. This is a simple meeting technique for project managers to use to facilitate requirement gathering workshops or business analysis sessions. Again, as I mentioned in one of my earlier posts, I do not use software/laptop/projector in my meetings because it is just not a good, interactive way to run a meeting. I use a whiteboard, flip-charts, and Post-Its. Later, I use software to capture it.

Coming soon – more benefits of Story Trees.

P.S. – Please pardon and ignore the horrid use of the generic term ‘user’ in my story list. We typically use personas, the focus of this post however is the story trees.

Using mind maps to start planning a project

As you might have read earlier, I recently started a new team that has been chartered with building a suite of new products from scratch. The business folks have been working in the domain for a long time and have built similar products before. Despite that, requirements for the new products have not all been nailed down yet, making this project somewhat of an ideal situation to start a new team. We’re using Agile (Scrum with XP practices) methods, and I’m infusing several ideas from Lean Software Development into the mix.

I used a new tool to kick-ff the high-level planning sessions this time. I’ve been using mind maps (FreeMind, Mindjet Manager, and NovaMind) for a while now: for various things – keeping track of to-dos, planning my personal projects, thinking about high-level goals, brainstorming and brain-dumping, and so on and so forth. I’ve always felt that such an intuitive tool might make for a great way to facilitate work sessions, especially when the work at hand is fairly high-level. An example might be – early stages of planning.

In my opinion, using the tool turned out to be quite a good idea. The first meeting lasted three hours (including coffee and a 10 minute break), and had about 12 participants with me facilitating using a whiteboard and sticky flip-charts. I ended up with several mind-maps including one for the overall project layout, one for training requirements, and another that detailed a particular module. The whole team was able to participate in building it as it was merely a form of a brainstorming exercise, with some extra structure.

Here’s a mock-up of one of these mind maps that got produced at this session –


One possible next step is to pick up the area which needs to be worked on first (actually this will probably be more than one – for example, the architecture-spike and config-management piece will need to be done in the beginning regardless of what else gets picked up) and continue to drill-down into its details. When sufficient granularity has been achieved, the leaf nodes of the mind map can be translated into backlog items (or phrase-level user-stories). Of course, this will mean that the brainstorming will need to be done with an eye towards this end goal – and all the guidelines around writing good user-story phrases will need to be kept in mind.

Overall, it was a good exercise – it was interactive and fun. More importantly, it was a visual way of representing the project and its potential scope – and was a great start at arriving at a shared mental-model of the system. Having all members of the team present (developers, QA, BA, and sponsors) helped a lot as well.

Note: I didn’t use the actual software in the meeting, instead, I chose to draw on the whiteboard and one of the participants (the sponsor!) volunteered to scribe. This let the session be more about the content than about formating and word-smithing. I later converted the notes to soft-copies using FreeMind.