User Story Mapping: Developing a Shared Understanding

[Music] my name is jamie windsor i'm a team builder a designer an engineer and i'm also a founder of a company called one more game along with a really good friend of mine patrick wyatt uh one more game is an independent seattle-based studio uh we're currently self-funded um we started this about uh in early february um so we haven't been at it very long but uh pat and i have been making games on and off together for about a decade now and although we haven't made an announcement we have a website that's public you can check that out but we've been pretty quiet so far but why i'm here today is to present a framework or a tool or a process that's the center of our incremental and iterative development process i didn't always develop this way

i thought i did by the way but it turns out that i wasn't being as iterative as i thought i was so let me give you uh some background about a problem i had which led me to the solution that i'm going to be sharing with you today so i worked on a game for about two years that we pushed into early access it was called moonrise it was a mobile game but also on the pc mac os and it was one of the first experiences that i had where i could play a game at work get on the bus play it on the bus get home play it at home do the same thing the next day on the way to work and then play it at work i love this game we worked on it like i said for about two years and at its core i knew it was something that was really fun but obviously we had to make some changes

because it wasn't landing the way that we thought it would land with our players this was after about two years of development so we continued to work on the next big release we prioritized a bunch of features and as we developed them and released them we started to realize we were prioritizing things the wrong way or the players that we had they weren't really accepting the things that we were developing we were building something off of a design dock or something that we thought we needed to build but as we released them they were just not landing with people that we thought the way that we thought they would eventually we had to cancel the project to work on something else that we had in the pipe but that experience really stuck with me how did we get there we were building something that i personally loved and i was sure people were really going to enjoy and my co-workers felt that way as well and this was a team that i never worked with anyone better than this before it was only after the project shuttered that we started to talk about what went

wrong we started having conversations about it pretty much daily um and we all wanted to figure out at the root of the problem so that we didn't repeat that again so i know this is a red flag today to wait that long to start talking about where something went wrong i mean i knew it back then i just i kind of was in my formative years of my career and i instead opted to listen to the people around me that were more experienced and when we got together in groups and we started talking together about the problems we started realizing that people had different ideas of what we were building on the surface they all understood we were building this mobile creature battler but then you start to get into more details and like for instance i might think this is a competitive game and then some other players might think developers may think this was more of a story based game or was more of a casual game and then you start thinking well our audience seems to be everyone

so let me take digress for a quick second who here has heard of the broken telephone game or played this when they were a kid right most of the audience so for folks that don't know um the telephone game is when someone starts a conversation and whispers it into another person's ear and then that person says it to the next person and so on and so on and eventually you get to the last person and like this picture shows the first person said peas and the last person thought they said fleas turns out this game isn't just a someone we played in the school yard it's also an important learning experience about how conversation works when you encode a message into someone else they decode it sent to the next person and it's lawful like as if i saved an image many times over right you end up with something like this this is cake rex if you guys have never seen this before i'm probably completely late to the party on this by the way but this is when somebody calls a cake

shop says what they want and then the person encodes it into a message hands it off to the artist that's putting the cake together builds it and then you end up with something like this best wishes suzanne underneath that we will miss you well clearly they meant that but not exactly like that or this one happy birthday just happy birthday right it's a perfect explanation right so if i have an idea in my head and i describe it in writing when you read it you might possibly imagine something completely different but when i ask you you'll say oh no i agree so for my team working on moonrise we basically knew what we were building because we were reading off the same document i felt we had a good grasp of what we were building everyone's the hero of their own story so of course the game that i thought we were building was the game that we were building and we were effective at building this thing it's coming out so i didn't

understand that there was a problem uh and it wasn't that someone was wrong it was that we weren't alliant and we thought we were that's the biggest problem this is because written instructions can be surprisingly hard to internalize and execute upon shared documents are not shared understanding they're simply a shared document that everyone can read from if you read from that document i could even ask you do you agree with me with what's written here and you may say yes we all agree however if we get together and talk one-on-one or in a group if we use pictures images any visual representation where we can move things along and we can start map out each other's ideas we may realize we are on completely different pages so if you look at this picture right here you'll see a group of people oh i'm glad we all agree they'll agree that we're working on a shape but then when you draw it out you realize oh i'm building a square you're building a circle and you're building a

triangle getting together and talking about it and visualizing those things will actually get people on the same page and you may feel like this was an exercise that cost a lot of time and money because meetings are expensive but in the end it it sucked that we weren't on the same page but it's better now that we are on the same page and we are sure moving forward so from this experience working on moonrise i realized that all encompassing dev bible was basically an artifact of waterfall development we all said we were building an agile methodology but we were only doing it in name pretty much um yeah we took certain processes from the agile manifesto or from things that came after that but in the end we were completely misaligned and we just weren't prioritizing the things that we really needed to prioritize and the more we detailed in that document and the t the bigger the team that got the bigger the team got um the worse the

