Story Maps - A Testing Tool After All

The following was recently published as a sidebar in Lisa Crispin and Janet Gregory's new book More Agile Testing. The book is full of great advice from the authors as well as other contributors. I encourage you to take a look.

So you’re an agile tester and wonder why you should care about story maps. You may already be convinced that modelling your backlog in two dimensions is useful for helping the whole team visualize the big picture. However, story maps are also a valuable testing tool, providing two additional testing avenues. In the first case, the map itself offers the ability to test the validity of a solution. In the second, a story map improves a team’s ability to identify story slices and then test them.

User Story Mapping Series

* How to Create a User Story Map
* How to Prioritize a User Story Map
* Tips for Facilitating a User Story Mapping Session
* Don't Etch your User Story Map in Stone
* User Story Mapping Tool Review – SmartViewApp
* Story Maps - A Testing Tool After All

Testing What to Build

User story maps are a representation: they provide a means to visualize a system that might be built and are useful for testing the validity of that system before investing significant time and money. A story shared at a recent Agile Winnipeg event demonstrated this principle well. The company involved used story mapping to test an idea before building any software. The team had a project idea that they thought would serve their client well. After quickly building a story map around that idea, they presented the map to their client at the next customer conference. Although it soon became clear that the idea missed the mark, the customer was able to collaborate with the team on the spot, to adjust the map until it represented what they actually wanted built. The map itself was the tool that allowed for the idea to be tested (and then adjusted) and moved the project forward.

Testing Application Slices

As Crispin and Gregory demonstrated in their first book Agile Testing, identifying thin slices and small chunks is important for testing agile projects. Story maps help identify those slices but, perhaps more importantly, they help us understand how those thinly sliced stories might fit together to form a thin slice of the whole application. When undertaking an agile project, testers are required to make a vital shift in thinking; only test small pieces at a time. Despite this fundamental change, it is also important to ensure that the first few pieces fit together, enabling end to end testing as early as possible. The story map helps to identify and prioritize that first application slice. It may be based on a user scenario or just a string of stories that represent the smallest stories that allow left to right movement on the map.

Visualizing testing slices in your map

As that the team identifies that first slice, utilizing excellent testing skills is crucial. By looking at the map, you can identify areas that will be difficult to test, areas where the test variations are still relatively unknown, or areas that represent higher risk. This activity can help identify stories that should be included in the first application slice.

When coding and testing begins, personas and user scenarios that were created can be revisited, helping to flesh out the map and application slices. Testing with a persona in mind helps ensure that the targeted customer will be satisfied with the solution. It may not be possible or wise to test if the application works well for everyone but testing should evaluate whether the targeted personas can use the application easily, and that the new functionality fits into, or adds to their current processes without getting in the way.

Story Maps—A Testing Tool After All

At first glance, the story map doesn’t appear to be an obvious asset for testing, but upon closer inspection, it proves its value in any testing toolbox. The map itself is a reliable way to test that the right system is being built before any code is written. The map also provides a visual aid for testing in horizontal application slices, allowing for early confirmation that a project is on the right track.

Subscribe to Winnipeg Agilist by Email

User Story Mapping Tool Review – SmartViewApp

User Story Mapping Series

* How to Create a User Story Map
* How to Prioritize a User Story Map
* Tips for Facilitating a User Story Mapping Session
* Don't Etch your User Story Map in Stone
* User Story Mapping Tool Review - SmartViewApp
* Story Maps - A Testing Tool After All

I’ve tried to give consistent advice when people ask me what tools I would recommend for agile teams. In my opinion, the best tools to start with are sharpies, post-its, and retrospectives. With these basic tools, you can create story maps, track your improvements and progress with a kanban board, and build just about any report you need in Excel. For beginner teams and co-located teams, this is often more than enough. However, as you grow, start working with remote team members, or just want more advanced and automated reporting, you might start exploring the tool market.

As a big fan of user story maps, I’ve been on the lookout for ALM tools that include them and occasionally talk to tool vendors to see what their long term plans are regarding story maps. As you can read in the comments in the link above, the options are slowly increasing. In this post I’d like to highlight a new entry into the ALM market that combines both story mapping and kanban in a simple yet effective package.

