[Music] all right uh I believe we're alive now so just wanted to say hi to everyone H streaming in to this session uh with Jeff padon where we're gonna be talking about five common mistakes that team makes um that teams make when use a story mapping so I'm just going to give people you know a couple of minutes here to uh join the session if you're joining just you know go ahead and say hi drop a note in the chat about where you're from and we we're I know we just started all right perfect I
see the chat's coming in hi Veronica uh thanks thanks for dropping a note in here uh for uh you know those of you who don't know me my name is shaan I'm the product evangelist here at M uh I usually am hosting distributed but this time around uh I'm here to bring you a session with Jeff a patteron this uh this year Jeff is really synonymous with user story mapping although he's spent sort of I decades Building Products uh out there um and then uh you wrote this book on how story mapping and story maps
of the new backlog um it's been really instrumental in my personal career in Des design I feel like I'm like a prolific story mapper it's like the answer to all all problems and every project so I'm really excited to have Jeff here with us um with to just share with the mural communities informal casual chat to share with the mro community what's happened since he wrote Story the book right like teams have been trying to leverage it what are some mistakes that common mistakes that he's seen teams make so we'll we'll get into that um
meanwhile if you all are here just know that you you can uh drop in messages in the chat as well as questions in uh in the questions box so like just we'll we'll look at the chat we'll keep an eye on the chat look at the questions and make sure we we try and uh address them as we go here all right I see a full house here Jeff so we'll uh we'll kick it off um I would say most of miror the miror community attending distributed they know probably know what user story mapping is
but for those who don't uh maybe you could start um start by sharing sort of what is a user story map Sher you can see the you can see see the mirror board that I'm sharing yes through all right for being here look uh normally if anybody's seen me Teach before I handdraw everything that I teach and I didn't have a lot of time to handdraw things we don't have a lot of time together so I did all my hand drawings this morning and pasted them in and made you nervous but because I didn't have
them there before today look uh there's just a panel that explains a little bit about what a story map is and for people that don't know I mean uh I started using this type of mapping to support Agile development for people that are already designers or ux people you know that a story map is just a journey map or an experience map it just describes the the experience of somebody using a product but one of the things I learned very early on in aile development is I can think outside in or I can think about
a users journey through a product and then start to decompose that into the work that we have to do to build the product so that's it basically story Ma just tells a story about people using a product left or right top to bottom we start to decompose user steps into smaller steps and at a certain point those smaller steps become nice tidy backlog items and then that simple square shape easy for people to use and if you can see that picture there the the bottom picture we use the the vertical axis to slice up maps
to slice them into smaller small successful releases uh look on this panel there's uh there's just a very short description of what story mapping is there's a link to the mirror template for story mapping there's a link to my book if you don't already have it there's a link to the first well one of the first articles I wrote out there that explains what it is a quick reference guide and if you do want to take a class I teach uh product management product ownership classes and people you'll build a story different variations of maps
almost every day in that class uhing Sho we were talking about what are common mistakes so look I tried to oh I didn't mean to do that hold on a second see sorry I'm a I'm fumbly when it comes to uh no you're good uh and actually I was just going to tell the audience that we'll share this mirror board out and the links to these resources uh including the templates and Jeff's book U but if I can if I could share Jeff my perspective on what a story map is I think of a journey
map sometimes as you know like from Discovery and research as the users's version of the world and a story map kind of is like a product's perspective of how the user flows through the product yes so when I think of a journey map you usually think of the user's version of the world without the product editor for the product is there or as is I'll def definitely I'll annotate a journey map U with where the pains are and the problems are and how long things you know take to do things like that but uh that's
what what we do you know if you're a product manager a characteristic of software as a product is software products continuously change and improve we're continuously looking at people's experience today in our products finding where the pains are and a map works great for that uh and then wherever there's pain you say okay what can I do to alleviate that so a lot of people we use story Maps primarily on the solution side I have to imagine what people will do step by step in the product the product that's not there yet so I love
that it's an Imaging the future kind of exercise Love It Journey map shows the problem story maps are the solution so let's dig into yeah what yeah what's some of the some of the problems you're seeing because I know every time I start building a story map there's so many moments that I get stuck or I pause or you know just hard yeah expect your problems aren't the problems that I see commonly so if I go through this first one I put in here the first one thing I stumble into when I'm working with people
building story Maps is they don't actually map stories or they lose the story the most common variation of thing I things I see that people refer to as a story map or where they identify features in the product and then uh left to right they'll put they'll prioritize features most important feature first least important feature to the right and then they'll decompose the feature into components or parts of features things they have to build and that works well for building a backlog it just doesn't tell a story it reveals a plan and so uh there's
a short description of this here but I'll just remind people that look if you've got a feature you use a story map to tell the story about the feature just identify uh who's using that feature and from beginning to end tell the story step by step by step uh get across the tell the whole story first and then start to decompose each step into smaller steps and break it down helps uh should have drawn this here it helps here to also start to visualize what it looks like visualize what screens look like things like that
oh interesting so would you like just drop in like screenshots from any prototypes ores here yeah usually tile those across the top and as soon as people can see what a screen looks like uh if you're working with Engineers on a team they can start to participate in decomposing that or identifying what's going on in those screens I can usually walk up to a map and if all if everything written on the sticky notes are nouns uh names of features or names of components or names of things on screens I know that's probably not a
story map what I'm looking for are short verb phrases are steps are things that people do you may know that when I teach story mapping I'll ask people to I'll uh ask people to map their morning routine and I'll point out to them that they they wrote down brush teeth they didn't write write down toothbrush and toothpaste those those are the things those are the features those aren't the steps right right so yeah the first one first problem I see most commonly is people aren't actually telling a story with the map look the the the
second thing I see is you're we're using these maps for decomposition and people start telling a story but then they just drop down and into Super granular details get lost in the details whenever I see a story map that starts with login or uh has things that say click a particular button I know they're down in the weeds or way down uh the the biggest thing that I didn't point out in the story mapping book that I use commonly is I make sure that people tell me okay who's in the story identify people and identify
the beginning and the end of the story just get to the end of the story stay high level stay mile wide inch deep get to the end of the story and then start decomposing don't get lost in the weeds or lost in the details and never get to the end of the story so I see people getting lost really quickly with those things this is um this is really interesting to me because it's really about like yeah having the full full picture but then also maybe and tell me if you see this but perhaps it's
also about choosing the right level of the right beginning and the right end so they can't be too big maybe like you need like a medium sized part of the story um because sometimes I see teams like trying to map their entire entire product on one map well that's funny be okay go to number four let me go to number four okay because come back to three because that's what that's what I see is I see people they've already got an existing product and they want to just add an additional feature capability to the product
and for some reason they feel like they have to tell the whole product story beginning to end they have to talk about what people already do in the product all the way from the beginning to the end and then it sometimes it's nice to have that whole product map and then when you're adding a feature you can see that that feature injects a few extra steps for one person upstream and another person Downstream but don't do that uh it's so again my number four is mapping the whole product when you're just trying to add a
single feature uh uh oh shoot I got to correct my language out of single features when you're just trying to add features sorry I pasted this in past this morning uh so yeah I see that people going way too broad uh and they don't start the the beginning and the end of their map at the beginning the end of using the feature they started at the beginning and the end of using the whole product and uh and then kind of bury the lead or bury the feature inside there totally and I think actually this is
really like I don't want to lose this uh important point I that choosing the right level for mapping your story is important and I like this feature sort of feature level um or maybe epic but like don't try and go beyond that that's a bigger discussion sometimes but uh you don't agree yeah no no no well just all that epic means is it's too big to put in the current Sprint so uh everything's everything's an epic until it's not and epic doesn't mean it's not a story it just means it's big that's all uh yeah
things started really really big and the metaphor from the story mapping book I use is the The Rock smashing metaphor in fact there's another book kind of built around that metaphor I didn't that just came out recently but look if you've got a big rock and you put it in the table uh in the middle of the table and hit it with a sledgehammer and it breaks into a whole bunch of pieces all those pieces are still rocks same thing with a story you put a big story out there you break it into small pieces
all those pieces are still stories now the story we want to bring into the team to do development with are are pretty small uh and a map can help you get down to small but you get down to small by telling the story now the shipper the other thing I didn't point it out here but it's in the quick reference is um use the concept of goal level that comes from a guy named alist Coburn where uh where we look at steps that people take from a goal goal level perspective a functional level or sea
level using goal level is something you would start doing with the intention of finishing it before you do something else uh like again when I teach people a story map and they write down take a shower I'll explain well taking a shower is functional level because you don't start taking a shower and then say wow this is really getting boring I'm gonna go grab a cup of coffee and I'll finish my shower later right way it works you start with intention of finishing it so yeah maps have a goal level they can be really high
goal level uh or they can but one of the things that happens sometimes is people drop way down into the weeds in into the details you'll need to get to the details eventually but before you get that whole story out got it got it okay this is uh the these are like some good metaphors to keep in mind I have a question that's kind of relevant so I'm G to sneak it in here and then we can go to uh problem number three but uh do you uh have like a certain number of relief leases
that you think teams should map out or like how do you think because you know we map it out and then we do have the debate a negotiation of what we want to do in MVP how like do how do you think about what what's your suggestion to teams as they're thinking about like how deep do I go yeah um uh that's number five let's do number five oh okay well kind of because I've got the pictures there um three or two plus one two plus one extra one thing to know when it comes to
how deep and then I'll explain what's going what I'm trying to show in those pictures and what I'm showing in that text yeah you know the minute you release something and people start start to use it whatever you thought was going to be in the next will change because of what you see happen when people use it so yeah you're doing your best to try and predict what people will do with what you ship but the minute you start to see outc comes you many you see people do things what's in the second release changes
so you know don't map out three and four and five releases but what what I uh what I'm talking about in this and this may be tougher to communicate in in a few paragraphs is the common thing I see people doing with story mappings is uh filling each release to capacity saying okay we've got a release how much can we get in it and making trade-offs about what goes into that release uh and the a lot of arguing about what feature belongs and what release what I'm trying to say here is don't one of the
things it's the oh I've got to write a a second edition of the story mapping book I'm sharper with the way I teach this these these days but when I talk about a release strategy strategy a strategy is what you use to make decisions about what goes into a release so I organize release strategies around a Target outcome by a Target outcome I mean who does what differently so I can say if the first truth releas is primarily for this person or this class of people and they can do this they do this differently they
achieve this and uh maybe for a secondary class of people and it affects them a little bit then uh given that then I make decisions about what goes into each release what is the least I can put in the release to allow these people I'm focusing on to accomplish what they need to accomplish or to improve things to become more efficient or more effective or use uh our product to do something that they were doing in outside our product before I will anchor a release on target outcomes target audience and uh and what their actions
are they're different and I can build a release strategy that goes three four five releases deep but the strategy isn't the choices I made for the features the strategy is my choice of where I'm going to focus my release uh on what people first um think of easy metaphors to describe this but uh this is the way we grow a product in the market I remember I work with the company I work with spotif Spotify as a company when they were tiny when there were a couple hundred people and when their product was the only
way to log into Spotify was through Facebook and the only way to find new music was by looking to see what your friends were listening to so uh the target audience uh for first version of Spotify were people using Facebook that had friends if you didn't use Facebook and didn't have friends uh it wasn't going to help you as much so you could even log on if you didn't have Facebook so that's a small target audience to start with you make a relase smaller by choosing a smaller audience and and fewer outcomes yeah and then
a really it sounds like like really kind of attaching yourself to that outcome and to that story whether the outome is a metric or it's like it could would be a qualitative sometimes it's if you're really small it might be a qualitative outcome if you're a bigger company might be a metric but really tying to outcomes uh versus what is the capacity and what is uh yeah just like trying to fill fill fill the bucket yeah my yeah don't uh what I see people doing with a story map sometimes is just trying to fill the
bucket to capacity and instead of backing up and saying what's our strategy who are we focused on and uh I see uh when people are trying to fill the capacity you see them creating releases to try to help too many people just a little bit instead of really focusing on helping one person or one group of people a lot yeah so let's go all the way back to my third one and then you and I can talk and uh this one's fairly deep the the other Fring uh a lot of T text here I just
realized I need to put a uh going to go back and clean up my paragraph here just a little bit one of the things that people always Fred about is you know story maps are flat uh they tell a story and this really winds up people a lot they'll say that there's branches or conditions here and uh people will say well you we do this step and then somebody has to make a decision if they make the decision if they it could end up in them doing this or this uh and if they go the
other direction they could do that or that uh and I'll say okay okay that's great uh now so i' I'd map it like this and I'll just flatten it out and they said well why did you choose to put that Branch first versus the other branch and I'll say I didn't you did in the way you told me the story I a quirk of the way humans have to speak is we can't speak two sentences at the same time and I'll map it in the order people tell the story uh sometimes I'll you know go
up a level and indicate the this is the first Branch or I don't don't say this is the first Branch we indicate what the choice that people made and the steps underneath it but I like using the vertical axis to decompose and to prioritize and if we start trying to uh a story map is not a flowchart the story map really relies on storytelling on humans to back it up to point and gesture and say people do this then this then this and if they make this decision they'll go over here and do this but
they made this other decision they're going to go over here to this branch and do these things that that's it relies on story Maps don't work as a communication device without a human to to walk you through them I think this is so important because yeah people can get really hung up on it and I love when you said a story map is not a flowchart right like flowcharts have their purpose and a story map is just a tool it's not meant to be like the most accurate representation of like there are much more accurate
representations the the um the story Maps really lean on storytelling they really lean on uh let me explain that second picture uh it's sometimes you see a a branch where a user could do one set of things or another set of things or you see another Branch where we hand off to two different users us are do are doing things concurrently and so I'll see people get super tempted to stack them on top of each other to to show that it's happening concurrently and you know I'll live with that that's okay uh but again I
just flatten it out uh um and use use the storytelling to communicate that uh there's a one of the concepts the communicate in the story mapping book is the the vacation photo effect and sheer you know what I'm talking about no no remind me again um look if I show uh if I send you one of my vacation photos you can look at it and say well that looks interesting and that looks fun but when I see that vacation photo I remember being there I remember lots of details I remember what it sounded like smelled
like I remember everything we were doing before that and what we were doing after that the vacation photo means a lot to someone who was there and when you look at one of these Maps or one of these pictures you don't need all the details by seeing what's in the map you remember what we talked about and what happened when we were there important thing for me me about stories in Agile development and storytelling is we rely an awful lot on the visualization plus the the talking the collaboration we did we rely a lot on
that vacation photo effect to communicate yeah I think this is okay I love I love that metaphor because it's all of this is meaningless unless you're doing it collaboratively and the artifact is like is just a way means of collaboration right it's a momento it's well it facilitates collaboration while you're doing it and just like a vacation photo after you did it helps you remember all the things you talked about and if somebody wasn't there somebody who was there can just like if I were to tell you a story about one of my vacation photos
I could show it to you and then tell you the story around it and then when you see the photo you'll remember some of my story uh that that's that's the way it works so that they don't rely on precise communication the way a flowchart would or a uml diagram or a use case or you know if if they're if you're trying to communicate a lot of important stuff without being there you're going to have to use a more uh yeah higher Precision form of communication totally and those come before and after a story map
right the story map is about collaborating making decisions aligning uh maybe discover C in but not necessarily I mean one of the questions one of the questions I saw in chat was how do you go from to jira from here um and I'm just going to put a plugin for the mirror jira integation you're using miror you can just like select all of these yellow stories and send them to jira exactly you use a miror to say to collaborate build shared understanding and then if you decide okay this is our first release slice select those
things put them into jira and what happens in is they turn into a flat backlog uh and you can then prioritize them as work and do the work but there's still a connection between the mirror board and jira so you can see what work has been started and finished and uh and things like that yeah and personally for me when I do this with my teams I love seeing uh just getting a visual I like I'm a designer I'm not a fan of J but sometimes I can see a visual of which parts of the
story are green and done and which parts are still to be done so I know what to expect in the experience so don't use Jura to communicate uh or tell the story uh you use jira to prioritize and organize work uh jir is a ticketing tool it's a planning tool it is not a storytelling tool and I've worked with alassian on and off over the years and atasan is really good at using jira for planning using other tools for telling stories and telling their product story they're not relying on jir for that all right so
I know we are technically on time but because we have Jeff here I have like one I see one more really interesting question there's so many questions honestly you guys in the chat will try and try and like get to uh get to some of these but uh the question I I know we should do we should do a follow-up Q&A um the question that I thought was really interesting was how what do you do you have a perspective on jobs to be done and does that does that kind of work with story mapping so
in the context of teaching I I I'll go back to original Clayton Christensen videos and explain jobs to be done and I suffer from learning uh interaction design from guys like Alan Cooper and the founder of personas things like that or the person who popularized using personas and what Christensen means by a job to be done and what Alan Cooper meant by a goal honestly is the same thing it's it's our why it's why we use the product and yes I like jobs to be done uh but it's a a way of working with things
that came from one community and traditional interaction design came from another community and I know that jobs to be done folks will show examples of personas and why they're not good but usually they showed examples of bad personas and and yes bad personas aren't good for for uh traditional design or for jobs to be done I like jobs to be done thinking uh uh but I see a a lot of overlap in it and but also I have to claim a little bit of ignorance I understand the basics of jobs to be done and where
the origin comes from there's a few models that come from jobs to be done I like like the forces diagram is when I'll use and thinking through things uh uh but uh it I don't know if jobs to be done has something like a journey map or a story map as a as a as a model built into it so I the mindset is great but I uh come get a hold of me later and I'll tangle with you but it's not new it's not different it's it's it's good language for talking about something we
all we all should understand totally and essentially and the forces diagram is my favorite too but essentially all of these Frameworks talk about you know what is the user what is the user goal and I think in a story map also you have the space for your Target user what are you know what are they trying to achieve and then how is your solution helping them achieve it so it's kind of we're all trying to say the same things with different vocabulary at risk of going too far along uh story map makes you think in
outcomes all all precisely Define an outcome is what your users do uh do how they feel and what they say after that if you're building a story map right it makes you think through what users will then do with your product and if every sticky note you put down is a short verb phrase every one of them are those are things that could be instrumented in your product and measured whether they actually do those things a a story map forces you to think in outcomes uh and I'll see jobs to be done is really good
at pointing out people's goals but at some point we need to figure out what they do differently and we need to be able to tell a story about what they do differently and then we need to build a product that supports them doing that force you to Envision what they do right sounds like we're gonna close out the stream this was too short but Jeff thanks for coming and then we'll we'll share our links as well as I think anyone that's trying to move into product thinking from project management like you all need to take
Jeff's course thanks Jeff for hanging with us thanks much
