User Story Mapping Workshop

I’m about a week or two behind on writing anything, but I’ve been out of town for the last two weekends for a bachelor party and wedding of a good friend of mine, and I just haven’t made time. Anyway, I wanted to write a follow up piece on my earlier post of How Not to Do User Story Mapping. I mentioned in that post that I was planning a workshop on User Story Mapping and Adaptive Planning, and I wanted to write a follow up on how my workshop went.

WARNING: This post turned out kind of long! Sorry I’m long winded…

This was the first workshop I’ve conducted since leaving recruiting and transitioning into an Agile Project Manager role, so I’m by no means an expert, but I’ll at least share my experience.

Before I get started, I want to summarize why I believe User Story Mapping is so beneficial, just in case you are unfamiliar with the concept or haven’t done them yourself. As I’ve mentioned in prior posts, I support two highly technical backend shared services teams, and the stories we were writing were very detailed and complex and it was nearly impossible to see how they tied into the big picture of what we were building. In fact, I found that we often were building something without truly understanding the big picture or how it tied into the problems we were trying to solve for our customers. Then the APM team decided to read User Story Mapping by Jeff Patton for our Q2 book read and it couldn’t have come at a better time!

The idea behind user story mapping is that you bring ALL project stakeholders together to talk about the Who, What, Why of a project and build out a map of what software needs to be built to solve a customer problem. It helps everyone to gain a shared understanding of what is being built, and with larger projects that are split among many different teams (which tends to happen at CareerBuilder), it gets us all on the same page with the complexity of the project and everyone better understands who is building what (i.e. better visibility into dependencies).

For my workshop, I used three resources to help me prepare:

1. User Story Mapping by Jeff Patton (I highly recommend this book)
2. Chapter 5 on Adaptive Planning from the PMI-ACP exam prep book
3. YouTube video by Ahmed Sidky on Agile Estimation (I also referenced his paper here).

I’m very fortunate in that I had full support from my Dev Manager, Product Owner, and Engineering Lead, as well as buy-in from the team to take a full afternoon to run this workshop. That’s four hours of sitting in a room and listening to me talk! Just kidding… we had plenty of activities mixed in, but I still appreciate them actively participating when I’m sure they would rather have been at their desk coding.

I structured the workshop to follow the sequence of events of planning out a new project: Build a User Story Map, High Level Affinity Estimation, break the map into potential releases, low level planning poker (using relative vs absolute sizing, and complexity [size] vs time), release and sprint planning, and finally daily stand up.

For the workshop, my Product Owner came up with a fictional app that would control a robot to do lots of activities around the home (think the Jetsons) such as cooking, cleaning, laundry, etc. Because we are a backend team, they didn’t want to do an e-commerce style site and wanted something that would involve a little more infrastructure setup. I also wanted it to be different enough from their day to day work so that they wouldn’t immediately try to translate everything back to their work, and instead would focus on learning what User Story Mapping is all about.

Unfortunately, I think I still struggled to help them understand the story flow that comes from building out the Backbone and Walking Skeleton. I ended up abandoning that and moving towards building a story map that would show how you get ready for work in the morning. Even though not all Story Maps have to flow left to right chronologically, you generally want to map out how a user would use your software in a left to right format, and getting ready in the morning helped to show that. The getting ready in the morning example also helped the discussion on breaking the map into releases as things like exercising in the morning may not be MVP. It helped to demonstrate how we might move stories up or down in the releases depending upon how important they are (note: that also depends on your customer though; exercising may be a mandatory story for MVP for some people, whereas for others it can go farther down. The key point being you need to understand your customer for planning out MVP and future releases).

For all of the estimation parts of the workshop, I pretty much copied everything Ahmed did in his YouTube video. This was probably the part of the workshop that resonated most with the team, so I’m glad I did. Practicing planning poker with the fictional “unpacking a Uhaul” example really helped us to surface a few things that we could learn about estimating together. For starters, during the workshop we made several assumptions and it was only after discussing why our estimates were so far apart that we realized we hadn’t asked the right question yet. It was cool to see the light bulb go off when the answer to that question helped us to then better estimate.

A lot of people complain about estimates and say that all of the time we spend estimating is wasteful, and that we could actually be building the software instead. I argue that they are missing the point of estimation; yes, the business needs estimates (which the developers personally could not care less about), but it is also a key tool to help the team ensure we truly have a shared understanding of what we are building. An initial estimate that varies is actually a great thing because it forces a conversation and develops shared understanding; if everyone throws out the same number that can actually be scary, because then you wonder if we all truly have the same understanding of the complexity in mind.