In order to give this application a good test of its capabilities, I decided to try and create a story map that mimicked the example I created here.  I was able to easily create the map, prioritize the features into releases, set the status of the features using the kanban board, and generate a few metrics. Here are a few screenshots: 

This is a picture of the user story map. At the top of the page you can see the four user activities displayed as envelopes. In this view, the Manage Calendar activity is open. Similar to my original story map that I created in PowerPoint (yes, really…), the map allows you to display the releases (I’ve used colour coding), and the status of each feature (green check mark = done, etc.). Dragging features up or down or between user tasks is simple.

The kanban board mimics functionality you can find in most tools. It allows you to set your own columns, set wip limits, etc, and it gives you some metrics and reports like Cumulative Flow Diagrams. One nice bonus of this tool is that it is already available as an iPad app so that you can carry your kanban board and map with you anywhere.

IPad Version

Web Version

I was able to set this project up as a public project, so if you want to take a look for yourself, click here.  Note – this application is currently only available in ‘modern’ browsers, so you may need to download Chrome or FireFox.

Not only does this tool support two of my favourite agile practices, it is also simple and easy to use. That means you can continue to focus on the important things - “individuals and interactions over processes and tools”. Since the tool is currently in Beta, it also means that it is ready for your input. In fact, some of the changes I’ve suggested have already made it into the product. So, if you think your team is ready to add an ALM tool, check it out here.

P.S. Need another reason to try this out? It calls us “people”, not “resources”. Thanks SmartView!

Don't Etch your User Story Map in Stone

I was having a chat with Adam Yuret last week about user story maps. A concern that he expressed and others have voiced is that by putting your ideas into a user story map it might discourage you from changing the map as you start delivering the stories and learn more information. He's right - it might and it probably does. Kent Beck recently expressed a similar concern about product roadmaps on twitter.

User Story Mapping Series

* How to Create a User Story Map
* How to Prioritize a User Story Map
* Tips for Facilitating a User Story Mapping Session
* Don't Etch your User Story Map in Stone
* User Story Mapping Tool Review – SmartViewApp
* Story Maps - A Testing Tool After All

So, here is your reminder that your map isn't just a list of features, but is really a list of unvalidated ideas. Whether you are working on a startup or an enterprise project, you begin with a list of questions or assumptions. Here are some examples:

• Will anyone use it?
• Will anyone pay?
• Does anyone care?
• How will we make $?
• Can we build it?
• Do we understand the problem?
• Will this solve the problem?
• Will it perform adequately?
• Will it integrate with other applications successfully?
• Can we build this with the budget & schedule we have?
• What is the best architecture for this project?

When you build and prioritize your map, you should be doing so with these questions in mind. As you resolve each of those questions, your map should change. It is one of the great reasons to put your map on the wall using post-it notes instead of putting the map into a tool - post-it notes are easy (and fun) to move. (Aside: Yes, there are sometimes excellent reasons to put things into a tool.)

Two quick stories to illustrate:

At a recent Agile Winnipeg event a local company (UnionWare) told a story of how they are using story maps. They had an idea for a project and quickly built a story map around that idea. At their customer conference they reviewed their ideas and realized they had missed the mark. They quickly (and easily) adjusted their map to confirm with their customers the new priorities and direction before they had even started building anything. The map itself was enough to help them walk through some of the questions above. As they told this story, their CEO recounted how he thought to himself: "This visualization stuff, it's going to be good."

For a project that I worked on this year we built a large map outlining all of the stories. We spent time going through the map with our customers slicing, scoping, prioritizing, identifying risks and assumptions, etc. We were pretty proud of the result and eagerly started delivering. As we started working on the first small release, we quickly realized that the answer to one of the main questions "Can we build this with the budget & schedule we have?" was "no". At this point, we had conversations with our users and sliced, scoped, and prioritized even more so that we could deliver something that would still meet the goals of our upcoming deadline.

In summary, "You cannot plan the future. Only presumptuous fools plan. The wise man steers." - Terry Pratchet. Don't etch your user story map in stone - build it with paper and expect to change it as you learn.

Subscribe to Winnipeg Agilist by Email

How to Prioritize a User Story Map

