I like experiments, I like to try and encourage others to experiment with ideas. There is safety in a properly organised experiment. Test out your theory but limit the downside. Allow yourself to get an understanding of why something worked or failed. Slowly tinker with the structure to improve the results. People and teams grow on the back of experiments. Fear of failure is not a reason for not experimenting, it is a reason to start experimenting.
I’ve been a fan of mind maps, on and off, for quite a while. In more recent times I’ve become much more consistent in my use of them. The strong visual representation of ideas really works for me. When I move information from the a flat paragraph to a visually rich representation I get a level of insight that really helps my thinking.
Recently I introduced the idea of using mindmaps to the scrum team I work in. There was a lot of positive interest. I was confident that this would work, the team didn’t have the same background, they, reasonably enough, wanted to see the proposal in action. We agreed we could experiment and ensure that if things didn’t go so well we could recover without too much effort. Accordingly we selected a small project.
We approached this by mapping the epic, decomposing to user stories then finally acceptance criteria. Even for a small project this approach led to some amazing discussion because we could clearly see relationships, unintentional crossovers and potential conflicts or gaps. We actually identified a user story we did not need. If this approach is going to consistently trigger this level of discussion, that alone is ample pay off. The result was a very understandable, useful mindmap that could be used to clearly demonstrate the current project thinking, and understanding, to stakeholders. Should we need to make changes the overhead will be minimal and the impacts easy to see.
At the close of this meeting I decided to continue this work and map test ideas in to the framework. At a high level this showed coverage of the acceptance criteria as well as other wider considerations. I do this anyway as part of me thinking my way through testing a story but it was great to be able to tie it back to the same kind of thinking. It delivered a picture of understanding we had not, as a group, produced before. Should something change between now and when I can start physically testing the code, no big deal, these are high level ideas not low level scripts.
It didn’t stop there. After the meeting one of our team members was so pumped about the process and the results she published the example to the BA and PO Guild lead. I love seeing people buy in to an idea and then start evangelising for it. There was an interest in the Guild – awesome! My team has decided we need to do more of this and we have a few more small projects on the horizon that will be great for this purpose. There is some excitement that we have found a way of communicating that will add efficiency to our process and help us improve the quality we deliver. Already we believe this can translate to bigger gains when we move to larger and more complex projects.
I would like to expand the use of mindmaps well beyond our current use, but for the moment I’ll settle for demonstrating value to the business, that will help build trust (I say business as the mindmaps will not get to clients at this point) . We have generated an amount of interest in a key group that will help keep interest bubbling. I’m hoping that this is the start of a meaningful change. As a team I think we are capable of creating the path. I’m hoping soon that one of the other scrum teams will decide to try this approach as well. That kind of organic growth is exciting.
If anyone would like to add comments about their success or problems in using mindmaps I’d love to hear from you.
Regards
Paul
@Beaglesays 
This is an interesting idea, simpler than user story mapping. However, branches of a mind map just float around, so it is tough to determine the priorities, isn’t it? Do you use this just to break down something you already know you have to do, or is there’s something I missed?
LikeLike
Hi Michal,
thanks for reading the blog and posting a question. I see story mapping as a little different, the client being a central part of the mapping process. The user stories have evolved at the point I’m discussing. I would like to get to story mapping and BDD but the culture to support this is not in place yet, and might be some time coming. I can try to influence the culture change but much is outside my control. Working with my scrum team, and a bunch of people enthusiastic to try new things, changes the dynamic. This is really about understanding what stories sit in front of us, overlaps, gaps, etc. It helps reduce complexity and identify relationships. Because the information sits in an easy to read structure the details are easier to comprehend than when they sit in a series of separate user story cards. you have a useful holistic view.
Regards
Paul
LikeLike
Hi Michal,
I just realised I didn’t answer your question around priorities in my first response. In the project I discuss in the blog this was not an issue but I think you should be able to highlight priorities. You could use markers (in Xmind) or colors (any mind map tool). In upcoming projects it will be a requirement that we highlight priorities. Something else to think about is that you can easily recognise cross story dependencies as well as priorities and then can also be highlighted. This is a powerful way to present information.
Again, my thanks for rading my blog and raising your question.
Regards
Paul
LikeLike
Hi, Paul!
I’d love to hear a little more about how the mind maps enabled you to see unintentional crossover and potential conflicts. Is that something you could speak to without revealing the details of the project?
-Carol
LikeLike
Hi Carol,
thanks for reading my blog and sending through a question. I think there are 2 parts to answering your question. The first is that the mindmap contained minimal information. Enough for us to know which user story was which (we track our user stories in Jira, they hold more detail). So we are working on just enough information to be useful, this allows us to focus on the relationships. So we talk at a different level as we are not thinking fine detail and we are discussing concepts more holistically.This is how we realised we had, effectively, doubled up on a user story. The discussion drove us to the conclusion that what we thought was a user story was really just a set of acceptance criteria for another story we had already captured. We also realised that some of the acceptance criteria were really not as useful as we would like. I think without a mindmap approach we would have found this anyway but we would have found it later rather than earlier. We did this in a small project context. In a larger project context these kinds of finds will be really valuable. I think the value of this exercise is that mindmapping help set out relationships and can efficiently remove complexity. This encourages people to discuss, that then generates ideas. I’m a big believer in the power of “group think”. I’m really looking forward to taking this in to a more complex project. That should happen in the near future. Once it does I’ll add another entry to discuss what I’ve found.
If you have any further questions please ping me. I’m very happy to talk about this with other people.
regards
Paul
LikeLike