Mind Map Reuse in Software Groups

Mind maps are used for exploring, clarifying, explaining, or planning. They are an effective way to gather and depict information. This could be information that we want to learn or knowledge that we want to share. We may want to focus on certain points, such as abstracting a number or details. Alternatively, we may want to plan our work ahead or explain how things work in detail. Brainstorming and finding connections between different ideas, solving problems, and creating new ideas, mind maps are a useful tool in our professional or personal lives. They go well beyond software development and they can be used in any human endeavor that requires critical thinking and decision making.

A mind map could be anything that organizes our thoughts — drawings, diagrams, tables, keywords, pictures, graphs, Wikipages, and so on. It can be done with a pen and a paper, a marker and a board, or using mind mapping tools like Coggle, MindMeister, Ayoa, MindNote, XMind, etc. 

A number of software groups that I’ve been working with have been reusing mind maps to release features. Product owners, developers, and testers have found an effective way to avoid missing use cases and identifying edge cases. This helped toward requirements clarification and disambiguation, testability and completeness. Reusing mind maps has led to fruitful discussions, educated decisions, and information exchange between teams.

Development Method Used

There exist different development methods, like waterfall, agile, lean, extreme programming, prototyping, rapid application development, and others. There are also different flavors for different methods, whilst hybrid combinations could also exist. We will not focus on which method, flavor, or combination is better, but to avoid confusion, we must clarify that this article assumes an agile-like whole-team approach. Development teams contain (at least) developers and testers, and the team’s work is divided into missions. Each mission contains features to be released. For each mission, a product owner is assigned that focuses on business decisions for customers.

Mind Maps for Different Roles in a Software Group

Product Owner

The product owner helps customers define functional and non-functional requirements. After all, this role tries to make the most out of development teams in each mission by fulfilling all requirements. This implies that all team members are pursuing a common goal, establishing priorities so that they work on the highest-valued functionality. Decisions are also made that lead to a good return on investment per mission. What is the value delivered per feature? Which feature is more important for any given set of features? Which feature should be developed first, which second and so on. What did the customer request?

A mind map from a product owner could be per feature, or it could involve multiple features or the entire mission. This depends on the feature size and on the scope of the mind map. 

Size

To analyze and explain large features that contain a lot of functionality, it will require more space on a board. When many large features are put in the same mind map, things may get difficult to understand. When a mind map contains tons of information, it is easy to miss details, and people usually get discouraged using it. However, when the scope of a mind map is to depict the functionality delivered during an entire mission, if large features are involved, then careful decisions will need to be made on what to abstract.

Scope

A mind map depicting interdependencies at a business level between different features will probably include only the interdependent features. A mind map focusing on a feature and its sub-features will probably abstract all other features. A mind map focusing on the security aspects of the delivered features will probably depict only the features involved in the security use cases. This is the context that needs to be clarified as far as a product owner is concerned.

Developer

Developers need clarity and completeness about what should be implemented. They decide how to write the implementation code and their tests. Based on mind maps from the product owner, they can create their own mind maps. It’s up to the developer what information should be depicted (the scope of the mind map). Is it used to clarify code interdependencies? Is it used to explain how things work? Is it used to depict what has been unit tested and what not? Is it used to request clarifications from product owners? Is it used to depict specific areas in the code that require attention from testers?

Entity-Relationship Mind Maps

Entities and their relationships are a basic way of analyzing software systems. Entities could be specific to the domain in which we are working, such as invoices for accounting systems, items in inventory systems, nodes in network management systems, or friends in social networks. Exploring entities and their relationships in a mind map has helped development and product teams achieve alignment on what should be developed. It has also helped testers identify edge cases and brainstorm with developers about performance bottlenecks.

State-Transition Mind Maps

Identifying events that trigger transitions between states is another way of analyzing software systems. For example, a log-in event may have triggered the transition from a logged-out state into an authorization state and then a logged-in state. States can be directly controlled by the UI and easy to identify like logged-in/logged-out. They can also be subtle, triggered by the passage of time (e.g., timers in our software system have expired) and are uncontrollable by the UI, like authorization. Mind maps depicting states and their transitions can be helpful in implementing and debugging. They can also help to identify edge cases and reproduce sporadic bugs.

Tester

This role tries to make sure that bugs are found and fixed before releasing features to the customers. After the release, testers try to verify that the evolution of features follows certain quality criteria. Testers create and execute (UI or API) tests from requirements. Mind maps from product owners as well as from the developers could be very beneficial. A product owner will include functionality that needs to be released. This is excellent for test-case design in black-box testing.

Some development teams created mind maps to depict what has been tested at a unit level. This indicated to the testers what has been tested and what not. Testers may augment development mind maps to make sense of what needs to be tested. Here lies grey-box testing information.

There were cases when developers shared mind maps depicting areas in the UI that needed attention from testers. This was another major source of grey-box testing information. Based on this kind of feedback from developers, testers could focus their testing efforts.

Ecosystem Mind Maps

An ecosystem includes the environment in which our software lives, all the interfaces into our software, and all the external dependencies. A mind map of the entire ecosystem could give a clear picture for investigating connections, dependencies, and risks associated with the parts of our system that are outside our software’s control. 

One team used ecosystem mind maps that depicted how their software connected to the outside world. The focus was on the interfaces, users, and connections to integrated systems.

Another team used a deployment-based ecosystem mind map. It was focused on where the components that make up their system, such as databases, configuration files, and executables, live in a production deployment. 

Ecosystem mind maps helped testers to devise their own positive and negative testing mind maps. They also helped product owners to get a bigger picture of their software and consider use cases that would have been missed on requirements. Developers found edge cases that needed special attention on their code.

Wrapping Up

Mind maps are reusable, tailorable, and can be mixed and matched according to our needs. They can be an effective tool for exchanging information and boosting confidence between teams to release features. After all, it’s all about aligning with the common goal of making customers happy.