End to End Software Development Traceability with Mind Maps

It has been a while since I have updated my blog. Due to circumstances, I have not felt comfortable writing new posts. Talking to others and seeing this new cool Pinterest wall created by Rosie Sherry http://pinterest.com/rosiesherry/testing-mindmaps/  encouraged me to write again.  I thought, what the heck, I will do a blog post.

The following is just a massive brainstorm I’ve had in the past couple of days. The ideas are here, but may need massaged more to form concrete ideas. I simply needed to get the following out of my mind and onto paper.

Let me know what you think. What could be done to improve this? Do you like this? Do you hate this? I simply want to learn, so share your thoughts.

Can Mind Maps be used for End to End Traceability?

My team is still currently using mind maps to write and run our test cases. We love it. However, corporate requirements (which are fair) want all testers to use the same system. We will transition to this tool this summer. I will miss the maps, but I hope we can still use them to brainstorm our test case ideas. This new tool does allow for traceability from requirements, to test cases and finally to defects. It does not, unfortunately, allow creation of user stories or tasks. We will therefore continue to use our physical task board for sprint planning. There will be an adjustment needed, but we are willing to try.

The traceability offered in the new tool made me think how you could do this with using mind maps. How could we do this traceability with using a map, or several mind maps? The following is just a brainstorm wave that I have had recently, and this could work for you and is roughly based on how we develop products on my team.  I have setup some basic template maps for each phase.  Each template could be easily presented and used by the team through each phase of the project.

Writing a mind map works best working collaboratively as a team. Draw it on a white board, project it on a wall, and work together on it.

On a very high level we have the following phases in our software development:

•  Project Definition
•  Requirements/Backlog
• User story Definition
• Task Definition
• Software Development
•  Test Cases Creation and Running
• Defects and Resolution
• Product Release

You may have other phases, and that is fine. Below is my brainstorm and thoughts on how traceability could be done.

Project Definition

The following map shows at the very high level the project definition. By simply answering the 5 Ws (What, When, Why, Who, and How) you can come up with an easy to read map that shows the project at a very high level. 

(Sorry, for maps you will have to click to view larger)

On my current team, we are releasing software on an 8 to 10 week release cycle. I know in the Agile world we are meant to have working code complete at the end of each Sprint that is shippable. We do achieve this goal, but there are many other factors that come in to play, and that is why we release software on a cyclical basis. This allows for betas, marketing, linguistic teams, support training, and many others to be ready for the release. It is staggering the number of teams that are involved and need to be prepared for software releases.

Requirements Backlog

Using a mind map will allow you to group your requirements on your backlog into themes, and to give them priorities within each theme. As we develop software we should be working on the highest priority items first. The product owner can always add items to the backlog, create new themes, and change priority.

Requirements and priority should not be changed midway through a sprint. If we agreed to work on a set of items at the beginning of the sprint, that work should not be removed and replaced.

In the map below, it shows a backlog with three themes and a requirement that doesn’t belong to any theme. Each theme has several requirements. Each requirement has a definition, and some basic acceptance criteria that the product owner has to accept that requirement. Note: I will break down requirements down into individual user stories and tasks below.

If a Product Owner wishes to change a priority of a requirement or theme it can be easily done in a tool such as Xmind. You may ask then, what is a higher priority? “Theme 2 Requirement A” or “Theme 1 Requirement C”? Here is a way that you could determine this. Multiply the theme priority, with the requirement priority. If two requirements an equal value, the theme priority will state which the higher priority requirement is.

“Theme 2 Requirement A” priority is 2 (theme) x 2 (requirement) = 4

“Theme 1 Requirement C” priority is 1 (theme) x 4 (requirement) = 4.

However, since Theme 1 is a higher priority the priority of “Theme 1 Requirement C” is higher on the backlog and should be worked on first.