At the Agile 2012 conference, Serena Software surveyed attendees about their biggest agile challenge. Here was the top answer:

User Story Mapping Series

* How to Create a User Story Map
* How to Prioritize a User Story Map
* Tips for Facilitating a User Story Mapping Session
* Don't Etch your User Story Map in Stone
* User Story Mapping Tool Review – SmartViewApp
* Story Maps - A Testing Tool After All

I don't know how accurate their results are but prioritizing customer demand was certainly a challenge for me on my first "agile" project.  We created a backlog with some pretty large user stories including "Search for items", "Maintain item attributes", "Set costs for items and groups", "Calculate prices", "Run pricing engine", etc. We then proceeded to tackle each story in order (that's what you do right?). After our first five week iteration (!!) we had created the most beautiful search screens you could possibly imagine. Our users could search by any and all combination of attributes and display the results in multiple different ways - there was even a brilliantly developed screen splitter so you could see all the extra details of one horizontal row in a vertical list at the right of the search results. We were so good that we finished our iteration commitment early and started to add in some of the nice-to-have search functionality. In truth, we were quite thrilled with our results. It was only in later iterations that the pit in our stomachs started to grow. While "Search for items" fit nicely into an iteration, "Maintain item attributes" had a tougher time and by the end we had lost all hope for "Run pricing engine". We had incredible search functionality (low priority) and sub par costing and pricing (high priority). Oops.

Thin slicing to the rescue!

It is no wonder that when Jeff Patton showed me how to create a user story map and use it to create thin application slices to prioritize agile projects effectively that I was hooked. It should also come as no surprise to you that in subsequent projects when "search" comes up as a feature request I am the first one to slice that story ruthlessly! "Search for items" is immediately sliced thinly to "Search by item number" and put in the first release. The rest of the search functionality is sliced into similarly sized user stories ("Search by description", "Search by customer item number", "Search by vendor", etc) and initially moved to the bottom of the story map.

Then we continue to slice each column in our user story map so that we can build a thin horizontal slice of our app in a short period of time (days or weeks). "Enter member, spouse, and dependent information" is sliced into "Enter member name" (first release), followed by "Enter member address", "Enter spouse information" and "Enter dependent information" in later releases of the application.

Prioritizing by risk and assumptions

Once you get the hang of ruthlessly slicing your stories and prioritizing them effectively in your map, you may notice a lot of 'easy' stories initially rise to the top of your priority list. In the case of "Search for items" this is a good thing. However, it can be dangerous to do all the easy stories first. When we've drafted our map and are ready to start prioritizing I like to ask - "Where are the risky stories? Where are our biggest assumptions?".

In the project example above, "Run Pricing Engine" was our riskiest story. It had some really aggressive performance requirements and if we couldn't meet those requirements then there was no point in building the application. In this case, choosing the 'easiest' slice of that feature would be a mistake - we should look for a slice that helps us validate our assumption that we can meet the performance requirements. Additionally, subsequent releases should continue to focus on that assumption before we work on stories like "Search by vendor".

Applying Cynefin to prioritization

This week I read an excellent article by Liz Keogh called "Cynefin for Developers". The article is well written and can help us understand how to apply Cynefin to project prioritization. One of the domains in the Cynefin model is "Complex" which Liz describes as:

"When you start writing tests, or having discussions, and the requirements begin changing underneath you because of what you discover as a result, that’s complex. You can look back at what you end up with and understand that it’s much better, but you can’t come up with it to start with, nor can you define what “better” will look like and try to reach it. It emerges as you work."

"... This is the land of high-feedback, risk and innovation: generally stuff you’ve never done before, anything that the business are unsure about, new technologies, etc."

As you are prioritizing your map, pay special attention to any stories that may fit into the Complex domain. Since these stories may change the direction of your project, I'd recommend that you tackle them earlier rather than later.

Re-prioritize often

Remember that priorities can and should change throughout your project as you learn more information. On a recent project we had a few stories that were identified as 'mandatory' but the team agreed to prioritize them towards the end of the project. Near the mid point of the project we brought in some of our external customers for a small focus group. We did a quick demo of our progress to date and also asked them to help us prioritize the remaining stories. We quickly learned that some of the previously 'mandatory' stories were no longer important and removed them from our backlog. Without that feedback and the willingness to change priorities at any point of the project we would have contributed to the famous Standish Report phrase: "64% of features are rarely or never used".