Overall the workshop went very well and the team learned a lot about User Story Mapping and Adaptive Planning. I gathered feedback from the workshop and the biggest takeaway was they would have liked an example that was closer to the work they do because we still had a big hang up on where Infrastructure fell into the User Story Mapping. I think they’ve been a little burned in the past because the business doesn’t understand the setup needed to actually start building end user functionality. I think that’s partially because we’ve never come together as a group (front end, back end, product, business, etc.) to discuss a project like this. I don’t want to say we haven’t had the buy-in of key stakeholders, because I don’t think we’ve asked stakeholders (or even other teams) to attend a session like this, but we definitely have not mapped out projects together like this in the past. If we bring all of the teams together and build a map together, we can still create a backbone and walking skeleton that is user functionality focused, and then use different color post-its to help everyone see the different layers of functionality that have to be built before that user benefit occurs. The business may not like all of the infrastructure that has to be set up initially, but at least they’ll have a better understanding of what we are doing and why we are doing it.

Only time will tell if we can get the buy-in across groups to do User Story Mapping sessions together. At a minimum, this team at least now understands how we can map out our next project so that we better understand the big picture, and how we can also provide better visibility into the full scope of the project. One thing I can already tell a noticeable difference in is our estimation sessions. I think this workshop helped them think differently, but it also helped me to better grasp some key concepts and metaphors to use to ensure we keep our estimates as relative complexity based versus absolute time based.

Do you do User Story Mapping sessions for projects? How did you get buy-in from all stakeholders?

How Not To Do Story Mapping

I started on my journey as an Agile Project Manager about 9 months ago, and I stepped into two highly technical backend search teams that approached story writing from a technical detail stand point. Paul Goddard, in his book Improv-ing Agile Teams, mentioned that he was afraid development teams had transformed the story card away from it’s original purpose, and back into a placeholder for the technical documentation [requirements] of the past. This was exactly what I felt my teams were doing.

Here are the observations I made and the reason’s I felt it was problematic that we were writing stories this way:

• There seemed to be a pretty consistent mix-up on exactly what was being built. We would come to a demo meeting and end up in a debate on exactly what it meant to verify that story. The way the stories were written though, it was very tough to actually understand the functionality being built and then even harder to translate that into Acceptance Criteria
• It was nearly impossible to communicate back to Stakeholders or even follow along in a conversation with the development team as everything was written from a Technical requirements stand point instead of actually having conversations about what we were building.
• The team rarely had the big picture of what was being built because we weren’t doing a Story Map and we rarely discussed the entire big picture of the project, it was usually limited to one area of functionality we were working on.
• Understanding MVP was nearly impossible because once again, we weren’t discussing what we were building, who we were building it for, and why it was important.

I could go on and on, but the main point is I noticed both of my teams were really separated from the end user and instead of providing solutions to problems, we were completing technical specs. It was amazing how often we would complete a card by the technical specs, and then when it didn’t work right and I had them walk through who it was actually for and why it was being built, light bulbs went off and they immediately knew a better way to implement.

Around this time, everything in my world seemed to begin aligning and pointing towards the need for proper user stories and coincidentally, the APM team at CareerBuilder decided on User Story Mapping by Jeff Patton for our Q2 book read.

I started reading this book, and AH HA! The light bulb went on and I had found the solution to all of my problems! So what did I do? I promptly rushed straight to my teams and attempted to implement User Story Mapping with them. This will be easy I thought… only it wasn’t. I fell flat on my face and probably confused my team more than actually helping them.

What I forgot to account for is that human beings aren’t very good at change. There is a reason many of us like routine. It makes us comfortable and we become GOOD at the task at hand. My teams really struggled to understand telling the story and how to make the backbone and walking skeleton of the Story Map. They tried to figure out how to translate our current model into the Story Map which didn’t easily translate. And when they had questions for me, I was stuck! The big issue was that I was not prepared to coach them through this, and I didn’t successfully help them to understand what we were aiming for.

I learned a very valuable lesson in this though. There is a TON of valuable information on Agile in books, blogs, forums, you name it. However, you have to be careful not to hear or see something and immediately run to your teams and expect they will get it. It’s critical that you first internalize and think through how your team might respond to it, and from there come up with a good way to introduce it to them.

I backed off of the Story Map exercise and in the short term am working towards writing better user stories and we’ve made strides in that area. We went back to the basics of As a… I want… So that… and we have greatly simplified our stories and gotten back to talking about the who, what, and why of the things we are building.

I’m now preparing a workshop where I plan to get my team away from their day to day activities, and we are going to use an entirely fictional example of an app that we want to build to practice this exercise. It’s going to cover not only User Story Mapping, but the Agile approach to adaptive planning. We’ll start with Story Mapping and go all the way through Sprint planning.

My hope is that by removing the connection to their work, they will be able to focus on the actual activities, and hopefully come away with the big picture of a great way to plan out and work our Agile projects. After the workshop, we can then figure out how to translate that to our backend services and work on applying in a way that best meets our needs.

I think a great summary of how to apply User Story Mapping or any other type of Agile exercise would be:

1. Read or Learn about what you want to do
2. Stop & Internalize it FIRST
3. Poke holes in the idea or think through the challenges your team may have with it
4. Come up with good analogies and activities to explain what you are trying to get them to do
5. Then bring it to the team
6. Starting with textbook implementation, adapt it to your needs

What challenges have you had with User Story writing or even Story Maps in the teams you work with and how did you overcome it? I’d love to hear your thoughts in the comments section.