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.
Join the DZone community and get the full member experience.
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.
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.
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.