On a related note, if re-prioritization is going to happen frequently, then there isn't much point in prioritizing your whole map initially. A good rule of thumb is to prioritize the next one or two releases only. Even though prioritizing a story map can be a simple and fast exercise, it may be wasteful to slice and prioritize everything at the beginning.

In Summary

My secret recipe for prioritizing agile projects is simply this: Roll out your user story map; add some thinly sliced stories; stir in some prioritization by risk, assumption, and complexity; rinse and repeat.

Subscribe to Winnipeg Agilist by Email

Tips for Facilitating a User Story Mapping Session

User Story Mapping Series

* How to Create a User Story Map
* How to Prioritize a User Story Map
* Tips for Facilitating a User Story Mapping Session
* Don't Etch your User Story Map in Stone
* User Story Mapping Tool Review – SmartViewApp
* Story Maps - A Testing Tool After All

In an earlier post I described how to create a user story map. Here are a few additional tips that you might find helpful.

Tip #1. Silent Brainstorming isn't mandatory. 
While using silent brainstorming is great for creating a map, you don't always need to use it. Sometimes you may find yourself in a situation where a full set of requirements has been written or the app is a re-write of an existing and well known application. In those cases I often skip the silent brainstorming and create the map from the existing documentation. Of course, I still do this with the team.

Tip #2. For your first map, reference the email map.
When you are creating your first map you may find that some people have difficulty finding the right level of detail for the second row in the map ("things people do" - the user tasks). In order to reduce the confusion walk them through the first two rows of the email map first. You can simply write the basic map on a few post-its as an example:

Finally, as they are writing their 'things people do', walk around and take a look at what they are writing. Encourage them when they are writing the correct level of detail ("Compose Email") and ask questions when they are getting into too much detail ("Set an email to High Priority").

Tip #3. Tear horizontally, not vertically
There are two ways to tear a post-it note off of the pad. If you tear it off horizontally (left to right or right to left) the post-it note will lie flat when it is stuck onto the wall. If you tear it off vertically (bottom to top) then it will have a curl.

Tip #4. Big Post-its
Quite often it isn't possible to create your map in the team room. If this is true for you then create your map on the large 3M Easel pads so that it can be transferred back to the team room.

Tip #5. Use name brand post-its
Post-its made by 3M seem to stick longer than other brands.

Subscribe to Winnipeg Agilist by Email

How to create a User Story Map

User Story Mapping Series

* How to Create a User Story Map
* How to Prioritize a User Story Map
* Tips for Facilitating a User Story Mapping Session
* Don't Etch your User Story Map in Stone
* User Story Mapping Tool Review – SmartViewApp
* Story Maps - A Testing Tool After All

User story mapping is becoming a popular technique through the efforts of Jeff Patton and others that allows you to add a second dimension to your backlog. Here are a few reasons you should consider using this technique:

• It allows you to see the big picture in your backlog.
• It gives you a better tool for making decisions about grooming and prioritizing your backlog.
• It promotes silent brainstorming and a collaborative approach to generating your user stories.
• It encourages an iterative development approach where your early deliveries validate your architecture and solution.
• It is a great visual alternative to traditional project plans.
• It is a useful model for discussing and managing scope.
• Allows you to visualize dimensional planning and real options for your project/product.

Want to hear more? I talked about the value and use of User Story Mapping with Richard and Carl on show #750 of DotNetRocks.

To create your own user story map:

1. Form a group of 3-5 people who understand the purpose of the product. 3-5 seems to be the magic number. Any less and you might miss some ideas. If you add more people, it slows the process down and there are diminishing returns on the quality of ideas generated.

2. Start by gathering the major user tasks of the project/application in silence - the “things people do”. Each person takes the same coloured post-it and silently writes down one user task per post-it. Once everyone has finished writing their post-its, have each person read their post-its aloud and place them on the table in front of the group. If anyone has duplicates they should be removed at this point.

