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

Golden Nuggets from the Innovation Games Summit

My friend Chad Holdorf describes golden nuggets as those practical things you learned from a conference that you can use on Monday at work. After attending the Innovation Games Summit this week in Santa Clara here are six golden nuggets I'd like to share with you:

1. Many of the attendees at my Silence of Agile talk were trained and experienced facilitators and during our discussions offered two specific tips that I plan on trying at one of our team's next retrospectives.

• The first tip was to change the voting so that people vote not only for their top 3 ideas but also their bottom 3. When tallying the results use the net votes (top minus bottom) as your top items to work on for that period. 
• The second tip involves changing the silent writing portion of the retrospective. Instead of writing each individual idea on one post-it, ask each team member to write all their ideas on one paper in a list format. Once everyone has written their list, pass it to the person on your left. Each person then reads their neighbour's list and adds to it. Keep passing the lists to the left until everyone has read and contributed to all the lists. Finally, put the individual items on your board and prioritize them as usual.

2. Innovation Games help you have better conversations and make better decisions. I had already experienced this myself when using these games for retrospectives. However it became even more explicit as we facilitated and observed the San Jose 2013 Budget Games. We had a diverse group of community members at our table who had honest conversations and made tough decisions about topics that are important for San Jose. I can imagine that a great facilitator could also have achieved the same results, but the game did this without much need for facilitation. I'll be looking for more places to try out these games.

3. As a facilitator, it is important to trust the Innovation Game and let the group create their own process and flow within the context of the game. Gerry Kirk was my facilitation partner for the Budget Games and I watched (sometimes in trepidation) as he deftly used good questions to nudge the group along rather than directing the flow. Their process was sometimes a little scary as they tried to work within the game to come to decisions. However, in the end it was their process and their results. The game did its job to provide structure and Gerry's gentle questioning prodded them to a good result much more effectively than a directive approach would have.

4. A new podcast source! Look for Jack Dorsey and others on Standford University's Entrepreneurship Corner.

5. A new book that was highly recommended by Mr. Holdorf: The Radical Leap Re-Energized by Steve Farber.

6. Two 'S's. These aren't agile tips, but useful nonetheless

• Have sinus trouble when flying? A client of mine recommended Sinusalia by Boiron. Take two pills before you get on the plane and then every two hours during your flight - they are magical.
• Need music for your training sessions, workout sessions, relaxing at home, etc? Try the Songza app. It has lots of curated music based on themes and also comes with a pretty neat UX experience that suggests musical themes based on the time of day.

Subscribe to Winnipeg Agilist by Email

Kanban At Home

As Jen mentioned in the previous post, kanban has crept into our home. Here is a quick post to tell you how we build our board, how we use it, and the results.

While some families create a permanent board, we've found that temporary boards serve us well. If you stop by some Saturday morning you'll probably find us in the act of putting post-its on the mirror in our front entrance. It is true that occasionally our board is created in the kitchen or even sometimes the hallway, but the front entrance is currently our favourite location. We have three columns across the top - "Ready", "Doing / Work in Progress", and "Done". You can probably simplify the middle column name to "Doing" or "WIP" but our kids have decreed that we should use both terms.

We populate the "Ready" column with everything we'd like to accomplish that weekend. We're careful to make sure the tasks are clear and not too big. For example, instead of "Clean the House", we create post-its for "Clean the Kitchen", "Vacuum the living room", etc. Our board will have a mix of post-its that are specific to one person ("C practice piano", "A practice drums", "M clean room", "Daddy pay master card") and cards with no names that anyone can grab ("Shovel the snow", "Organize the front closet"). More recently we've also started to add post-its for doing fun things together ("LEGO!", "Family Movie").

Once the board is populated the process is quite simple. Everyone selects a post-it, moves it to the "Doing / Work in Progress" column and goes to work. Once they are done that task, they move it to "Done" and select another. By the end of the weekend, the post-its have made a large shift towards "Done" as seen above.

For our family this board works because it is simple, transparent, and requires little to no 'management' (i.e. nagging). Once the board is populated each person has a clear view of their expectations and can make their own decisions about when to do chores and when to play. On most Saturdays our kids (ages 7, 9, 11) do their chores earlier in the day so that they can spend the rest of the day relaxing without worrying that more chores will be added to their list.

A board we created this holiday season is a particularly great example of the peace that a board can bring in our household. We had just returned from a road trip through Nebraska (Car Henge!), South Dakota (Rushmore and Jewel Cave), Wyoming and North Dakota. The level of grumpiness as we unloaded all of our luggage from the van into the house was historic - we were all tired and the mood was tense. As we stood around the pile of luggage now clogging our front entrance we reluctantly decided to create our board. Among the post-its for "Laundry" and "Unpack Luggage" were reward post-its like "Sleep" and "Spend my $10 Claire's gift card". After agreeing to take care of all the chores before starting any of the reward post-its, we moved our post-its to the "Done" column in record time with zero nagging. In parallel, the spirit of our household moved from grumpy to peaceful with the same efficiency.