problem would become so it's because of this that i like to think of design documents instead like photographs or vacation photos instead of writing an 80 page design doc write something that defines a story that you can then tell everyone else so if i show you this picture you just see a picture of two people you might recognize that i'm one of them because i don't have sleeves on right um and it's a lifestyle choice okay uh so uh this is my girlfriend wunder and i and we're at the top of a pretty big mountain in washington i'm from seattle uh i live there now and this was a day uh a long day after riding dirt bikes and she's never ridden dirt bikes for the first time and uh she agreed to do it even though it's not her thing and the dirt bike was too big for her and i don't know how she was able to do it falling off getting back on going up trails that i thought were difficult um and you know as i look at this picture i can

tell you this whole story i can tell you that earlier in the day my friend almost flipped a 4x4 in in in the parking lot and then wasn't allowed to drive a motorcycle that day i can also tell you that my birthday almost got canceled because we showed up and none of the motorcycles worked so we had a florida river that day right anyway the point of this is to tell you that a picture exists so that way you can remember the things that happened around it and i think that's the way that your documents should work you shouldn't try to encode all of your intent especially if you're developing something that might come out in two to four years what you really want to do is just have an open framework with the ideals of what you're trying to accomplish that everyone can get around and talk about and have conversations about so they remember why they're building it you also want to design with now in mind so if we're not writing design documents which exist out for four years or so think about the first three months or the next three months i should say

live now and not later um the more you try to predict in the future the more you're probably going to be wrong um if you're trying to land a rocket on mars you know there's a lot of conditions that need to happen before that that lands um it's an extremely difficult task you don't need to be the most skilled developer or producer or engineer or artist to be able to just predict the next third three months the longer you predict predict out the more difficult it becomes so i like to use something called the now and later model what i like to do is think of the world as it exists today and who are the people in that world and what are their problems ultimately your job is to change the world i even stutter as i say it because it's pretty lofty to think about we're game developers we make things that are fun we don't make toys we make games but still the idea that you're changing the world

should sit in you are you make something for the people today with the problems they have today you have ideas about how you can solve those problems you output a solution into a release and then you look at the outcome did i deliver on the intent that i meant to do did i make the player feel the way that i made wanted them to feel did i deliver the experience that i set out to change if you recall i told you more about my experience playing at work getting on a bus and getting to work that could be any game that at the time was a thing i had never touched before so it really imprinted on me and it was a thing i really wanted to accomplish with this game if you go through this process you might realize that there's all kinds of products you could build all kinds of features you could build all kinds of enhancements and together as a group you'll end up ideating and figuring out what those are so starting from that point i encode these ideas into something called a

product framing doc the product framing doc is existing to answer these five questions the why which is the background required to explain the rationality initiative this might include market conditions the competitive landscape historical context the proposal this thing frames the scope of the initiative at a high level uh it's important that it's at a high level it provides enough detail though that it's clear what the initiative seeks to achieve for the player and then players these are the people you're building it for and i like to make sure that we have two sets of groups one is the beachhead or the early adopters because they have different behaviors than your later adopters or your normal players you may be going for the normal the larger market but you need to pay attention to who's going to play in the beginning first if you don't get early adoption you don't get later adoption right makes sense

the next is outcomes why are we doing this what is the point of putting any of this work in um and the last is metrics which is a pro uh ways to prove that i achieve the outcome that i meant to and they must be measurable they can't be vague they have to be actual numbers that you might put up on a dashboard somewhere some way to communicate with everyone else to say hey we actually accomplished what we've set out to accomplish you can do this any way you like but i like to use something called an opportunity canvas for this an opportunity canvas will act as a center point for all the conversations that we're about to have in the technique that i'm going to show you later i bring an opportunity canvas to a user story mapping session it's how i align people around who we're building for and what we're building and also align people around what our businesses goals are this is an exercise that could be a talk all of its own but i'll talk really really quickly

about why i use it to frame my conversations so i know this looks like a mess at first if you've never seen it the numbers represent the order in which you would do things so you start in the center and then you go to box two each one of those boxes this is probably difficult to read by the way you can get this off of jeff patton's website if you just search for opportunity canvas on google it'll come up don't do it right now please um so uh uh the important part of this is it looks like chaos because it's not for encoding it's for decoding when you go through and read it later you can read it left to right and left represents the state of the world today and write represents the state of the world later the now and later model the top represents users while the bottom represents the business so in the upper left i can talk about the state of the world for our players whereas in the bottom left i can talk about the state of the world for our business like i said you don't need to use this exact thing i recommend it but the most important

