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?

Post-Its vs Agile Project Management Software

While some of the posts I’ve written recently, I’ve had a specific point I wanted to make, today’s topic is really about a current experiment I’m running and whether organizing our work digitally or with physical hands on artifacts is better. This is not anything new that I invented, and I’m sure countless thousands of Scrum Masters before me have done this with their team. This is just a placeholder for me to be able to look back in time and see things I tried or what my general way of thinking was and how that’s evolved; and hopefully I’ll generate some comments from you so I can learn about things you are doing!

Problem:

The team started missing sprint goals and carrying over work sprint to sprint, and the daily stand up did not seem to provide the transparency or accountability that a team ideally needs to help collectively move the sprint forward each day.

Said another way, while we follow the “Yesterday I did, Today I plan to do… “ format, the updates were extremely vague and it was tough for me as the Scrum Master to really tell what progress, if any, we made the day prior. In addition, the team did not hold each other accountable and stories seemed to drag on longer than they should be.

Looking at this bigger problem above, there are any number of potential reasons that these issues could be coming up including:

• Are the stories groomed properly? Clear Acceptance Criteria and Definition of Done?
• Are we committing to too much work each sprint?
• Are we facing impediments and not surfacing them?
• Does the team not trust each other enough to hold each other accountable each day?

However, the purpose of this post is simply to discuss one experiment I’m trying to help with the daily stand up piece. The other questions will have to be left for another day J

At CareerBuilder, we use Mingle as our Project Management Software and for the most part all of our teams manage their work with a digital scrum board, including both of mine. However, when reading Jeff Patton’s User Story Mapping and listening to speakers or reading blogs, a lot of them still heavily reference using physical post-its and having that information up on a visible wall. So I talked with my Engineering Lead and shared that one of the concerns I had with our missed sprint goals was the lack of clear direction and accountability in our daily stand up, and that I’d like to bring a physical sprint board into our area and move towards using post-it notes during our stand ups (see picture). He was on board and we brought it to the team, and we are now heading into our second sprint using this.

Our Sprint Board in preparation for our next sprint

Prior to this, we had user stories, but did not really task those user stories out. Since a user story on average can be anywhere from 1-3 days (some more, some less), it become a little too easy to talk about the same story for a few days without providing any real clarity on what parts of it you got done. For the last two sprint planning sessions, we are now taking our user stories, and instead of just having a general discussion on what needs to be built (which tended to include some of the technical things that needed to be done anyway), we are actually trying to identify and create as many of the tasks as we know about for that user story. We aim to identify ~70-80% of the tasks and we know we’ll identify more as we learn during the sprint.

At the start of the sprint, all of the tasks we identified go up as individual post-its on our physical sprint board. The way I’m coaching the team is that while a story can take multiple days to complete, if a task takes longer than a day, it means one of three things:

1.     We sat on our hands and did nothing the day prior

2.     The task is too large and should have been broken down

3.     We are facing impediments to getting that task done

When we come to stand up each morning and can’t move a task forward though, it at least provides a very clear signal that one of those three things happened and we need to figure out which one it was and work to fix it.

It’s been a work in progress and the first sprint was a little bumpy on understanding that it’s ok to break tasks down into further chunks. The main point of introducing the tasks was to allow them to break the work down into hour long, or 2-4 hour, or whatever chunks of work allows them to best organize their day and hold themselves accountable to the progress they are making.

It was very cool to see one of the Engineers walk over late afternoon on the second to last day of the sprint, and move along two task cards that wrapped up her story! I think when we do everything digitally, it’s a little easier to hide things than when you have a physical board right out in front of the team. But on the flip side of hiding things, it’s also cool that it’s a visible sign and cause for celebration when someone can walk up and move sprint goals along!

Feedback thus far has been positive and the team has agreed to at least continue on for a few more sprints. In general, they seem to like the visible reminder right in our area, because while they can ignore Mingle, it’s tough to ignore a white board right in front of them. I’ll try to remember to write a follow up on this after I see if we start getting the desired results.

One quick note, we do still use Mingle for tracking our stories; we just added the physical white board for our daily stand up meetings to discuss the tasks associated with those stories. I’m not as worried about tracking data on the task cards though so we don’t require those to be in Mingle.

Do you and your teams prefer just working with the software versions or have you tried the old school touch and feel of post-its as well?

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.