Check out my main site

Hello, I am starting to blog again at my main site. https://www.macafee.ca. Come follow along with me there.

 

Thank you,

Nolan

Task Board is so yesterday. I give you the Task Bullseye

On my last blog post, I wrote out my ideas in a giant wave of thought. When I was writing that post I thought about the sprint map that I produced. A mind map has a central idea with topics floating from the middle. My thoughts drifted to the task board that we currently use. Is there a way that we can change it to look more like a map?


Using all of those maps I posted earlier are great for planning, but we need a way to visualize on a large scale what we do during a sprint. Today, we use a task board, either virtually or physically.

Let me introduce a new idea to you. The Task Bullseye ( Copyrighted by me :) )

The Task Bullseye takes the idea of a traditional task board, but shifts how it is designed. A task board is horizontal in most cases, with new tasks on left, and as the task progresses you move it to the right. I wanted to think of a way to make the task board less linear in design, so I came up with the circle idea.  (Also, idea might come from my years curling http://www.curling.ca/ as well).  Linear design can also appear to be very step oriented, or almost waterfall in appearance. Moving items always left to right could also fall into an idea of a timeline (good or bad).

The Task Bullseye could easily be put up on your scrum wall. Tasks can still be posted it notes as well. Each quadrant is one user story, so this assumes you can do up to four user stories in a given sprint. You can always slice up the circle more to allow more user stories.  If you have more phases of the sprint, such as Verification, another ring can be added.

Tasks are placed on the outside of the circle, and move inwards as progress completed. I like the symbolism of this, as all the tasks come together to form one releasable product at the end to the sprint. Each person on the team has to pull together what they are working on to one common goal, the Bullseye.

It visually is easy to see what tasks have not been pulled in and are not being worked on. For example, one user story has an Other Task that nobody is working on. The other user story has two Bug Tasks that need to pick up and completed before the end of the sprint. The colour coding of the Tasks is what we do. Use what colours work for you, and add more Task types if needed.

I searched the web, but found nobody that is using this type of concept. If would love to hear if someone else is using a task board such as this. Maybe this could catch on? Please comment below and let me know your thoughts.

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. 

Test Cases vs Test Ideas - Looking for assistance

Michael Bolton (http://www.developsense.com/) commented on my blog about moving towards the concept of Test Ideas. There is still much that I need to learn about using Ideas versus Cases.  I feel though, that this maybe how originally I had the team create the maps before moving to the Given, When, Then format. I wanted to testers to think freely about scenarios, instead of having a dedicated way to complete a “test case”. We simply did not have expected results on our maps at all. Was what we were doing Test Ideas?

Our applications and the system that we test allow for multiple ways to complete a certain task, therefore it is more of an “idea”. As I continue to do research and to grow I feel there will be more clarification in my mind of the true difference between “test cases” and “test ideas”. I’m on a journey here of learning and growing, which excites me.

Please comment and share thoughts about this. Do you have a good blogs, books or articles that I should read? How do you define a test idea? Do you use ideas?


Update: Blog link from Darren:
http://www.bettertesting.co.uk/content/?p=1438 

Our Current Test Process

There have been several comments on past posts about the importance of testing changes to the system. This is done by the team currently, and is capture in reports. I thought I would simply provide some additional information for clarification.

Our process dictates that when we test a build we do the following:

1. Run Acceptance Tests.
2. Test all changes. This is done through using our bug tracking system. When a build happens, the bug is moved to a Verify state. The test team self organizes and each tester decides what to test and verifies the issues. Each change the developer does to the code is matched to either a bug in the bug tracker, or to a User Story or Task on our sprint board. This ensures we test all the changes.
3. Run through all other test cases based on Coverage Level. In an earlier post I said Priority, but in truth it is Coverage Level. That level is determined at the beginning of the sprint on how much testing we require on a map. Remember, each functional area of the product has one map. We test the maps where the changes occurred to ensure that no other areas were broken by accident.
4. Results are updated on our Dashboard.
5. A summary is sent out to all those that are interested, which include a copy of our Dashboard, a list of new bugs found, and the list of verified changes.

I hope this post gives you some clarification on what we do when we receive a build to test. A future post should also write about our overall process during a given sprint.

General Update

The past few weeks I have received a lot of feedback on my blog through comments, email and Twitter @nmacafee. Each comment, good or bad, has been very helpful. I am a tester like many of you reading this blog, who wants to grow and explore new ideas and concepts.

Thank you to everyone that has commented, as I find this to be encouraging. I feel what I have been doing to change out we test within my organization is justified, but there is still plenty of fine-tuning to do. It was almost a year ago now that I first came across mind maps, and shared this idea with the team. There were several confused faces during that first meeting, but they were willing to give it a try. 

There has been a good cultural shift within the team. Developers are now comfortable with the mind maps and are even using them for their own use. Other test organizations with the company are coming to me for guidance on how they could implement mind maps for testing with their group.  There are still many skeptics out there who do not believe that this is a real “test management system”, but I continue to push forward turning those people into believers.

Change is a good thing. We need to move past the conventional methods that we use to test simply to shake things up.  Standard test case writing still has a place and work for many. Mind maps have though opened up the door to exploring new ideas within my team. We have saved time, which I’m excited to share, has led to all on my team learning some basic automation. When we get a test case automated it is now marked on the map. There is still much to do, but I have been very encouraged with the progress we are making.

Agile Ottawa Meetup - User Stories

On Thursday night this week (November 24, 2011) I attended the Agile Ottawa Meetup Group http://www.meetup.com/Ottawa-Scrum-Users-Group/. I have attended in the past before, but did not have a very good experience unfortunately. No details will be shared, but I put that aside and thought I would go again. This session I am happy to report was well organized and I learned more about Agile.

Below are my thoughts of the evening.

The meeting was focused on writing User Stories. The presenters, who were the “Product Owners”, gave us a mockup application that they wanted us to “develop”. The group self organized into four teams, of approximately four people. We then went through and wrote User Stories for the application. I have been writing User Stories for a while now, but what I did learn was A) another template that can be used B) mind set of those involved in writing can be very different.