thing is regardless of how you come up with your product framing dock that it's uh flexible requirements are a really hard word they're absolute and people will take them as a must-have and really what a requirement is is just ideas that you have about how to change the world again really lofty but that's it we often built things in moonrise because they were requirements setting down to us and we would build them in the order that we were told to build them in sometimes by our publisher or sometimes because even experienced people i was experienced enough on my own to say you know i need to build this next but did we really need to build chat right then i'm not sure so you have your product framing doc the next thing that you want to do is get together as a group and tell a story to each other when you do this you'll find out that one you're going to get a bunch of

buy-in from people because they're going to interact they're going to collaborate unlike this room right now where i'm broadcasting to you if we sat down in a circle we could share ideas and when you share ideas you can get people really excited about what you're building if we do x we'll get x and you get a diverse group of people together you want that because you have blind spots um so you know if i had a grand vision um i'm gonna be wrong simply because i'm only a 30 for 34 year old tall white male who likes played quake in the back in the day and then world of warcraft right i'm i'm probably going to keep trying to build the same thing unless i had people around me that could fill in those blind spots so when you get together and tell a story you also ensure that people know that story and they can share it with others on the team so this is the lead that i've buried you're here to hear about user story mapping which is how you tell that story

this is a tool that i picked up from a guy named adam jacob who's the cto of a company called chef software he's a great friend of mine and also a huge influence i took a break from games for a short period because i wanted to know what went wrong on that product that i built i didn't think i was gonna get it at the place that i was at so i left games for a short period of time about three years to go work in enterprise software a startup that builds enterprise software so i could go sit in larger enterprises to figure out how you solve problems for people that big from that i met jeff patton who wrote this book and this framework was given to me as a way to align my team building a next generation piece of software for that company it changed the way that i collaborated with a team and it changed the way that i thought about solving problems so i'm going to give you guys a mock version of this that you can bring home and try out with your teams it's uh an exercise that'll only take

about an hour um you'll only need a couple things so first is you need an idea for a product feature or enhancement um in this section i'm gonna give you a fake one which is a morning routine you need a white board uh you need some markers and sticky notes a timer and a group of engaged minds people that have an open mind about trying new things out don't bring this to somebody that's process process averse for example not at first so we're going to build a product frame um sorry we're going to build a user story map around the product frame of building a morning routine i choose this because it's something everyone knows how to do and everyone kind of does it differently which helps illustrate a point so the first part is an initial brainstorm grab everyone put them in the room hand out sticky notes hand out markers ideally they're different colors so that way people know who wrote what ask your participants to

write the activities that they have from when they wake up all the way until they get to their desk at work whatever detail they like one activity per sticky note and then set a timer for five minutes when anyone's done writing on all the sticky notes they put the marker down and they just hang out for a little bit when the timer's up ask people to put down their markers if they haven't and then use a system called fist to five fist to five is where you raise your hand and then together you reveal a five a one or any number in between a five is i'm good a one means i need more time and then you kind of look at the room and gain a consensus okay we need some more time set the timer again if not everyone's a five keep going and do it as long as the group needs um if there's one person that's holding a one and they're keep doing it just ask them do we really need more time and and then keep on going if the answer's yes um but we use this so that way one

voice in the room doesn't plow through everyone else like if you do this with your ceo you might look at him and he's like no i'm good and then everyone's like oh we're good too so that's why we use this system all right so once you have all the stickies written each represented activity have one person go up to the board and put each sticky note up in chronological order in a horizontal line as they do it have them read to the room and tell the story about what their morning routine is have the second person go up and again chronologically and they put it in their order they don't have to do the same order that the other person said and then below that and then below that and then as soon as they're done you'll have something that looks like this i know this is extremely difficult to read um so here's a zoomed in version and all right i think i think some people can probably read this one um if not the top line is one person um they hit snooze like three times before they get

up they they take a shower they brush their teeth they put on some deodorant the person below them probably represents someone that has a family or they're married they wake up to feed a baby and then they wake their husband up and the person below that is someone that's probably more concerned about their health they're cooking breakfast they're going to the gym and this is a zoomed in next chronological order where uh the person on top um just uh kind of goes to the bus you know they this is clearly a bachelor that's my routine probably um the person below them is you know taking a little bit more time and then below that they're working more in the gym and this is the end the point of this was there's a beginning a middle and an end of every story and you want to make sure that that's representative from each one of the people writing sticky notes so there's going to be shared tasks between them between the three authors and they're also going to be wildly different potentially but reasonable