• Depending on the size of your application it can take 3-10 minutes to get all the major tasks, but you can watch the body language to see when they are done. You will see that the group goes from huddled in at the beginning to standing/leaning back at the end.
• Likely each post-it starts with a verb. (eg. Compose E-mail, Create Contact, Add User, etc)
• These are the high level user stories called “User Tasks” which forms the "walking skeleton" of the map.
• When they are done, point out to your team that in a few minutes they gathered most of the high level scope and that if they missed a user task or two, someone else probably didn’t. This might be their first ‘aha’ moment for silent brainstorming.

3. Next ask the team to group the post-its in silence. Simply ask them to move things that are similar to each other closer to each other and things that are dissimilar to each other should be moved farther apart.

• Use silent grouping simply because it is faster than grouping them out loud.
• If duplicates are found, remove them.
• Groups will form naturally and fairly easily.
• Once again, body language will help you see when they are done - usually 2-5 minutes.

4. Using another colour of post-it, name each group and put the post-it on top of the group. This step can be done out loud.

5. Arrange the groups left to right in the order a user would typically complete the tasks.

• If the group can't decide on an order between two or more tasks, it probably doesn't matter.
• The groups are called “User Activities” which form the backbone of the map.
• You should now have the first 2 rows of the user story map - something similar to this:

A1       A2    A3          (user activities = backbone)

T1 T2 T3 T4 T5 T6 T7 T8 T9 (user tasks = skeleton & timeline)

6. Now walk the skeleton to make sure you haven't missed any major user tasks or activities. You can walk through user scenarios, or even bring in users and ask them to walk through their job functions to make sure everything is accounted for.

7. With a finished framework for the map, you can add more detailed user stories below each user task before breaking your map into releases. I like to use the same silent brainstorming technique to generate the initial set of stories for each user task and augment it with other techniques such as user scenarios and personas. Once you have a good set of stories, then you can put your release lines in the map and ask your users to prioritize top to bottom.

• I like to put the first release line on the map pretty high on the map so that it only allows for 2-3 user stories per user task in the first release. This has been an effective way to encourage prioritization and scoping.
• Because all the stories end up on small post-its, you can forgo the traditional 'as a' format and just put the story title on the post-its. This will allow you to read the map a little easier.

8. Finally, I like to take all the user stories in the first release and do some serious user story slicing to make sure we have sliced the first release as thin as possible. As a guideline, you should strive to be able to create the whole app (at least one small user story slice for each user task) in the first iteration or two.

"An example would be handy right about now" (Brian Marick)

(click to enlarge)

Here is an example user story map for creating the next email client competitor:

• The second row contains the "things people do" in an email client such as Compose Email, Send Email, and Create Appointment. 
• The first row contains the groupings for those things people do. 
• The first yellow row is the smallest user story slice for each user task. For Compose Email, that means a basic form with To, Subject, and Body text fields plus Send and Cancel buttons. Functionality for RTF support, HTML support, adding attachments, getting email addresses from your contact list etc, are not included in this user story but are included as user stories lower in the map. 
• The small blue and orange post-its on the larger yellow post-its indicate the status of that user story. The blue ones say "done" and the orange ones say "wip" so that you can see your project status flow down the map.

If we now build the first row left to right before working on any stories in the rest of the map we can deliver all of the basic functionality quickly. This enables us to validate our messaging architecture (i.e. Send an email and then make sure you can Read it). It also allows us to test all the basic functionality in the application end to end so that we can make sure it all works together while getting feedback on whether or not it will solve the business problem. If we were building the very first e-mail client, we could release to the public at this time. Notice also that we did not have a user story for "Delete Contact" in the first release - we don't need to deliver functionality for each "User Task" in each release.

Finally, some definitions:

(click to enlarge)

• The post-its you create in Step 2 are the User Tasks (blue post-its in the diagram). 
• The groups and group names in steps 3 and 4 are the User Activities (orange post-its). Jeff calls these top two rows the backbone and walking skeleton of your application. 
• The user stories (yellow post-its) are organized under each User Task in order of highest to lowest priority for that User Task. 
• The chronological order of how users will typically use the application goes left to right (Time).

Subscribe to Winnipeg Agilist by Email