If a product owner feels that a requirement is at a high level, they can simply move it to the main topic and give it a priority. In this case Requirement X has a priority of 3. It should be worked on before either “Theme 2 Requirement A”, or “Theme 1 Requirement C”

Requirement Breakdown into User Stories

In general what we have do next is break down our requirements into user stories. We use Planning Poker to give each user story a relative size. Over time, we have figured out our velocity. At the beginning of a Sprint we commit to the user stories in priority until we have filled our velocity for the week.

For a user story we use this template:

As a <user name>

I would like to <action>

So that I can <result>

This can be easy mapped out as shown in a couple different ways below. There are probably more ways as well to map this out. If you have suggestions, please share.

Option 1

Option 2

I personally prefer the second map as you don’t have to repeat the <user>. Often the <user> is identical on several user stories. Both maps above show 3 user stories.

The other neat thing you can do in Xmind is change the map from a map structure, to a Spreadsheet structure. This is a neat way to see the two requirement maps above.

Option 1 as Spreadsheet

Option 2 as Spreadsheet

What is neat about the spreadsheet views, is that I feel you could simply cut and stick them to your task board.

In general, I think it would be best to break down requirements to user stories, for only those that you think you can accomplish in a given sprint, and maybe a few more. I would not take all the requirements and break them down at the beginning of the development phase. That is falling into a waterfall situation. Iteratively split requirements into user stories as the development progresses. When the team can take on more work in a sprint, take the highest priority requirement, split it into user stories and continue working.

User Story Breakdown to Tasks

A user story can be broken down into simple tasks for the team to do. I suggest colour coding the tasks. We use blue for development work, green for testing tasks, purple for UX, yellow for other. On an Agile team though, all members are responsible to ensure that the tasks get completed for the end of the Sprint.

Depending on the types of tasks, different work will be needed to be done. Developers will start coding, testers will start writing or scripting test cases, UX may need to create new graphics, etc.

Each task can have Acceptance Criteria that is specific to the task. Each task should also follow the Definition of Done that you have set for the team. For the end of the Sprint, each task should meet its Acceptance Criteria, plus the Definition of Done. A Sprint passes if all user stories are done.

Test Case Creation and Running

Each task has acceptance criteria. Could these not be test cases as well? Of course they can be. So, the test cases can be mapped out as shown previously in my Given, When, Then test case map legend. You would simply change Area to Task.

Writing test cases in the manner can be used for both manual and automated test cases. My team is currently marking the test cases on the map that are automated with a flag. The scripts are stored in our source control. I suggest also including on the map if a test case is automated the path and script name for easy traceability.

Test cases are marked up on the map as I previously discussed in an earlier post as passed, failed, blocked, etc.

If a test case has failed, mark the test case with an X. If you are using a bug tracking system, include the bug number. If you are not using a bug tracking system, you could add details of the issue directly on the map.

Defects and Resolution

Wow, another brainwave just hit. The bug actually should be a new task. Why use a bug tracking system? The goal should be to fix the bug before the end of sprint. You want shippable working code right?

Our team uses pink sticky notes for defects found in sprint. That bug task could then be added to the corresponding user story map, or branch off the test cases. Here are two thoughts on how you could do this.

In order for the user story to be complete for a sprint, all corresponding tasks would need to be done, including found defects.

Product Release

When you are ready to ship the product, a simply map could be used to ensure that all corresponding work outside the team has been completed. Truly, this work should be communicated earlier in the product and tracked on your task board. Maybe there could be a general product release user story that remains on the board, and you have tasks associated with it that move. For example, you need to have a marketing done; there could be a task for that. That would be out of scope for the sprint work, but in scope for the general product work. It is still something that needs to be completed before the project is released.

Conclusion

You are probably thinking, wow that is a lot of maps. Yes, it can turn into a lot of maps. What you could do is combine maps that are for a particular Sprint into one map. For example, you could do this.

So what do you think? Writing this post made me think of more brain waves which I plan to post. I look forward to hearing from you and learning more from one another.