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