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.