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

3 thoughts on “Advantages of story-trees

  1. I have one problem with story-trees as “feature lists”. Some features are dependent on other (i.e. several) features. I’m sure you can relate to that so how do you handle it?

  2. You’re right. When a story is dependent on more than one story, it is difficult to represent it and this relationship. One way I would handle it, is just pick one of those stories as the parent story, and rely on the prioritization process to ensure when the set of stories get implemented.

    The other way you can do it is pick the ultimate parent of all the stories your particular story is dependent on, and make that its parent. That way, you can decide to play the story only when its parent is “done”, and that might be done only when the parent’s other children are done.

  3. Well, some instruments for creating ming maps allow to link dependent leafs together in the way they won’t be connected as parent-child. So two leafes will be connected as dependent, but will both have their own parents. That could be a solution.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s