At any point in the software development life cycle, brainstorming on a whiteboard or on paper, proves to be enormously helpful in fleshing out thorny requirements. Whether it’s in the initial stages of discovery when you still are figuring out the core product or whether it is during development when developers raise questions that overturn or discover loopholes with some of the initial thinking; brainstorming will always be powerful.
There are many brainstorming techniques available for your analysis. You may opt to go with Mind Maps, Fishbone Diagrams, Flowcharts, SWOT Analysis, Starbursting, Affinity Diagrams or Concept Maps. But even if you are not well-versed in these formal methods, don’t hesitate to map out on the board your way of thinking and visualization of the concepts being discussed. It doesn’t matter what the name of your diagram is, or even if you don’t know the name at all; you will experience the power in all cases.
Here’s a list of powerful effects:
- Your diagram will highlight the components of the core process versus the subsidiary processes. Sometimes we get stuck in the details within the detail which prevents us from getting through a project from end to end and then tackling the details later. If you plot the core process on a board, it can show how what you are discussing is merely a detail that can be tackled later. Or vice versa you can show how a core piece of the process was missed whereas subsidiary processes were given too much priority.
- When planning a system or feature, your diagram will help show what part of the process in the business will be done in the system and what may be kept outside of it. This is especially useful when building MVPs (Minimum Viable Products) where you need to prioritize MosCow and decide what features are not needed in the system. Sometimes features that do not have a ROI are built simply because the users just want everything in the system. However, if the discovery focuses on the whole process and presents outside solutions for areas that can be without, then many savings will be realized. In addition, the system can be streamlined to cover the core process with additional features and nice-to-haves added at later points.
- Your diagram will visually depict dependencies in a process/system. An issue with a feature may be because it was developed to always assume a specific preceding scenario that isn’t necessarily true in all cases. A diagram (usually a workflow chart in this case) will show how the point in time of this feature may be preceded by different use cases and the feature needs to accommodate all those cases.
- When you have many different combinations of use cases, a diagram can be used to organize the many different use cases and show the user journey through them. If this area isn’t brainstormed correctly you may result in a feature set that can have users end up at a dead end.
- Sometimes you’re all just saying the same things in different ways! If you diagram it and the words are represented by circles/boxes, you may pleasantly discover that you were on the same page all along.