2018-08-22 , 7 minutes read, 539 views 0 comments
Have you covered all of the edge cases? Where have you ended your job yesterday, and how much more work needs to be completed? Are you going as planned? Oh, and what were you doing before that junior dev came to your desk to ask for some advice? These and even more questions can be partially solved by mind maps - let me show you how.
What mind map is
Mind map is a diagram used to visually organize information. On the center of the map, on it's root as we - programmers - like to call it - you'll find starting point, your main, abstract concept. Around it you'll find branches - connected ideas, that later split into others, more specialized leaves. Following connections and overall structure, you'll see relationships between them and the main concept in the center.
Below you can see example of a cool mind map inspired by the one found in Ursecta article:
Mind map can be build just by connecting text labels with lines, but you can also use images, videos, icons and colours to make them even easier to understand - they may end up being perceived almost like infographics. They can also be quickly drawn by hand on a small peace of paper or on a blackboard in the office.
History of mind mapping goes back to Tony Buzan in 1970s, who promoted the idea, but he didn't invented it - visual thinking was probably used even in Antiquity, but for sure - in the Middle Ages.
Why do I use mind maps
Personally I find mind maps very useful to track my progress on my current task/story. In my team we're using Scrum, so in every sprint each team member has opportunity to work on many small user stories.
However, as an unofficial team leader, I have plenty of other tasks to work on during my day, a lot of interruptions, questions, meetings and alerts. Because of that, it's very easy for me to get distracted and forget where I was in my story before the interruption, and what else I need to do.
I used to spend like 10-20 minutes just to "come back" to a state where I was coding in speed once again, and sometimes I got that feeling that I needed to remember about something, or I realised that I needed to do something, but then I was interrupted and now I cannot remmeber what it was!
Later on I started noting what needs to be done on a sheet of paper - as a list of sub-tasks to my user story. It worked quite nicely for some time, but I felt that:
- there is way more tasks I need to do, but I'm noting only the most important ones, so I may miss something (either by not coding it at all, or just by not connecting the facts that something may be needed),
- it's not easy for me to estimate my progress because each task on a list has steps of it's own and I'm in the middle of these steps,
- i can't present this list to my client to discuss it or show my progress,
- I used to cross out things that I thought are completed but sometimes I needed to write them back because I realized that more work needs to be done,
- sometimes going in this list from top to bottom was not the best order so I was working on something in the middle, but when I was interrupted for 2 hours, I didn't remember which point was it so I needed to look into code to find out.
Then I gave a try to mind maps and now I'm using them for my user stories all the time. They resolved or partially resolved problems I listed above.
When it makes sense to use mind maps
I would say that it always makes sense (you may got amazed how oftenly programmers introduce new bugs in the smallest of stories they have in backlog) - but if you're working in a startup or small company, and even writing automated tests seems to be "too high cost" - it may be useful to use this technique only for stories approaching to 1 day or more of uninterrupted work in size. If you're a team leader and got interrupred all the time, it may be useful for you do it even for smaller stories.
My process of mind maping a user story
Keep in mind - this is not order of execution of user story. It's order of deconstructing story into smaller parts.
1. Add center of the mind map and carefully read user story
The first thing I do, is adding number of my story (we're using JIRA) in the center of the mind map. I also write below the title of the ticket.
Next, I'm reading through JIRA ticket in order to understand it. In my team, description of user stories in JIRA conssits of three parts:
- Business goal - why we do the story in the first place,
- Description of task - what needs to be done,
- Acceptance criteria - bullet points describing desired end-result in short sentences.
These will be important later on.
2. Find out if you need to add totally new parts of the code.
In more complicated stories it may not be immediately obvious, but most of the times you will know right away if you need to add new:
These are quite easy tasks - and easy to encapsulate. I like to start from these and commit them as first small peace of completed work.
3. Add tests to your newly added parts of the code.
I'm trying to follow TDD whenever I can. Every new feature is covered by at least one unit test - and when all my unit tests are passing, I know I can integrate parts together. That's why on mind map I create features under "tests" blocks - because when all my newly added tests are passing - feature is completed.
To complete this part, you'll need to follow JIRA description once more - look on acceptance criteria.
4. Think which parts of existing code you need to adjust.
This is most tricky step - you need to compare desired end-result with current code base and find parts that needs to be adjusted. It's not easy to find them, but when you do - process is similar to step #2 - add them to your map.
5. Add tests to modified parts of the code.
Same as in step #3 - but this time for parts that already exists. Biggest issue here - your modification may break existing tests, or there may be no tests at all. In both cases - adding tests to existing code is sometimes harder and more time consuming than adding them to fresh peace of code. However, if you have nice test suite already, then adding new cases shouldn't be a problem.
6. Add manual checks and run automated ones
It's extreemly unprofessional and inmature to push your code further without checking if it works or not. It may sound obvious but I know people who say it's tempting since QA needs to check this feature anyway... yeah, right. It's BS and just laziness - always check if your code works. Write few cases for manual checks and make sure new features work as expected.
If you're using code review and code required some adjustments, you should do these checks once again, before it get's merged.
7. Add documentation chores and questions
Sometimes you won't be able to know right away everything you need. I like writing questions to certain parts on this diagram to remind me that I asked it to someone - and I should check answer. Also, it's important to update documentation of your project and README if necessary.
How to use drawn diagram
At this stage, a lot of problems that this user story introduces will be easier for you to grasp. You don't know the small details yet - but probably you will know how much work needs to be done and where you'd like to start.
Now I'm usually colorring a branch that I will focus on (in blue) - if someone will interrupt me, I will know where I was and what needs to be done. Then I'm starting working at these parts, and when I think I completed one stage, I'm going back to diagram to colour (in green) to indicate it's done. Sometimes after few lines of code you will understand story deeper and you will know that it's necessary to do more work then you thought - it's important to go back to diagram and draw it right away - to make this thought perssistent. Sometimes you will do the opposite - you may realize that thing you wanted to add is not necessary - it's good to remove this right away from diagram, or apply strikethrough to it.
I feel like using this technic allows me to forsee more things and give me smaller chance that QA will find some issue in my solution. However, sometimes it makes me drift away from a story goal and add more stuff than necessary - It's important to check story estimations, importance of your branches, and if you are running out of time - it may be better to color blocks of a diagram that could be moved to other story, for later time. I'm usually using red/orange colour.
This is how diagram my look like after I started working on story:
Tools you can use
There are many different tools you can use, to draw mind maps. I was using three:
- Just pen and paper - fastest, but it gets really messy when you need to modify it. And it's difficult to share with remote team, photos don't look good enough.
- Mindmeister - probably nicest looking tool I've seen online, but I didn't like the pricing model and dropped it after trial. However, I think it's really nice, especially the feature to embed iframe of your mind map. Really useful - you can inject it in documentation, for example.
- Mindmup - looks pretty old, but it's cheap and does the good job. Also you'll get ability to store maps on google drive and share them through it, which is really great - especially, that my company uses g-suite. That's the tool I'm using right now.
Mind maps are powerful tool that may help you find your way in current world of constant interruptions and chaotic notifications. I'm sure it helps me a lot! Hopwefuly with tools shown above and technique presented earlier, you will be able to use it on daily basis.
Let me know what do you think about this method and don't hesitate to share your own tricks in the comments!