Well, it's Saturday morning. I'm being beckoned...

Subscribe to Winnipeg Agilist by Email

Living With an Agilist

(Editor's note: The following is a guest post by Jen Rogalsky)

A couple of years ago Steve came home from work and announced, “Podcasts have changed my life.” My natural response was: “What? Podcasts? Not me, not our children, but podcasts?” He persisted with his original assertion. “Yes, podcasts. They’ve changed my life.”

This was my first introduction to the fact that Steve, through podcasts, had begun to learn about something called agile, and his declaration of devotion seemed to leave me with a clear choice: learn a little about this new interest or be left behind by this obviously life changing discovery. We were not immediately friends, agile and I, and yet along with the post-it notes and sharpies that have overtaken my house, some agile practices and principles have slowly become part of my life. I don’t pretend to be an expert in their application in a business context, but as I stumble through trying to explain to someone who asks me “What does your husband do?” I often come out with some kind of statement explaining that agile is applicable in some way to almost everything and everyone. Quite a lofty statement, and obviously somewhat hyperbolic, yet my personal adoption of some agile ideas is a testament to a sliver of truth.

So here are just a couple of examples of how agile practices have seeped through the cracks.

I like to picture myself as quite a broad thinker, capable of pondering and producing on multiple platforms simultaneously, unhindered by the shackles of linear constraints. Okay, so, that may look somewhat unsystematic to the outside viewer. And, okay, that may occasionally result in many simultaneously started, yet unfinished (albeit very creative and useful) projects. As I’ve learned more about agile, however, I’ve become more convinced, although reluctantly, about the value of shorter loops. Just as risky as it may be in a professional setting to invest money and energy in a long arc with feedback and product only at its end, shorter loops have proven their value for me, as well. I churn less often, (although sometimes churn on purpose just to be rebellious, now that I actually understand it for what it is), actively seek frequent feedback from those involved or implicated by my task rather than wait until the end to ‘test’, and force myself to be more systematic at finishing one task before beginning another, fueled by the motivating sense of reward that can provide.

My evolving relationship with kanban has been no less reluctant, and yet equally as relentless in slowly changing my practices. Steve introduced kanban into our household quietly, first making his own boards for house and renovation projects, then producing boards on the kitchen cupboards for when he was in charge of doing chores with the kids. I didn’t object as long as I wasn’t required to participate. “Let’s just do it already, instead of sitting around writing stuff out first!” was my usual response when invited to join the process. Steve’s gentle suggestion that he wasn’t born with the ability to help accomplish our common goals by subconsciously divining the detailed task list in my head wasn’t enough to convince me of kanban’s value. Once again, however, like the persistent drip of water on rock, my resistance has been futile. It began with observing the relative lack of nagging involved when he did chores with the kids. What a wonder to behold when they would eagerly race back to the board to move their sticky from “WIP” to “done.” Or to overhear them debating their preferences in referring to the middle column as “Work in Progress” vs “Doing.” Or to watch their ownership of the whole task process increase as they were given the opportunity to participate in the creation of the list and then freed to choose their own route through to getting all the stickies transferred over to “done.” And now, after a long, slippery slope, most of our Saturday mornings begin with the creation of a family kanban board on the mirror in the front hallway. We are careful to also include the fun and relaxing activities in the “ready” column, and we all share in the sense of satisfaction when, come Monday morning, the board is balanced quite differently toward “done.” kanban’s conquest to take over our house is almost complete, since I recently found a spare bulletin board that seems to be calling to me to be made into a personal kanban board. Oh, how the mighty have fallen.

Finally, Steve’s passion for all things agile has found its way to the very core of our most significant common project, by influencing the ways in which we parent our three girls. I often find myself thinking, “But isn’t this just common sense? Perhaps we are making these decisions because we’re so incredibly intuitive and such remarkable parents…” and yet I know that our thinking has been shaped by what we have learned about an agile approach to treating people in the workplace and applying these ideas to the little people we live with. A couple of deliberate parenting strategies have emerged. We deliberately try to assume our kids’ competence rather than treat them as inherently incompetent and in need of our micro-managing. We try to make expectations clear up front, but then encourage them to find their own route toward completion within the established boundaries. We’ve learned that feedback is most easily heard and adopted when offered immediately and within a conversation in which the kids are participants. And perhaps most significantly, we are trying to do whatever we can to help them develop what Linda Rising calls an “Agile mindset” rather than a “Fixed mindset.” I almost thought I heard angels singing when my daughter recently told me that she wished her friend would realize that “Life isn’t supposed to be easy! Challenges don’t mean you’re supposed to sit down and complain, just work harder and figure out how to get past them.”

All right, then, if agile ideas can eventually help my kid say something like that, even once, then I guess podcasts have changed my life too.

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