Templates

This one I have been using:

As a <user>

I want to <task>

In order to <goal>

The new template I learned was:

In order to <goal>

As a <user>

I want to <task>

(Side note both fit well with Given, When, Then as well :) )

The new template simply rephrases the order to help it flow better. Depending on the scenario and phrasing required, I noticed that we used the different templates. Basically, we used what sounded right.

Testing vs product owner vs developer mindset can be very different when writing a user story. The teams that were mostly developers the User Stories were very technical, while tester’s User Stories were more general in nature. This reaffirmed to me in the Power of Three was necessary for User Story writing. The team should do this. Not just the developers, not just the testers and not just the product owners. ALL should sit together to write the User Stories as this remove confusion and helps start the iteration in a good direction.

Some good points that I picked up:

•        Focus on what is necessary in a user story
•        Do not over think the user story. Some went wildly off track from what the Product Owner wanted in the product. There is nothing wrong with thinking about how the application will work in the future, but over thinking can “cloud” our tasks for our current Sprint/Iteration.
•        User story should be testable externally. With this we started to write three Acceptance Tests per User Story. This really helped us focus on writing clearer and shorter User Stories, and will help the team define Done as well.
•        The presenter suggested that each User Story should take up no more than half of your Sprint/Iteration.
•        If there is research involved in a User Story or task, make sure you time box it, or it can grow out of control.

I was happy to hear that some use diagrams to write their user stories. They didn’t really see or know that what they were doing was simply a mind map. Mind maps are just very useful and can be used for many applications. Using maps for User Stories will be something that I will like to introduce to my team going forward.

Some good (or bad) quotes from the night:

“Telling a developer how exactly it should look will take away the freedom for developers to add value.” (I am not in agreement with this. As a team, you should be working together to a common goal. Product Owners should know what is being developed, and testers should have a clear under standing before development starts (ATDD) in order to prevent confusion and test case rewrite at the end.)

“Keep User Stores big when out there, but when they come closer (in time) break them down, like the game of Asteroid.” (Again, I wonder about this. If something is not yet ready to be worked on for a Sprint, is that simply not on your backlog or as a requirement? Should you have large User Stories that cover future development, or simply statements for what they are?)

“The more self sufficient your team is, the more effective it is.” (I agree with this)

“Break down barriers between teams.” (Definitely. I was surprised how many at the meetup were working at companies were the developers, testers, UI developers and product owners worked on separate teams and even in separate locations! That does not sound Agile to me. I’m just very happy to not be in that situation currently.)

Overall I enjoyed the session and learned more. The most valuable item I got out of going though was how happy I am with my current job and the team I work with. Our team is quite mature when it comes to Agile and we are doing really well. Sometimes I think the grass is greener on the other side, so it was nice to see how other companies work (some are cutting edge, and some are still learning). I just know that I have a good balance where I currently am, and freedom to continue growing.