morning routines the next step is as a moderator it's your job to facilitate formation of something called the backbone of the story and the backbone is just umbrellas of like tasks or things that could be reasoned about being of the same shape in a real user story map this would be like i log into a web page or something like that right and then we would maybe say all of login and that represents a bone here i've created a couple topics for this mock story map where you have hygiene self-care and you wake up there's dressing breakfast in the gym transportation arrival it's important while you generate these to communicate with the group as well make sure that everyone agrees that it makes sense to group these things underneath a particular backbone it's much easier when you're doing the morning routine than it is for other

features so this is what the board would look like after applying the backbone again this might be a little bit difficult to read but it's not important what is most important is that you can still see the chronological order you can see the grouping and it's important to note that the person that goes first typically always has uh the chronic the truth of the chronological order and that's not really that important at this time um so if somebody else eats breakfast uh before they brush their teeth or afterwards they're just gonna wait a second and things will smooth out the next step is to order these by urgency so now that things are in chronological story order we then order things from top to bottom for how important they are to how not important they are and if we do that you see it like this so through each of these exercises it's okay for the whole group to get up and arrange the stickies themselves

they can move their own sticky notes they can move other people's sticky notes and facilitate a conversation around it as well so let people negotiate what they think should happen next or what is most important and then this is it zoomed in so these are now chronologically ordered left or right and importance top to bottom so it's no surprise there might be some discussion about what's more important in one of these columns it says that you have to feed a baby and then there's another task that says you have to drink coffee and like your teammates might have not enough empathy to understand why one of those is more important than the other but there's a conversation negotiation that you have there but this leads to the next fun part which is when as the moderator you tell the groom that they're late for work and they only have 15 minutes to make this happen so you're going to put a constraint on them and say draw a line below every sticky note and

then you have people go to the board and move below that stick below that line everything they don't believe is extremely important that they could get done within the 15 minute time and what you'll end up with is a board that looks like this um let them spend as much time negotiating and speaking with each other negotiating moving cards um it's important to remind people it's perfectly acceptable to disagree and that conflict is productive and it's not bad a lot of humans are uh really resistant to conflict and really all they are is a negotiation and you figuring out together what's most important this is a really good time to focus on that if you're working with a team that has typically been conflict averse or aggressive with each other it's most important to point out that conflict that's respectful is productive and conflict that's not respectful is completely not productive so everything above that line is going to form your first release

a release isn't something that you always give to a player or to show it to your ceo or show it to your producer or show it to your investor it's just something that gets the point across of what that initial outcome was that you were trying to deliver everything above the line is that release and everything below is something that we care about but it's something that we'll probably do later so prioritizing this way is difficult because everyone has an idea about what's required that's slightly different and that's because those people in the room that i ask you to gather are diverse you may have younger people you may have older people married people people with families people with cars people without cars and the most important thing is that you group you generate some personas personas are just who's going to be using your product in this case who's going to be having a morning routine so with our new goal of get ready in 15 minutes we're going to determine that we

have bachelors we have married people people with kids coffee drinkers physical fit types breakfast lovers and people with cars this may look different um i'm sorry this will completely look different if you're building um a real product but this should get the the point across another problem here is prioritization around this so now we have these personas in these groups who's most important so um the old saying goes if you try to please everyone you end up pleasing no one i just gonna tell you that guile said that because uh uh apparently everyone on the internet has said this if you search for that like everyone's been attributed to saying this uh it's better to declare complete bankruptcy than to attribute it to somebody that did not actually say it uh so at this stage uh encourage the group to optimize for early adopters or beachhead users uh it's just easiest for this mock setup but that might not be always what you want to do for a real user story map

you may have business constraints that say that you must focus on particular players and then you'll have to work back from there but for now early adopters and this is a good point a good part to remind people it is okay to disagree um and it's especially gonna be difficult to align people because you're working with smart passionate people what is not okay to do is disagree and not commit but it is very okay to disagree and commit on a team you have to work together no matter what even if you do not think that the thing that you're doing right now is the most important once you walk out of the user story map everyone needs to commit to this idea and understand it's their idea as well and they need to be productive in explaining to everyone anyone else that asks what they're building that this is what they're building through these negotiations i like to use something called the ten scale which is a way to help people understand how important your idea is to you so uh

