I've been doing a fair amount of requirements gathering lately across a number of projects that I've been working on. At the start of each project I needed some way to get a handle on the size of the project and I wanted to do so in a way that improved customer collaboration while helping me structure what the project was all about..
Enter user stories. For those who don't know - user stories are requirements written in the form of "as a <role> I want <something> so I can <reason>". They're short one sentence structures that act as a mechanism for drawing out not only what a system needs to do, but also why. The why often being the thing that is overlooked in traditional requirements documentation. Stories are also of great use when trying to compile a product backlog and prioritise the order in which work should be carried out.
Now in times past I would've sat down with the customer, opened an Excel sheet or One Note section, and started writing stories right there and then. On the screen. In front of them. In one great big long list.
And this works really well.
The customer gets involved in the story writing, in the flow of developing stories and describing roles. It's engaging and fun and the customers love the involvement. Now here's the wrinkle - we like to write stories in groups of related items so it's easier to keep track of what our thinking is, but unfortunately people aren't linear creatures. We tend to jump around, go off on sidetracks and tangents, work our way around a problem, attack it from different angles and generally approach things in a somewhat random but related manner.
When you try recording stories in an excel sheet and you get more than a few hundred of them it starts to get really hard to figure out what stories relate to which parts of a system. The customer asks "can we go back to where we were talking about thing X? I want to add a few related stories because I've forgotten some stuff". So we look at the list, realise we can't remember where those other stories were and start searching for keywords until we find the area we want. Over time it gets kind of confusing. Also, unless you tag your stories with a functional area they relate to, when you come to collate stories later on you can waste a lot of time and gets things mixed up very easily. Didn't we cover this already? What should this be related to? etc.
Enter Mind Mapping
Mind mapping, for those who don't know, is a technique where you start by drawing up a few basic ideas and then expanding on those ideas as you think further about them, creating other sub-ideas and so forth. When you find related ideas you link them together or branch off ideas based on a core theme or concept. Over time you end up with a whole raft of ideas that are all interrelated and linked in some way. Mind maps are a great tool for visualising this approach.
So these days when I'm gathering requirements I use this technique but instead of starting with a core idea I start with a placeholder ("the system") and then branch off into the things that people want the system to do.
Normally people start off with some very high level concepts, and then you start to flesh out those ideas eventually working down into the details. When there is enough detail to write stories in then I start adding the stories directly to the mind map.
Here's an example:
Where this gets useful is in the way people think - you can now visually jump around the mind map and easily navigate to where concepts and functionality are located. Also, you end up talking about things from the customers view - it's their mind map you are helping to draw up.
If you keep at this for a while you can create some fairly large and complex requirements maps - for example the one pictured below has over 1,200 nodes on it yet it's still easy to navigate and find items plus the customer is able to understand what it is that they are asking from the system without getting lost in the details. I find it hard to do that effectively in an excel sheet, or with story cards alone, so I shudder to think what a struggle it is for my customers.
Don't confuse things here. A mind map is not the ONLY thing I use for requirements. I still work with user stories, I still do sizing (though often on the mind map itself), I'll still record stories in excel or TFS or <tool of choice> and I still prioritise them with the customer.
The mind map is just a tool to assist in the effective gathering of requirements, and it helps my customers think through what they want more clearly. This helps reduce the number of missed requirements and improves understanding between us and I think that's a good thing.
Mind mapping is just one more tool for your agile development toolbox. A useful tool, but not at the exclusion of anything else.
P.S. The software I've used here is FreeMind. It's a little more structured than some of the other mind mapping tools out there, which I find useful when working through requirements and wish list items.