In this episode, Dan, Alba, and Michael are diving deep into different approaches to starting a backlog, they describe the benefits of story mapping, and explain why it is a great tool to achieve a shared understanding throughout the whole team. Listen to this episode to achieve a comprehensive understanding of Story Mapping with various examples that will help you put this concept into practice.
- Why is Story Mapping a great way to create a product backlog?
- The entire team can see the overall vision and what is in the mind of the Product Owner
- It is a way to identify the release strategy
- Story Mapping can be a helpful tool when change needs to be embraced
- Mechanics about how to create a User Story Map:
- Who? Story Mapping starts with the user
- What are the goals to achieve? A journey map for the team including all pain points
- How? Identify how to address those pain points
- Organizing left to right and top to bottom
- Examples of Story Mapping and MVP (Minimum Viable Product):
- Alba shares how she uses Story Mapping in her work as an artist
- Story Mapping can go wrong
- Not knowing how to identify your MVP
- Having difficulty identifying opportunities for learning
- The what and the why need to be addressed for Story Mapping, not just the how
- Having someone with the experience in Story Mapping is hugely important for the process to develop the best way possible
- There needs to be conversations about how Story Mapping will be done
Mentioned in this Episode:
- User Story Mapping: Discover the Whole Story, Build the Right Product, by Jeff Patton and Peter Economy
- Coaching Agile Teams: A Companion for Scrum Masters, Agile Coaches, and Project Managers in Transition, by Lyssa Adkins
- Medical Medium: Cleanse to Heal, by Anthony Williams
- Lean Enterprise: How High Performance Organizations Innovate at Scale, by Jez Humble, Joanne Molesky, and Barry O’Reilly
Transcript [This transcript is auto-generated and may not be completely accurate in its depiction of the English language or rules of grammar.]
Intro: [00:03] Welcome to the Agile Coaches’ Corner by AgileThought. The podcast for practitioners and leaders seeking advice to refine the way they work and pave the path to better outcomes. Now here’s your host, coach, and agile expert, Dan Neumann.
Dan Neumann: [00:17] Welcome to this episode of the Agile Coaches’ Corner podcast. I’m your host Dan Neumann, and joined today by two AgileThought colleagues, Alba Uribe and Mike Guiler. Thank you very much for joining the podcast.
Mike Guiler: [00:31] Well, thanks for inviting us.
Alba Uribe: [00:32] Thanks for the opportunity. This is great.
Dan Neumann: [00:35] And Alba your first, your first time. Here.
Alba Uribe: [00:39] It is my first time.
Dan Neumann: [00:42] We will be gentle. Hal was on for the first time, a couple of weeks ago. And I asked him how he ended up here at AgileThought. And so not to go off script too far, but Alba, how did you end up here at AgileThought?
Alba Uribe: [00:59] Yeah, actually I have been listening to the podcast for almost two years and I was thinking, well, it would be cool to join AgileThought. I think this is a great place to work and learn and here I am, and I’m so happy to be here. Thanks so much. Yeah.
Dan Neumann: [01:16] Happy to have you here. Thanks for being a listener and thank you to all the other listeners that are out there right now. Very much appreciate the downloads and the comments and the questions. So always an open door to to have people engage. The topic today. We’re going to be exploring story mapping and Alba, this is something that you proposed as one of our topics. And I would kind of ask you to, to start why story mapping as a topic? Why is it important?
Alba Uribe: [01:46] Yeah, I’m super passionate about story mapping. Story mapping is a technique that allows organizations and especially specifically the product area to develop their backlog in a two-dimensional way and have a shared understanding of what the feature or the outcome is. So that’s a great tool to build a backlog.
Dan Neumann: [02:11] How’s that different than maybe other approaches you’ve seen people use to start backlogs or what’s the gap that you or Mike see kind of getting addressed there?
Alba Uribe: [02:21] Yeah. So with a story mapping you’re developing workflows based on the user experience from a step one to step two, instead of just building a flat backlog. So you’re building high level ideas and then breaking them from left to right, and then breaking them down from top to bottom, you’re able to identify dependency and gaps is, is an amazing tool to have, again, a shared understanding to have conversation with the teams. Not just write in a document of requirement document, and somebody just reading it on their own. Here are you have conversations, you identify gaps, like I mentioned at the beginning, and it’s very useful for to see the overall goal of the feature instead of just an isolated section of a product.
Mike Guiler: [03:25] I love the fact that you brought up that it’s not a flat backlog for me. The story mapping exercise brings the backlog to life, or is actually ideally the precursor to the actual creation of the product backlog. And now this flat thing becomes very dynamic and alive and people can kind of put their hands on it and see the overall vision of what’s what’s in the mind of, of the product owner and the product manager and the whole business organization. It’s such a powerful tool to bring it to life.
Alba Uribe: [04:00] Yeah. And to add to that also, you are able to identify release strategy. So what is your release strategy? What is your learning strategy, which can be the MVP, maybe a prototype that you can put out there in the market and learn from it. So the idea is to build, release, measure, learn and tweak it, or even toss it. If it doesn’t work, then why continue building something in working on something that used to bring in value to their organizations.
Dan Neumann: [04:36] A couple of words that went by in there that, that I thought were really important. I mean, I know you talked about requirements documents in previous approaches, and now we’re talking about, you know, I think alive and creating alignment and sharing a vision. And for me, that’s one of the biggest changes as companies or teams move to agile methods is realizing that what they thought they wanted is just a point in time assessment. And that needs to be alive. There has to be ways to respond to that change. Here’s what we thought was going to be for release one, oh my goodness. Something changed. How do we respond to release one? How do we embrace that change? And, and story mapping can be a helpful tool and having that conversation and creating that clarity.
Alba Uribe: [05:25] Yeah. And, and to give you an example of one of the organizations I worked, they had a homepage that was quite old and they thought that put in a new one. So they did a story mapping. They identified MVP, they did it in one week. They, they did the AB testing with the new and improved homepage. And the results were that the users wanted to keep the old page. So here we are thinking, oh, my, this is awesome, has more colors. It’s very useful. It has all these neat features, but at the end of the day, the users wanted to keep the homepage. So that’s, that’s one of the things and the benefits of identifying that learning strategy or MVP.
Mike Guiler: [06:17] So I’m interested now, but have, have you ever experienced where you get the people in the room and you’re doing the story mapping, but everything’s gotta be done. It’s all MVP. And, and how did you, if I don’t know if this happened in, in this scenario, but how did you help them get to the point where, well, let’s just do a little thing and learn a bit so that we didn’t do the homepage and everything else, and then discover, oh, for heaven sakes. This isn’t actually what our customers really want.
Alba Uribe: [06:44] Yeah. So the, the whole project actually, or the whole product was to revise the, the whole UI and they started with the homepage. So that was the MVP. So they, at the beginning, they wanted to do the whole revamp of the website and I help them understand that lets, put something out there in front of the users so we can learn and see if what we’re thinking or the strategy is something that is valid. So at that point they kind of say, okay, I think that that is something that we’re willing to do. It makes sense. And then we went ahead and did it, but it took, it wasn’t that simple. It took a lot, there were a lot of meetings back and forth and people like, oh no, we want everything. And again, applying that agile mindset of inspection in a patient, correct. Or that’s, that’s also.
Dan Neumann: [07:49] We’ve talked a little bit about the why’s of some of the story mapping and a pet decided they should weigh in and, and have a comment, which is part of the fun of working from home. And That was a bark of agreement. I love it. I love it.
Mike Guiler: [08:07] Charlie is very agile.
Dan Neumann: [08:10] Is it a small agile dog?
Mike Guiler: [08:12] Yes, he is.
Dan Neumann: [08:14] Perfect. so story mapping, we should probably mention for folks maybe newer to the concept Jeff Patent and his book story mapping is where much of what we’re going to talk about here comes from, and certainly is a good read for folks. Let’s talk a little bit about the mechanics of how to go about creating a story map. We mentioned the value in having a shared vision and the opportunity to identify where we’re going to do certain releases and, and take iterative and incremental approaches to it. But let’s talk a little bit about how that how that happens.
Mike Guiler: [08:46] So I think it starts with the user, right? So what is the persona? Who, who are you on to, to focus your effort on? And most organizations have multiple personas, right? So you got to do a little persona discovery to figure out, well, these are the people that, that are our application is targeted at, and then maybe a journey map for those people. What are their pain points? What, what do they love about our system? What do they not so much about? So you want to identify, you know, the person or the role, if you will, and the pain points. And then from there, you can begin to start to talk about, you know, Alba had mentioned, you know, moving left to right to your application. Building that backbone around what are the things we want to get after they’re going to help address those pain points?
Dan Neumann: [09:37] So the person who, who are we talking about, a persona and an examplar, and then what are their pains? What are they, what are their goals? What are they trying to achieve as you go through? Okay. Certainly helpful.
Alba Uribe: [09:51] Yeah. So identify your hypothesis. So what is you are trying to resolve, or you’re trying to have happy customers, basically, because if you want them to come to your website and consume your products, that you have to make it in such a way that they’re happy and they keep coming back. So what is your vision? What is the problem they’re trying to solve and understanding that very well. And what is their behaviors like Mike mentioned, what are their behaviors of those users?
Dan Neumann: [10:29] Yep. I think of obviously one example that comes to mind for me pre pandemic mostly was the need to travel frequently. So I would go out to my favorite airlines website. And ideally there’s an option for me to quickly book the same trip that I booked previously going to the same client this week that I went to last week. That’ll go to the week after the one after that. How do they easily solve, you know, Dan Neumann business travel, or going to the same place for six months in a row. That would be an example of a problem that somebody might solve. Are there other, other ones that come to mind for you maybe Alba with, from your past experience, a persona, the problem they’re trying to achieve and breaking that down?
Alba Uribe: [11:12] Yeah. Then identifying a steps. So steps. What is when, when I did a story might be, so when I do a story might be nice. They’re asking my, my product person. So what is the first step that the user is going to do? X, Y, and Z, then what is the second one and so on. And so you go from left to right. And then you develop the tales from top to bottom. So it’s step number one is very high level. And then, okay. What are the, the details to that? Let’s say it’s a login page. First thing. Yeah. They go to a login page. So in the login page, you have to reset your password. You have to login, you have to enter your user ID and all that, so that those are the activities. And we’ll go from top to bottom. And then you identify dependencies during that process, identify gaps. Sometimes just having a flat backlog. Doesn’t allow you to do that. When you have a two dimensional backlog, you’re able to identify, Hey, we have a gap here. We thought we could cover this particular functionality, but we have a dependency here is external, and it’s going to delay some of the development. So those, that process is, is very useful for identifying gaps as well.
Mike Guiler: [12:41] Yeah. When, when I’m running a story mapping workshop, and we’re talking about those steps, you know, I’m trying to encourage the people to go really wide. Think about anything. Don’t worry about if it’s a nice to have or anything, just put it down. You know, the whole, you want to try to discover as much as you can so that you begin to, to bring to life that that potential backlog if you will. And then you can begin to kind of go back and, and start to go deep on, on each individual of the steps. And really then to your point, it really bringing it back to life for, for the, the people in the room.
Dan Neumann: [13:17] Have you had that sense, I think you were, you were asking Alba, Mike, I’ll twist it around and ask you like, when, when you do go wide, I mean, all those good ideas, I almost sense people get into this loss aversion. It’s like, no, no, I had the idea. I want it. I really want it now. I can’t live without it.
Mike Guiler: [13:32] So yeah, absolutely. So thank you very much, Mr. Neumann for turning that back at me. So absolutely, you know, it, it happens and you kind of want to be able to have that conversation. And so they went wide and now we’re starting to go deep and they’re like, no, no, no, I’ve got to have that. And now you’ve got to begin to have the critical conversation around. Yeah. But we need to get something out. What, what can we live without initially so that we can get back to Alba’s example. We can get some feedback on our redesign of our homepage that then informs us and we’ll get there. Right? We’re just another iteration away from getting to that next, next release. And so as a, as a business unit, we have to look at our backlog or our story map and go, now that we can live without this for a little bit, it’s coming, don’t worry about, you know, we need a big bang of everything. We can take small little chunks of this thing.
Dan Neumann: [14:33] I was thinking of, of the, the, the conversation around what can you live without, and almost wondering about opportunities and to shift it to, but what if you could have this part now, because so many times there’s an inclination to hold a release till it’s all there. And I wonder if it’s a chance to say, yeah, but you could have this now, right. Instead of no, no, you don’t need that now. It’s like, but this is what you could have now. And you could start capturing the value you could, you can, de-risk your system, like Elvis said, right. Put it out there. Oh, the users hate it. Well, I’m glad we didn’t spend a year doubling down on what users hate. Right. You’ve, you’ve learned rapidly and you could have built a whole lot of waste into that system.
Alba Uribe: [15:16] Exactly.
Mike Guiler: [15:17] And to build off of that, one of the cool techniques is, is as you’ve, you’ve put you on your steps and now you’ve done some level of, of your depth. Now you can begin to walk the wall assuming that you’ve done it old school, and you’ve got your story map up on the wall and you can literally look at each of the steps and go, gosh, do I have a fully functioning piece of software here? So just enough, the flat backlog or the requirements document, it’s difficult to do that, but when it’s up on the wall and you can see all the steps for your persona and all of the depth, you can literally start to draw lines between the things underneath of the steps, the solutions, and go, yeah. If we just did these five, that’s actually fully functioning back to your hypothetical, Dan, that would be enough for Dan to quickly book his return or his next flight based off of what he did before. That’s awesome. Let’s get that out there. So to your question, you know, if you just got that, would that be enough? The answer’s yes.
Dan Neumann: [16:36] So we’ve talked about story mapping and we’re going to continue to paint a word picture of what we’re describing, and then hopefully we’ll be able to release some video of this part two of a shared desktop. But Alba, do you want to walk us through an example of story mapping?
Alba Uribe: [16:55] Sure. I have a personal example. I’m a painter. So I paint in acrylics and I use kind of a story mapping or MVP actually identifying the MVP and doing it in iteration doing my work in iteration. So initially I have this client came with this picture of a flower or some roses in a vase, it would have a very complicated background in, at that point, we agree that I was going to do just the flowers, the vase in a simple background. So that right there, we had the conversation, we agreed on what would be our product in kind of a reduced scope of what the mentioned was at the beginning. And then the first iteration, I would say for the first MVP, it will be the drawing of the sketch. So I draw a sketch. You can use pencil. Some people use the same brushes and the sketches. The, the second step is, or the second iteration, because this is this I get feedback from the user at this point. The process, the way you like it is a proportion. Okay. Things like that. So we are in constant conversation. Then I go ahead and do the background, a paint the background, and we start painting the dark parts of the roses. And then continue to add more color to the roses and the background changing a little bit, the background, the background looks matte and now a little bit different. I added more beige tones based on the feedback. And at that point, when I showed the roses to my client, she said, oh, but the roses are too dark can you make it a little lighter. And I went ahead and did that. I added more lighter red, I started working on the stems and the table in and the vase where the roses are. And okay. So then, and then I got the final product. So that was that’s here, the roses, or I got the vase with the table, all the leaves in the background and with my signature and I had a happy customer. Yeah. Again, all constant feedback with a user in incorporating that feedback, iterateing and incorporating their feedback.
Dan Neumann: [19:51] We’ll definitely have to find a way to, to share the video here. And it reminds me of one of the examples, a metaphor. Well, if Mona Lisa had been drawn this way and, and you know, it says this and not that, but here you you’re actually doing it. We’re not imagining what a dead artist happened to do. And so you had the constant feedback loops and it reminds me of a quote. I think it’s something like art is never finished. It’s just abandoned and right. And you could always do more with the painting. You could always iterate on it again and again and again, I think that lesson can apply to story maps and to working software too. There’s always more good ideas at some point you have to ship and at some point you stop investing in it. But you can’t just keep going and going and going and going because it’ll never be done.
Alba Uribe: [20:42] Yeah. And there there’s a point. Yeah. There’s a point where you, if you continue to invest your rate of return diminishes, so that’s, that’s something to consider.
Dan Neumann: [20:52] Perfect. Well, thanks for walking through that. So we’ve talked about all the awesome stuff that can happen with story mapping, this shared vision and opportunity to negotiate, scope and view dependencies, and talk about users’ needs and how we’re going to meet those. Let’s talk about some of the story mapping gone wrong. So what, what are some pitfalls you folks have seen people fall into? Yeah. Alba, did you have one come to mind?
Alba Uribe: [21:17] Sure. Yeah. Identifying not knowing how to identify your MVP or continue to say, no, we don’t have MVP we have to do this whole big ban. And so having that difficulty on identifying opportunities of learning is, is one of the big pitfalls that I have seen.
Mike Guiler: [21:40] Yeah. For me, I see when, when the group decides that, ah, we only need, you know, me and Albert in the room to do it, our voices, our experience will be plenty. You know, we couldn’t abs absolutely couldn’t benefit from, I don’t know, the scrum team being in the room and sharing the, the other side of that coin is you get too many you get too many technology, people in the room and all of a sudden it’s a conversations around the house instead of the what and the why. And now you, you, you can’t literally get to a story map because we’re, we’re talking about, you know, Java versus .net. And, you know, we got to upgrade our database to do it. And it’s like, no, wait guys, gals, we’ve missed the whole point of this thing. So having somebody in the room that knows how to do this can help facilitate, has some experience worth its weight in gold.
Alba Uribe: [22:34] Great point.
Dan Neumann: [22:36] The how is a conversation to have just not now, right? Yeah. Yes. We’ll get there. We’ll get there later. So you talked about so I’ll be, you’re mentioning right to too much scope before capturing some value by releasing too few people, Mike, right. That’s having a shared story across a whole team, allows them to make decisions without having to send everything up to the big boss. Well, what does it make sense to, I dunno, put the dollar sign in front of the currency, whatever, just figure it out. Right. If you understand what the person’s trying to do, decide, you don’t need to do an analysis, sprint this sprint and then a build it sprint next sprint, just like decide, do something you all have heard the story, do something that makes sense in the context of the story. That’s awesome.
Mike Guiler: [23:31] And to build off of that, it’s not just necessarily heard the story, but you see the entire picture at a high level. So you’re right. When you’re down into the weeds on that story, you’ve got the bigger picture. You see how it fits in as opposed to the, well, I’m just doing this story. And yeah we had backlog refinement and I got a little bit, but that’s usually just that piece. I don’t really see the whole picture. I don’t see the beautiful painting that Alba made. I only see the leaf that you’re asking me to play with. Well, it would be nice if I knew it was on a rose. Story mapping, does that if you have a big tent event.
Alba Uribe: [24:07] Yeah. Yeah. Another thing that I’ve seen is organizations just having the whole UI done upfront or the, yeah. The mock-ups or the UX designed on perfectly done before having conversations about how to develop a story map and the, the way, and if pattern actually is the one that, that says this the way he suggested, he said, you can even have a drawing on a piece of paper, just sit down with your developers. Well, right now, even right now that we are remote, you can just draw and then upload your drawings and then have the conversation with, with the map. And they’ve continued to develop their backlog while actually you can get details after later on that are very useful doing these interaction with paper designs versus having the whole complete UI and then having to change it again.
Mike Guiler: [25:14] And to build off of that, I had an experience with, with a customer I was working with we had on shore off shore and we were in New York city doing a story map and somebody in the room went, no, how cool would it be if we could have a quick little conversation with the offshore people and see while we were sleeping, if they could quickly build, you know, a version of this thing that was setting up on a wall, it was a story map? And it happened. And literally when we walked in at like 10:00 AM, the next day here was this working piece of software. Yeah. Really rough around the edges, but a working piece of software for the thing, we just did a story map for. How it was unbelievable, unbelievably powerful, and the feedback to the product owner and their leadership was like, this really works. We had this two dimensional thing up on a wall, and now we’ve got working software in less than 24 hours. Let’s keep doing this. It’s unbelievably powerful.
Dan Neumann: [26:14] That does sound powerful. Right. Just going from, from idea and some shared conversation to working software in exceedingly short increments. Super cool. So we could go on a very long time on story maps, but I’m gonna kind of like take a nod towards the time box here and just ask for any closing thoughts on story maps. And I guess, so we’ll start with the Mike.
Mike Guiler: [26:37] So I think to build off of the, the mistakes side is I see a lot of organizations that go let’s do story maps, great. We do them. And then they, they get dust that they did. It’s a one-time event and that’s it. And then it goes into a flat backlog with, you know, versions or releases drawn on the product backlog. And it’s never updated. It’s never used again, story maps are so much more powerful when they’re living and breathing. And they’re always up to date with what you’re releasing. Current client, we’re, we’re trying really hard to use that for our budgeting process, a story map. That’s the idea, keep them alive, keep using them. They’re they’re exceptionally powerful when they’re living and breathing.
Dan Neumann: [27:22] Yeah. So taking it outside of the software and right. Keeping it alive, otherwise it’s a requirements doc in a different form. Right. It gets done and it gets dust. Yeah. Correct. So what about you Alba?
Alba Uribe: [27:32] Yeah, I couldn’t agree more. It’s a living document. You continue to add more or change it and iterate on it. But for me, it is about the cycle of learnings or identifying the MVP, nail it first, and then scale it, you can smell it first and then a scale, your, what you learned, whether you have to toss it or whether you can scale from the learning of the MVP.
Dan Neumann: [28:03] I love it. Nail it and scale it. I think I can remember that that’s tweetable right there. Thank you. So I’m definitely have seen story maps, be powerful. There is definitely a lot of richness to the topics would encourage people to continue on the journey, ask any questions. You know, they can obviously email us at firstname.lastname@example.org and let’s transition to a topic that we have at the end of our episodes, which is what’s on your continuous learning journey. Alba, what what’s got you learn in these days?
Alba Uribe: [28:36] I have been reading a coaching agile teams, by Lisa Atkins a very, very good book. I really recommend that book for Scrum Masters and agile coaches. And one of the things that caught my attention is like just put in outside of your command and control. Usually like my background is technical and then I went into project management and then I became an agilist and that command and control was something difficult for me to get rid of. And she gives you a lot tips to do that. So that’s an awesome book. I’m also reading on the personal side, a book called cleanse to heal and it’s about eating healthy for three, six or nine days, and then cleansing your body to feel better. And that’s by Anthony William.
Dan Neumann: [29:31] Perfect. We’ll put links to those in the show notes. And I know when I I think I decided I was an agile coach at one point, because what’s the threshold of being a coach, you say you are right. And Lisa Atkin’s book, I read, read that on the train back and forth from my client. So yeah, for sure. Mike, what about,
Mike Guiler: [29:48] So for me, I’m in between books, but the next step on my list is just humbles lean enterprise.
Dan Neumann: [29:57] Probably ties in well to what you were describing with budgeting and story mapping.
Mike Guiler: [30:03] You see the magic, why I need to read that.
Dan Neumann: [30:07] Just in time learning it’s it’s I kind of get inspired by a situation and go pull that threads. That’s pretty cool. And I was sharing, sharing with you guys before we clicked to record here. Yep. My, my current learning journey is I got way outside my comfort zone and sign up for an acting class at our local civic theater. So I’m in there with a whole bunch of humans. I would have never met our, our circles would have never intersected in my normal life. And so it’s not only kind of interesting to meet all these other humans that I probably wouldn’t be dealing with. But it’s also a chance to really explore voice and body and presentation and, and do something very, very different. We’ll get to explore things like the difference between fear and danger, right? How often do we, like a lot of times there’s fear and there’s no actual danger. We’re just scared. So it’s that, that was one of the insights that resonated strongly with agile journeys. So, all right. Well, I want to appreciate both of you for joining and sharing with with me and with the podcast listeners and the agile community as a whole. Mike and Alba until next time.
Mike Guiler: [31:19] Thanks Dan.
Alba Uribe: [31:20] Thank you so much.
Outro: [31:23] This has been the Agile Coaches’ Corner podcast brought to you by AgileThought. The views, opinions and information expressed in this podcast are solely those of the hosts and the guests, and do not necessarily represent those of AgileThought. Get the show notes and other helpful tips for this episode and other episodes at agilethought.com/podcast.