ten out of ten i'm ready to die on this hill right so i think that we should do it this way and there's no other way one out of ten i have an idea that i can give you but i don't mind and somewhere in the middle is i can go either way all right so now that we've grouped the personas and we've talked about what's most important we think about who those early adopters are the easiest people to build this morning routine for is people who are bachelors and people who have cars um the people to the right aren't people we don't care about they're just that other group that that later group as our product gets more fleshed out then we can start focusing and building for them so after you've done this ask the group to go back up to the board and mark every activity with some sort of color marker here i used a website called mural and there's these icons that you can see

or i'll show you zoomed in in a second here and then if it's table stakes it's up to you to mark it or not table stakes is the most bare minimum by the way so you need to wake up in the morning to be able to go to work so we know that has to be there and that's for everyone but if we look zoomed in these are tasks that are important but we've assigned to them personas um so the bottle would be someone with a baby the ring would be sewn with a marriage and we care about these people we just can't care about them right now because guile told you you can't right um so now if we take a look at the first milestone we'll see a pretty bare-bones morning routine you have to wake up you take care of your medicine you brush your teeth uh take a shower or no actually this one you just put deodorant on it's even it's even easier to get ready for your morning um you get to work get to your desk but this is

extremely bare bones and like i said this is just the first release everything below that line this is what we would probably do later so this is usually as far as the mock user story session goes typically this will take about an hour depending on how many people you have in the room um this isn't the end of a real user story map though um so i'll talk just a little bit more about how i continue to get value from this and what the next steps are if you were to use this in a life scenario so from here you're going to have a list of activities and they're going to be prioritized if i go back to the moonrise case we may had worked for three months and our initial uh uh you know slice maybe is a login uh or not you know maybe maybe there's no back-end system in any way you you get to a menu system you start fighting that's slice one um and out of those features what we

might do is uh identify ones that are particularly large and then we might break those up into smaller pieces um this is by the way particularly great to watch cross-discipline that's another reason why i highly recommend that you get people you know your artists in there audio engineers programmers producers grab everyone that's interested um not too big of a group by the way because past 10 is crazy but grab them put them in a room and have them start breaking things up and what you'll realize is that an engineer might have overestimated or underestimated something because they didn't realize that they they appear somewhere different in the pipeline than their peers do and potentially there's dependencies that weren't known so as you break these up you start assigning work to each other and estimating how long it takes so this is a thing that normally you need done anyway if you're tracking work of any kind you already do this maybe you don't estimate

maybe you do you can leave that off as well if you're not looking into it interested it but i think this is neat how the conversation that we were having directly also translate into an artifact that helps me track our progress um and then a conversation every activity every one of these cards is a conversation that i can have with the person it's assigned to or we can look at it and then as a group remember the story we were telling each other you know walk up to a physical board and say oh this is where we are right now and have a conversation around that ticket so with that time constraint that we placed on people the 15 minutes what we ended up trying to do here was looking at the state of the world understanding an idea we wanted to get to work on time and through minimizing the amount of output doing the least work amount of work possible how we could have the outcome that we wanted and then we looked at how to maximize our impact impact is the people that you change the

world for in this case it's small we looked at bachelors and people that have vehicles in the next release potentially we could pull in some more features and have a larger impact but the key here is to deliver outcomes and ignore output a lot of times we measure output like velocity or burn down charts and i just don't understand if it's an anti-pattern what you really want to do is measure if you made the impact and the out it had the outcome that you desired out comes a special word it literally means what happens when it comes out and output is just what you did to get it there outcomes are difficult to measure though because a lot of times you can only measure them when it comes out and that's why it's important to build less that's minimizing output if your slices are smaller you can deliver faster

you can then measure your outcome sooner so in the case of moonrise we might have figured out before two years that what we were building wasn't resonating with the people we thought it was going to be resonating with if instead we had delivered been delivering much more rapidly maybe not to a complete audience but to use your research groups um and more regularly um we might have figured out that we were just not building the things that our players wanted um this is why that metrics point is so important on your product framing doc you already predefined that in the contract that everyone agrees upon we want to do this thing we want to have this outcome and this is how we're going to measure it it's all part of the framework and that's again why i like to use an opportunity canvas because it presents a wall in your office that you can take anyone to and walk them up to it and say this is what our vision is at a high level another thing about building less is

there's always more to build than you have time or resources for um there's countless numbers of features that you could build countless number of enhancements that you can come up with um and there's a lot of different types of players so you could try to build something that satisfies everyone and it's just a you know a billion dollar game but more money and more people don't equal a great product what we're attempting to do with this incremental approach is deliver something i like to call a minimum viable solution a lot of people in this room probably have heard of a minimum viable product the reason i don't like to use product is because the idea that you're going to deliver in a completed product means that there's room for somebody to say it's just not good enough yet a minimum viable solution focuses on the literal minimum amount of work that we can do to achieve the outcome that we

said we wanted for the people that we said we wanted to deliver it to so in this iterative approach what you want to do is make things useful from the start and better at each stage so you can see that the story had a beginning middle and end of our user story map it was small it was short and granted i didn't even take a shower in it right um but you could do it it accomplished the outcome you got to work under the constraint i like to use this diagram um by the way i didn't make these this is from jeff patton this is part of the book and these are just these resonate extremely well with me so in this scenario you were set out to to build a car um and uh if you look at the top people built it in pieces uh complete pieces the wheel first and the axle and the

wheels and then the car and then the hood and the car and the first three stages the person wasn't happy but if you look at the bottom this person thought about the outcome which was i need transportation to get somewhere now a skateboard might not be unbelievably useful to somebody if they have to go on a highway like you can't skate on a highway right a scooter might be more useful for somebody if they have maybe a mile or two mile long trip and then slowly you iterate to the bicycle the motorcycle and then the car and the point here is that at any moment you can release and see if it accomplishes your goals you also might realize that you never needed to build the car you thought everyone wanted the car and then you deliver something and really all you ever needed to do was build a bicycle so you don't waste you you create less waste by following this methodology in each one of these releases each one

of these milestones treat it like an experiment do the least amount of work that you can have the metrics ready to measure the outcome and then try to learn from that release i'm sure some of you here have seen this diagram before this is the validated learning loop so you you build your minimum viable solution you measure that minimum viable solution against a group of people maybe it's external maybe it's internal maybe it's your qa folks maybe it's friends and family then you take that data and you learn from it you look at it and say are we still doing what we should be doing avoid a flat backlog don't let somebody tell you here's what we're doing for four years because i guarantee you after you if if you have a release of uh and it takes you three months to get it out you're gonna learn so much from that that the ideas that you had three months ago are no longer good or only some of them are or they're still good but they're not good for right now

that's why all of these documents are mutable you can change any one of them even the product framing dock even the opportunity canvas you can just burn it make a new one because you learned from your from outputting and measuring the outcome so using user story mapping you'll end up building with an incremental strategy this was a strategy that i was looking for when i was building moonrise i wanted to know why my product was failing much earlier or i wanted to know that it would fail so that way i could prevent it from happening had i known uh that it was going to fail we wouldn't have run out of runway we would have iterated and pivoted and worked on different features this solution this tool this framework to get people together was exactly what i was looking for one of the reasons i really appreciated it was there's an actual book that you can you can give to people about this

you can you can get on a stage and tell people about it and tell them to go read about it um we could go out in the hall after this and anyone here could come up with a feature and we'll do a user story mapping session about it it's really easy to get to do so building software especially entertainment software is a big task it takes a lot of time sometimes two to four years you could theoretically be waiting quite a while before you can measure an outcome it's because of this that you shouldn't aim to complete things step by step or complete things in a way that a gif would load in you know the mid 90s um instead think of how van gogh made the mona lisa he set out to have an outcome of painting a picture of of a lady a fine lady right and um he sketches it quick uh fills it in and the whole way you can kinda see the picture and because of this it's also a place that people can gather around imagine

this like a game um you know you don't have the entire thing in place there's a bunch of debug text or you know the ui is not right or you know you're using other games artwork temporarily whatever it is but you can still see the vague picture of what's going to exist in the end i guarantee you if you do it this way you'll have less waste so if i've bored you through this or if you're scrubbing through at home i hope you hear just this part in these next couple slides um the reason i continue to story map is like i said it has a book and i can teach it to people um but it resonated well with me because it's around building teams and it's around aligning under a same goal it becomes let's build our game and not let me build your game it also makes sure that you produce less waste you just simply build less when you use a method like this and because as a framework everyone can agree upon

it there's no thought about what you should do next one the first the most important thing that it does for me is it tells me exactly what i should build first you basically pick out what the table stakes things are who the people are who are you building it for what do they expect and then what you should build next it also gives you a space like codified into your culture about bringing alternate points of view so instead of the programmers all getting together and and solving a problem in a way that programmers would i can say that by the way because i'm a programmer you pull in other folks and hear how they would solve it you start understanding what their problems are and then you start empathizing with those people as well and it makes you more inclined to want to help them and have less arguments about who's right or what vision is appropriate if you fill in the blind spots that you have if you bring in other ideas the third is that buy-in i had said this

a couple times we're building our game i'm not building your game nobody wants to just build your game um people want to feel like they have purpose in the workplace and your product will have more soul if there's more ideas in it this wasn't part of this talk but i actually want to give a small analogy about why diverse minds are really important in a room so apple designed a glass staircase and they put it in one of their stores um it was summertime and they were wondering why the second floor just wasn't getting used or why particular demographics were not going and buying things on the second floor um what they found out through polling people is that they put a glass staircase in in summer in a place that gets warm and then women didn't want to use it because they walk up a glass staircase and there's people standing under it potentially or kids standing

down there right that was an idea that a a a particular set of minds had and yeah it's cool but if other people with other ideas were in that room they would have probably never had that problem that is a very visual representation of something i keep seeing when we're building games and only certain minds are in the room the last thing and this is pretty much the title of talk is that i keep using user story mapping because it helps me build a shared understanding with people this takes time and it could be someone's sole job to make sure that everyone every day understands what we're building but it's better than finding out two years into the development process that everyone looks like they understand what they're building that's more dangerous than not knowing because if you don't know it's a lot easier to correct you but making this part of your process codified in means that i guarantee you in two years you're not going to ask

people hey what are we building and they all have different ideas about who they're building it for and what they're building if you get nothing else from this talk understand that stories aren't a written form of requirements this is in a way that you now describe to people what they must do and stories aren't the requirements these are just conversations that we can tell each other in chronological order in a way that we can arrange them visually in a place that we can go have conversations about each task or activity stories encourage those conversations those interactions and questions which lead to better understanding a map is literally ju how you figure out let me do this one more time how you build a map is by finding the edges and that is the same way as solving complicated problems find all of the edges agree upon the edges and then let people fill that space with the solutions so here's some resources if you want to

do this on your own mural.co is the tool that i use to generate those slides with the sticky notes on them i've worked on remote teams before and i've used that quite a bit in lieu of a physical place that we could get in a room i do highly recommend getting in a room though there's three levels of communication that i escalate through one text is it quick is it not going to hurt your feelings i'll send you a quick message two voice um can i convey that i'm not a being a bad guy by giving this information over video uh of voice and then the third is video or in person and that's when you're really going to have potentially conversations that have conflict anyway the next is jeff patton associates that's his website literally i wouldn't be up here talking about this if jeff patton had hadn't uh come up with these ideas written about them come and presented to them um so

i have a lot of thanks to deliver to him and adam jacob and the other developers that i worked with at chef so again i'm jamie windsor you can see me on twitter there and that's my email i really appreciate everyone coming and thank you to the av team here and the staff helping me out hope you guys have a great rest your day but before i let you go we got 10 minutes left first i'd really like to ask you guys to and gals to please rate the talk if you can negative feedback positive feedback it doesn't matter it's very useful for us and next if anyone has any questions we can do a q a [Applause] hey how's it going great talk um thank

you can you do me a favor and just say who you are and where you're from and oh yeah sure my name is james i'm at adobe and we uh you talked about the diverse people in the room and the example of how everyone gets ready for work is great because everyone has a very similar experience like that but when you're talking about like a product feature or product in general you know you're bringing engineers you're bringing designers you bring whomever that might be in there how do you balance out the you know the product requirements and you being the product person and knowing that there's a vision based on your expertise and user understanding versus what an engineer is going to bring and how do you kind of include them in those talks but at the same time keeping it focused on what you know to be the direction and path you want the product to go in absolutely um okay so because that's recorded i'm not going to repeat the whole thing back but the idea is how do you align other people with a vision instead of letting it kind of get off the rails right okay so

that product framing dock or an opportunity canvas acts as a contract just be welcoming to people and say hey this is the problem we're trying to solve people love solving problems i think that's why people play games by the way literally games are just problems that you're solving right it's the difference between a game and a toy and uh engineers really like solving problems too so if you show them the state of the world and say how can we fix this and this is the outcome that i want you'll just it's going to happen it's very rare you have to have a very particular cynical type of person who's like that data i completely disagree oh sorry again two those are my those are my helmets um yeah so uh aligning people around the problem and getting them uh excited to go do it often will just kind of cut it off at the head but it's true that games are subjective and that is where you i use that 10 scale quite a bit like look we all have to be reasonable here

um we i hear you like it blue we're going to go with red for a little while always try to have metrics though that you can fall back on cool thank you yeah no problem thank you um i'm alfreda from wizards of the coast um i'm just curious how you either modify this for larger teams or figure out who like the most important 10 people are to be in the room because you said a limit of 10. yes that's a great question so i like to limit these to about 10 to 12 people and uh it's kind of hierarchical so uh not hierarchy like how important you are or what your title is it's just um uh people that are excited or interested people that have free time right now people that agree to the team contract that want to form a core team around a a core team around that that vision they want to deliver those outcomes

and then slowly um break it out even more so that was one board and it was like hard to fit that on a slide um what you're going to end up with is a is all of your walls are going to be covered in this if you really adopted it and you have teams break off and build features and then you you kind of just set a larger hierarchy and someone's a product owner um or a producer or or product manager a product line manager and it's that person's job to make sure that communications flowing between each team but the core group say you were building a brand new product right now limit it to 10 and then as you're doing the rock breaking process start realizing there's epic tasks that you can then give to other teams and then form another 10-person team around it and say this is the problem that we're trying to solve for this are you guys ready for this and gals are you ready for this and if they are they'll get excited and they'll start doing that as well anything more than 10 is chaos

in my experience thank you no problem further adjustment hi annie vandermeer minnesota uh system era i'm as you know it's an unfortunate truth of our industry that there's a lot of turnover uh how would you adapt this methodology when uh there's been turnover and you're trying to bring on a new person and an onboarding process especially somebody who might be uh in a higher sort of level like a lead has been replaced yeah that's tough um but uh if everyone has the story and everyone knows how to and it's lofty to think everyone will by the way you you can't have only one person holding that vision and being more near the center or as you go out in a layered approach you can't have just one person being able to carry the torch at that layer but um i don't find that or it's not been it's not it has not been my experience that i've lost one person and

then the entire project uh could it couldn't be completed um and it's mostly been better because it's more distributed in this way um one of the things that it has helped for onboarding with no one goes and reads an art a wiki article that was written two years ago which is completely out of date now and then has a different idea of what we're building instead they can look at that photo you know that small thing and then they have a bunch of questions about it and then they get the more up-to-date information by chatting with uh people in the in the room is that satisfactory is that okay that is totally okay all right hi jamie thanks for the talk i'm nicole from zynga um you i like your reference of design documents or like photographs so after this process is concluded what do you recommend teams actually do document so i would use the product frame or an opportunity canvas as that photo

the most important things like i said at the kernel or what you want your outcomes to be why you're doing it who the people are and the metrics to measure it but from there you're going to be creating entertainment software right and then small slices about describing that feature and again you can you can product frame features you don't have to just product frame the product you could then go along and say okay this is this particular system like uh um we're building a a card game and and i'm trying to figure out a particular mechanism and you know for cards uh you know how we deal or how we manage with resources um and uh you can have a smaller version of that uh for for just that feature team okay thank you absolutely [Music] hi um my name's kyle i'm from codemasters and um i'm currently trying to work out how i word this question

without sounding like a crazy person um so in in the example that you gave you are highlighting commonalities uh in the backbone do you also go through a process of if there are say users that have diametrically opposed opinions or ideas do you highlight conflicts as well and then if you do what do you then do with it yes absolutely um that does happen especially more when you're building entertainment software right those are must-have conversations and then uh it's really important that there's another party present who isn't one of the people with that idea so as a moderator you shouldn't take a side um hear each side out and then as a group let the group try to figure out what they should commit on if you as a moderator know that the thing being suggested is going to be a tire fire you should then be like hey i'm 10 out of 10 on this man like i really don't think we should do this

is it okay if we don't do it right now and by appealing to that person who has the completely opposing idea a lot of times they're pretty reasonable as long as you're in person if you do this over text it ain't happening yeah okay thank you absolutely hi i'm andy martin with moonlight games i i get in meetings all the time with kind of our executive staff where the meeting sort of ends and i understand or i completely agree and instead of really meaning i completely agree it's just kind of a way to table the topic yeah do you have any ideas of how to solve those types of problems yeah don't put people in meeting jail um make sure meetings only last a certain amount of time i use 25 minutes and 55 minutes because i like to give people five minutes in between to go to the restroom or or i just need time sometimes to sit there

and think of nothing but don't keep people in a room much past that because they will tap out and then you'll only have the ideas of them the the most uh the people with the longest endurance for putting up with meetings you know um so do use a story mapping session if you don't complete it it's okay it's all on a board come back the next day and uh keep checking with people you know check in with them ask them if they like it don't do it in front of everyone else but pull them aside say are you finding value in this and uh again if if they're not but you're a nice guy a lot of times people will um there's a social currency that goes with you say can you give me a little bit more time but don't let yourself get burnt out in a meeting and make a policy that if you're not finding value in it you can just walk out cool all right i think that's it um that's

time as well thank you everyone for coming i really appreciate it