 2000 that I first got my exposure to these things and it was well in 2001 the term agile was coined and I've been using them since the since they were a thing and I want to tell you it's gone horribly sideways the people don't use them quite right so I want to bust down to some basics and as as always if you've seen me present before I've got too much to present so I'll edit a little bit on the fly because I'd very much like you guys to get the get some practice creating a story map so I'm gonna favor doing versus versus just talking now a few people have asked me I've got a workshop running on on Friday and Saturday and if you're in that workshop yes everything I say here I will repeat Thursday and Friday so I've told a couple people that I don't come to this because if you're in that workshop you're gonna get it already I'm gonna do this in a little bit of a weird style because I want to control my deck and there may be times I want to draw a picture here so I've got this desktop thing to do that let's break this down we've got three parts to this I want to talk about what stories are and art and why they're such a simple thing and why such a simple thing can be so complicated I want to talk about what a story map is because that's the way I like to work with stories and we might be blending a little bit of two and three because maybe the best way to learn about a story map is for you guys to create one and we'll have to go through the process to create it so let's start from the beginning here did anybody read that Dilbert cartoon while I didn't have a slide up so you could read it but the if you look at the URL on that the date is 2003 I believe January of 2003 which means the authors or Scott Adams Scott Adams okay yeah get my hitchhiker's guide Adams and this as I transpose those it means it you know he knew in 2002 what these things were the story thing is not a new idea it's a fairly old idea and the the story thing came from this guy Kent Beck Kent in the late 90s was looking at at process and was looking for things that were going wrong so if you treated the process that you work with like a product the thing that you're making and you want your process to work better you look for problems or things you can fix and one of the things he latched on to is the way we transfer information to each other the way we write things down as requirements and hand them over to each other now there are a number of problems with that but one of the bigger problems is it well it just doesn't work I have to show you some examples of how written instructions don't work these are silly and they may not completely translate well these are examples there's a blog out there and if you want to waste a lot of your time go visit a blog called cake wrecks and there's a lot of it's it's silly if there's a lot of oddly decorated cakes but one of the underlying themes is misinterpreted instructions now if you see a few of you smiling so you can tell you tell how those instructions were misinterpreted obviously underneath was misspelled wrong but they've just written exactly what was there sometimes people just don't pay attention and just really aren't following the instructions this one's a little bit tougher to detect you see the problem there where the decorator went wrong anybody got it the stuff on the right side is telling you how the left side should have been done now you might think we could solve this problem by doing documents electronically pop perhaps it's handwriting and other things more specification so we might put those documents on a USB drive and hand those to the cake decorator who will then go to work decorating the cake this is a cake decorator that didn't look at the document but duplicated the USB drive on the cake there's just straight up reading the words and not paying attention there's the misinterpretation of non-functional requirements I don't know if that's going to kill me if I have a nuts allergy or not and then just not paying attention now these are funny but this is a fairly old story I just isn't India working on sending out an orbiter in Mars and that's trying to go on right now is that correct so there's a lesson to be learned here this is when the United States did it and the United States created a Mars orbiter and before I don't know what the to look up exactly how many millions of dollars were spent on this thing the thing headed off to Mars and just when it came time to to enter and start orbiting Mars and instead it crashed directly into Mars there was apparently some software written by ground crews and one group of people writing software were using the metric system and another group of people were using the imperial system and it'd been well documented but well somewhere it got lost in translation and that kind of mistake cost a lot so that's not so funny now Kent's idea was simple now one of the things that's happened is the original idea has sort of gotten lost in translation over the last decade so I had to have a little bit of a conversation with Kent back and forth and just pulling this out of my email I said Kent where did you get this idea and he said you know what I was thinking of was the way users can sometimes tell stories about the cool new things that their software does for instance I type in the zip code and it automatically fills in the city and state without me having to touch a button I think that was the example that triggered the idea if you can tell stories about what the software does and generate energy and interest and vision in your listeners mind then why not tell stories stories are called stories because they're meant to be told if I had a I'm tired of the question how do I write good stories because the point is the reason they're named this is they're supposed to be told and it's it's not a way to write better requirements because the the fundamental principle here is that the way we write them doesn't work so the idea was simple first off I've got to organize a lot of things that I want and I need to basically just write what I want on a card doesn't matter what you write on a car just write some stuff on a card and then I get together with somebody who can build something and we have a conversation it's through that conversation that we tell our story that the person building understands who's using it and what they're doing and what's expected to see and and together they kind of work out what should be built and the developers starts to work out what how they can build it now there's a I should have done a show of hands here how many people in the room work with user stories right now today that's a lot yet I'm going back to basics here to remedial I'm sure you've all heard this card conversation confirmation some of you have heard that mantra first off that's let me I'm going to hit it again because well it goes like this you you write a card and you have this conversation now the person coming into the conversation has an idea of what they want and because it's a conversation they explain it to the other person who then listens closely and forms an idea in their head of what that person wants now it's a conversation so that person can then ask questions and they realize the idea I've gotten what you said isn't right and they start having a conversation and through that conversation they arrive at some shared understanding of what they want now if you're watching the slides closely you'll notice that the shared understanding that happens in that conversation isn't the same thing as the person who wrote the card came in with if your goal is to write perfect stories that have all the details in them and get it right then you're not using stories right the goal is for us to get together and actually learn something and it's that collaboration between the builder the maker and the one who needs something that has the real power this is not another way to specify things now agile processes take a big hit for we don't write down anything the truth is you write down a buckets anybody using agile development knows that you write down a ton but what's and you might come into this conversation with a ton written down already but you use this to point and discuss and change and I work with UI designers who will come in with the UI but you have to sort of expected to get marked up and changed and and well expect change but at the end we're driving to the answer to the question how will what exactly are we going to build how will I confirm that we've done it so that's that confirmation part it's an agreement between us that we okay we're on the same page and this is how I'm going to check to see if it's done now the over time we've evolved the best way of doing that is writing acceptance tests or acceptance criteria or story tests and well the answer to the question what will I check to confirm this is done now I believe that there's not three seas there's five seas the next one is actually constructing or building this thing and then after that well we've got to you know show the story at that sprint review thing but the truth is the blue guy did not build it for the green guy they built it for these other people and these other people have to look at it and we have lots and lots of conversations and here's where it gets really ugly we usually find out it wasn't the right thing and how we then change it is by writing a card and it's a cycle my friend Alistair Coburn said for every story you put in the backlog or for everything you need you should put three in the backlog and I said well what do you mean Alistair he said well just write the thing you need on a card and then put in two more I said well what I write on the second ones and this is the other two cards Alistair said it doesn't matter and I said I can't just write nothing on them and he said well if you have to write something on the first card put what you want on the second card put fix the first card and on the third card put fix the second card if you're not going around this cycle a few times you're not learning and well you don't get it right the first time that's not the goal so you don't get it right going into the conversation and even when you agree you don't get it right afterwards those are hard pills to swallow but unfortunately they're a bit true the point is that well this is about conversation and well the idea is fairly simple but simple doesn't mean easy let's not go back to this the idea is simple but there's well you can already smell and you already experience tons of things that go wrong basically people don't have conversations about the right things now I'm gonna spin quickly through a model I use yesterday and this is the model that frames my thinking always when I'm building software I'm building software not to build something but to create a benefit and I draw this now and later model a lot see how fast I can spin through it here the world we start with thinking about the world now and we see people in the world that are unhappy that are confused or frustrated and we get ideas about what to build now I might call those those could be products or features or enhancements to features we've got we might eventually start call you know specify them and call them specifications and at some point in time we'll call them our requirements now remember that requirements are just what we call our great ideas to solve people's problems now we go through some development process agile or not and at the end we end up with a delivery and what we hope is true later is that those people that we identified with problems are now happy they're not happy because because we delivered this stuff they're happy because they start using it and their life gets better and not everyone's as happy and some people you just can't please now everything between that idea and that delivery that's output that's the junk we measure with velocity that's the stuff we put in burn down charts and it's just stuff but what we want is what happens afterwards but we what we want our outcomes and those outcomes are measured by how people behave differently as a consequence of using that software how do they work differently how is it better than they used to work are they happier and oh what changes now some changes if I deliver a piece of software I can right away start to observe people and measure outcomes if I'm delivering some e-commerce sort of software and I make some changes and I observe that more people look at more products and they buy more I can observe that right away but if my goals were bigger I'm trying to change my position in the marketplace or improve customer satisfaction I don't measure that the day after I deliver something that takes longer the word I'll use for that is is impact your job in software development is not to deliver more software your job is to deliver less software your job is to minimize that output and maximize outcome I want to let's pound that in here output is what we build outcome is what we actually want and the stories we write are about the future they're about outcome and well what went wrong with stories is people started going into these conversations and they started well delivering specifications they started describing what to build and the listener to that conversation all they can do is take a lot of notes and ask questions about what to build and well they can't offer any better ideas or better solutions so now somebody came up with the clever idea that look we need to get people talking about the right thing so let's get them to talk about who what and why so the template as a type of as a kind of person a user I want some something so that I can turn that frown upside down so that I can get some benefit that template is made to build is made to help us have the right conversation now people make the mistake of thinking that that template is the story it's not the story in fact one of the important things about a story is that I have a crisp sharp title one that I can refer to in conversation one that I can point to and say I'm working on that such-and-so story do not fill your backlog full of these as I want to so that statements because well you know what happens at a stand-up meeting everybody will start to refer start to refer to story number 128 and that's no longer communicating it anything at all no one knows what we're talking about and give it a short title and you might use that template to help derive the right conversation now well it's there's the problem with people not talking about the right things but there's problems with people not talking at all what goes wrong with that template is people think okay I just have to write them in that template and then I am done that's it I can hand those off the same way I used to handle handoff requirements let's see if I've got these slides in the right order now I I love and hate that template I see Dave standing in the back of the room or sitting back there and I saw him speak earlier last night and I think you might share my opinion on this now I want to make a quick point about the way we learn to do things isn't the way we the way we really do it is anyone in the room a skier yeah I'm in India I suppose are there any skiers here I live close to a ski resort is anybody here learned to ski before yeah how did you learn to ski say you took a class and uh well did they teach you that move called a snow plow yeah that's what my kids are learned they learned pizza and french fries and the goal of the snow plow is to learn how to feel stable on slippery snow going downhill you don't learn the snow plow to get really good at snow plow there is no olympic snow plow event and and the best skiers do not snow plow through those moguls they stop it that template is a snow plow and it's critically important to use to learn but once you get it once you realize that the point is having a good conversation stop it it's embarrassing all of us it's you can't snow plow and call yourself a professional what you need are really strong conversations about who's using the product and there's a lot of subtlety about that because there's often different kinds of people using the same product what they're trying to accomplish and why they're trying to accomplish it and not just why they're trying to accomplish it but why we as a business want them to be using the software to accomplish it but it's more complicated than that there's a lot more to talk about than just who what and why it's not as simple as these two people talking to each other it's not just a user and developer we've got product managers and business analysts and testers and user experience people and project managers and they all want to have different conversations they want to have conversations about well if i'm a product manager what is the chunk that gives me some sort of return on investment or benefit in the market and and if i'm a ba i need to understand technical details what goes on under the scenes that in what are the business rules that drive this thing and the and if i'm a tester i need to understand boundary conditions and how to break it and where it's likely to break if i'm a ux person i certainly don't want you telling me what the ui looks like it's my job to design that i need to know who's using it what they're trying to accomplish it so that i can then do the ui if i'm a project manager all those details are interesting but i need to know if there are dependencies how long this is going to take if it started and and where it is in progress it's a lot of conversations and it's a lot more conversations than well the original idea is i would just flip the card to the back and i would write acceptance criteria on it but it's going to take a freaking huge card to hold all this information uh does anybody old enough to remember when libraries used to have card catalogs in them so uh for those that are young there that's a weird device uh like a record player but uh you used to go into a library there was a card catalog i'd look at the up the card and i'd pull out the card it would say the name of the book and a little bit about it but i knew that that card was not a book the book is somewhere else on the shelf and it's got lots of chapters and a ton of information story cards and the tokens we use are like that but your information is going to be in rally it's going to to be in confluence it's in some wiki some documents someplace or collected as information on the wall in the most informal situations that's great now that's one complication but we got the size problem a size always matters now if i'm having a conversation that's well it's user size if i'm a user expressing things as a need that's fairly straightforward i know what a need size is but then some developer says hey that's an epic it's way too big it it has to be small enough to fit into a sprint oh that's uh smaller than i need actually and uh well what's the ideal size for a story to to go into a sprint or an iteration did i hear anything did i hear a couple third of a third of a sprint i hear a third of a sprint i when i started with this stuff it could be bigger could be smaller but you hear a couple days but the point is it's well isn't associated with need size it's associated with development time and i hear a couple days to develop is ideal and hey if i'm a business leader uh that's not even interesting to me what's interesting for me to talk about are features and stuff i put in milestones and i'm certainly not interested in those little two-day things and um kind of a little bit more interesting well interesting things that make a difference to me is a business and well there are different right sizes for stories and for conversations now that's that's another tough thing now the truth is there's lots of right sizes and stories go through a journey if you picture yourself looking down the neck of a funnel and in that funnel is the smallest i'm gonna think of that as a development cycle and uh out the outer edge of the funnel that's the release cycle and my stories of i've got to pour them into this funnel and they've got to go down and turn into software and well my the things i write down may start as big capabilities or features uh big opportunities and i've and i've got a way to they won't even fit in the funnel i've got to have a lot of conversation and in those conversations i need to break those stories down into smaller size small enough that i can decide which one's going to a first release which one's going to a second release and in those conversations i might add more details and then once i've identified which one's going to a first release i can pop those into the funnel and have more conversations and add more information now if anyone's a business analyst or a product owner you know that you go through lots of conversations you add a lot more to your stories you might bring them into a workshop or a grooming session and you show the stories and all the acceptance criteria and how many of you have heard that story's too big and yeah at least a couple uh so it's those stories that you've got to break down into even smaller stories and it's those smallest stories that are right sized that shuttle through that through that sprint iteration across the Kanban board and it's those stories that are pile up as done or potentially shippable software it's it's those stories that well we're supposed to be actually showing these to end users but end users really aren't so interested in your cool new checkbox they're interested in things that support their work user-sized things so we kind of have to let a few of these pile up into chunks that i can validate with real people and it's those chunks that i then kind of that eventually pool up into big things that i can release that's the journey that stories go through and the best stake i see most people doing is trying to break them down to that tiny size to begin with anybody aware of the old Atari game asteroids anybody know that you played that game uh well in that game there's a little spaceship in the middle and there's these big rocks kind of moving around your job is to shoot those big rocks and they break down into smaller rocks shoot those smaller rocks they break down into even smaller rocks and then you shoot those now the bad thing about asteroids is when you the big rocks are big slow moving rocks but when you shoot them they break down down down into smaller rocks that are moved faster shoot them again they break down to even smaller rocks that move really fast a bad asteroid strategy is to break down all your big rocks into small rocks right away because they will crush you and kill you. A bad backlog strategy is to break down your big stories or epics right away because they will crush you and kill you. Don't do that. In fact, one of the things you can do with stories is if you've got a lot of little ones, you can actually roll them back up into big ones. You can't do that in asteroids, unfortunately, but you can with stories. Keep your backlog low. That works a little bit better and know that this is a natural progressive refinement thing that goes on inside your pipeline. Now, I promise to talk about the story mapping thing. I'm having too much fun and taking too long, but I've got to talk about one more problem and multiple people talk to me about, okay, great, I see this breakdown thing, but developers tell me and I know I can't break them down any smaller. I'll tell you what I told someone earlier is that it's a skill. It takes practice and it's kind of hard. Trust me, if you keep doing it, it'll get better, but I want you to think of cake. If this metaphor works for me, it might fall apart for you, but let's say I had a wedding and Indian weddings are much bigger affairs than they are in the U.S., but is a big wedding cake ever served here? Sometimes it's a big affair in the U.S. and they're big things and if I was going to make a big thing, a big wedding cake, and I was going to bake that, I would normally break that down into a recipe, which is for a big cake, lots of flour, lots of sugar, lots of eggs, lots of milk, and steps for beating things and baking things. Now, that's good, but your job with stories, the trick to breaking them down is to break them down into little cakes, cupcakes, and those little cupcakes have a similar recipe, just less. A little sugar, a little flour, a little water, things like that, and, well, that's the skill that's hard, breaking cakes down into cupcakes, and it's these, it's cakes that are stories, it's these things that we refer to as tasks or delivery tasks, so if you think of your developers as, well, they're the bakers, they're the, you put cakes and backlogs and those sprint backlogs or those tasks, those are filled with recipes and cooking steps, things like that. Now, we've got a lot of challenges working with stories and I need to talk about this story map thing. Stories are built for discussions or for telling stories and if we're trying to tell a story about a whole product, it's, and we don't know how big it is and we need to break it down, then that's what a story map is for. Start building a story map when you've got a problem that you need to better understand. We'll have a discussion that starts not just at exactly what to build because remember we got to talk about who, what, and why, we start with the big why. Why are we building this product feature thing and we can set some goals about what success is? We can talk about who, talk about the users who use something and then we say, okay, well, let's paint a picture the same way Kent said and let's tell a story about what they do step by step by step. At first they do this and then this and then this and then this and then this and we can tell that story step by step and then we can break that story down into all the details. Well, if they're going to do that in the first step, well, what do we need the software to be able to do? What other things could they have done? What goes wrong? And we end up with this kind of big fat map. And by map I mean a simple two-dimensional structure. It's everything above that that, well, it isn't, well, you can think of them as the bigger stories or context or other things, but that's the big who, what, and why for everything else. And well, those bigger stories at the top get referred to as a backbone. They provide structure for the map. Now, that's what a map looks like. We've got a lot of people in the back of the room. Does anybody want to build one of these things? Trust me that I can walk you through building one in 15 minutes. This is going to be tough. There's a lot of people in the back and we need some table space. So I'm going to grab, I'm going to grab some just a few sticky notes. There's only sticky notes on the front here. So some people in the back need to move forward onto the, into the front. And you could steal a few sticky notes from these tables. And if you want to just hang back and watch what happens, that's okay too. But you should come forward and join these people. Give this a shot. So all the tables should have them on. And we're going to do this really fast. Now I'm hoping people have pens because sticky notes without pens or there's pencils on the table really stinks. All right, the best way, story maps are for telling stories. I need everybody to tell a story and I want to teach you some concepts of what goes into a story map as we go here. The best way to do this is to actually tell a story about something you've already done, something you've already experienced. Raise this just a little bit, see if that works. How many people woke up this morning? At least half, that's good. I want you to think back to the moment that you woke up this morning. And we're going to do a very quick silent brainstorming thing because we need to populate this story map with lots of things people do. So if you think to the minute you woke up this morning, until, well, if we just talk about the minute we woke up and tell, I need a better pen, I'll get one during the break here. Until we left our home or hotel room. What I want you to do is write down everything you did between those two steps. So if I think back to me, the first thing I did was hit snooze. Actually, I did that twice and from then on I got up and went to the toilet and it goes on from there. You're all going to need probably 20 or so sticky notes and you need to write as fast as you possibly can. Go. If you're in the back and not participating, you might grab a sheet of paper and just actually write a list. It might, it'll help you get the same concepts down. I will tell people that to finish this activity takes exactly the length of the time of the song Kung Fu Fighting. I don't have speakers, so you can't hear it. So it's for me. Verbs? Okay. Verbs are important. It's difficult to tell stories about what people do without verbs. These particular short verb phrases that we naturally speak in or talk about are what I'm going to call or not what I call, what lots of other people call user tasks. Now tasks is a tricky word in agile development because we use that to say what developers do to make software. But these are what you do to get out, to reach that goal of getting out of the door in the morning. Now, do a quick scan count. Did anybody get more than 10 written? Do anybody more than 15 written? Anybody? I give people, yeah, a few. So why would some people write more tasks than other people? And you got to shout loud. More detail? More granular? Yeah, you guys know all the answers. What else? More post-its? You had more post-its? You didn't run out of post-its? You do multitasking? Well, let me, I'm going to fill in for you to go fast here. Lots of people talked and yeah, that's, I can't hear two things at once. That's bad. You had more time actually, yeah. So if you have more time, if you get up earlier, you can do more. Now, this may come as a shock to you, but people are different and they do things differently. If anyone has children, I guarantee you have more tasks than other people who don't. If you have pets, it might be similar. If you have more time, it might be similar. If you have a little bit of a dedication to an exercise or workout regimen, it might be similar. If you've got an annoying job, you probably have tasks for checking email and other things like that that others may not. But basically, there are differences among people. Now let's pick apart this more detail thing, Mr. Coburn for talking about the goal level of these tasks. Now, he talks about, he uses a C level metaphor to talk about what's in the middle as functional level and he'll annotate those with ocean waves because that's at C level. A functional level task is something I would do with a reasonable expectation that I would complete it before moving on to something else. Like take a shower is one of those. Because you don't get halfway through taking a shower and say, man, this is dragging on, I'm gonna go grab a cup of coffee and come back and finish this shower later. You finish it, but taking a shower decomposes down to adjusting water temperature and washing hair and washing body and because people are different, my wife has these tasks with some loofah of mitt thing and I don't have those tasks and I don't use cream rinse, I'll admit it and things like that, we're different and oftentimes the difference are in those subtasks and Alistair will annotate those with a fish and then above that, it might be summary level tasks and Alistair will annotate those with a kite but those functional level tasks are the ones that matter. For designing software or thinking about users meeting their goals or actually getting a value or benefit, they've gotta complete something that's functional. Once they complete something that's functional, if it's crap, then you can modify things underneath it to make it better, but if they can't complete something functional, then it doesn't matter. All right, now let's see how fast we can do these next couple steps here. Here's the, all of you at a table have done this and what we need to do is organize these into a model that shows what you did and basically if you organize these tasks into a flow from things you did early, early to things you did late, you'll end up with sort of a left to right flow and this would be easy if you were doing this all by yourself but I want a map that shows how people get ready in the morning in the same way you want a map that talks about how people use your software, not just one person uses your software so we've gotta merge these together. This means you're all gonna have to merge yours into one left to right flow and this is going to be a problem because people did things in different orders, some people did things that other people didn't do and there will be arguments about what order to place things in. Fortunately, I have a simple remedy for that and that's to shut up, no talking. Organize these things left to right, put them in a flow, you might find that some people have subtasks or similar things, you could stack them and if you don't agree with where someone put it, you can move it and if they disagree with you, they can move it back but you'll find this goes easier than you think. So organize these on the tables left to right. If you're in the back, you might pop up and watch what these guys do and go. Just have a minute or so, get these things left to right as fast as you can. If you talk less, it'll go faster. Just for now, I'm gonna blow my time box really bad if I don't stop you, so I have to conclude this and show a few pictures. All right, all together, I wanna tell you that the order things are left to right is what I'm going to call a narrative flow. It's the order I tell the story and people will say, hey Jeff, the world doesn't work that way. I have this process where I do step A and then I come to this decision point and I could do step C or step D. How do you show that in a story map, Mr. Smart Guy? And I say, well, I just do A, C and D. Why do I do C and D? And I say, well, why do you do that? Why do you put it in that order? And I say, I didn't put it in that order, you did. You told me I do A and then I could do C or D. All that connective tissue between stories like I could do A and then C or D, all those extra words come out of your mouth. They're not, this isn't UML. This does not replace UML. It doesn't replace use cases. It doesn't replace any other modeling mechanism. Arrange these in the order you would tell the story and if there's ands and ors and other kinds of conjunctions, let them come out of your mouth and if you need to, draw a UML model. Now, that's what narrative flow is and you'll find that if people did, what you see top to bottom are, well, details and variations, alternative ways that other people do things. See if we can get a couple more steps in this and then I can conclude a little bit. If you read across that map left to right, you'll find that, well, it's fairly long but you'll find that there's some natural chunks or breaks in it. You'll often find if you're doing, talking about real work that people do in a house that oftentimes when you move from room to room, there's a break. So like you might find all that stuff about getting out of bed is here and there's some stuff about getting cleaned up and ready and some stuff about making breakfast. Take another color of sticky notes or you could use whatever color you've got. By the way, in a pad of sticky notes, not many people know this, you get two shapes. You get a square and a diamond, free. Wherever you see a group of things that look together at the beginning of that group, put a sticky note and then put another sticky note. So I could say all these things are about getting myself out of bed and all these things are about cleaning myself up. Mark it with sticky notes and I will tell you that you need to write something on this. And you need to keep these verbs also. But really, you only got a minute. Mark them fast, decide fast. It's gonna be, don't argue about it. Make sense? Go. You gotta shout out, read me the top, just the big things at the top. Taking care of health, family time, getting ready for conference. Just those three. Anybody else finish? Can you read what you've got across the top? Wake up, what was the first one? Next one? Freshen up. Check. Check work, okay. News. Pack up, okay. Eat and drink. Leave. Okay, so there's kind of different levels of things there. They rolled up at a higher level, you rolled up at a lower level. Does that flow sound familiar or right enough? So what's interesting is if you stay in narrative flow, we can go up a level and there's still a narrative flow. Still tells a big story, so I don't have to read all those other little stories. The term I'll use for these, that's a user-centric term, is an activity. Activities are things that people do with lots of tasks that they may do in oftentimes many order and omit some and keep some. Now we could go to town on this story map and I could ask you to fill this in with tasks that you do on other days. And I could ask, I could play what about with you? What about when things go wrong? What about, well, when you're, my daughter didn't do her homework and I've got to hurry fast stop what I'm doing and help her do that or my wife is sick and I've got to take kids to school and other sorts of things. And I could fill these in. I could also say, well, what about, what if my morning could be better? What are the things I would do to make it really good? I would exercise, I'd make a better breakfast. I'd get up early, I'd read a little bit. I could put all those things in and really fatten this map up. And we want to do that because we want to think of everything we could do. We're not, we're gonna do one quick last step and that's to plan. I want you to, maybe most people might have a first task in there of turning off their alarm or something like that. Pretend that task didn't happen because your alarm did not go off. You woke up and your eyes sprung open and it was 8.57 and you wanted to be here at this conference on time and you know you're going to be late. You need to get out of the house as fast as you possibly can. I want you to look at all those tasks and I want you to move everything, just keep things at the top that you would do and move everything down that you would not do if you had to get out of the house in just a few minutes. Now you have to satisfy everyone at the table. I see men often skipping the shower stage and saying I could just apply extra deodorant and women not being okay with that. You might have to write more tasks for things that you would do in that situation. Just take a minute, just quickly shovel things down and see what you have left in that top slice. That conversation about all the details and all the acceptance criteria. If we're thinking about value and benefit we've got to have stories at whole product or whole feature, we've got to tell stories at whole product and whole feature levels. My first goal is to understand that thing, understand who, what, and why. Not for this little tiny thing, but for the thing that has value. Then once I understand it, I get the whole flow, I want to then explore details and options and all those what abouts and then I want to plan. I want to say gosh, to be feasible for us to deliver this on time, I need to focus on a specific user, a set of users and some specific context and let's slice this up into what are useful releases and then I need to carry those things into this routine sprinting cycle of having more detailed conversations then I want to write all that acceptance criteria and really dive into details but that's when I'm delivering. Story mapping is for breaking down big ideas and big features and helping me figure out what the minimal viable release is for those features. Helping me have big conversations. Now that first understanding starts with framing the product with what's that product, who is it for and why and I'll often build simple lightweight personas to describe those. I'll often name product goals and even go so far as to name metrics for those. The next thing is to imagine that product's use and tell a big story left to right. These are guys that they're starting with understanding who the users are and they're, show a little bit of this, they're telling a story and I want to watch just enough of this to see these guys work. They start by writing cards that give us that narrative flow. That big left to right green stripe is the first people do this and then this and then this and the thing is we love to work top down but sometimes our head doesn't naturally think in activities so they add the activities in later to make it easier to read and sort of summarize things that kind of all go together and then they start moving forward to talking about details and fattening this thing up, adding lots of what abouts and we could do this and it would be better if we did this. They're making a next version of existing product and they're looking at this product they don't like very much now and they're writing stories about it and you can see this thing is getting fatter and fatter. People will ask me, what is the difference between those bright green cards and the other light green cards in the middle of that thing? There's no difference, they just ran out of one kind of card but it's a signal that they've been telling the story over and over and rewriting it and ripping it up. Just cards, just rip them up and make sure the story still tells right. That's the important thing, those short titles and these nice titles work like that. Now that's one way to do it but I work with other people that say, gosh it works better for me to think about the user interface first and sketch UI and a storyboard and then I can lay that out and then break things down underneath that and well it's once I've got that that I can do this exploration phase, this breaking things down and think about other, this is where I pull a lot of other people into this map to help me do this. These people are having a, this is a real story conversation. That guy talking is the finance manager of a bank. He's interested and engaged because this is a story about his life. He can engage with this thing because it isn't a stupid story about a check box. It is something that's important and the guy writing a sticky note is actually not writing a story so much. He's writing down a problem that he has that they want to figure out what to do about with a story. Now, advance ahead, it's that same map and by now they've fattened it up. You can see that it's fairly big and there's a lot of things we can do with that map but here's where the real power of this kind of structure comes in. This is the same group at a company called Globo and this is a map when I first encountered this group of people. I'm running a couple of minutes over. The person with the next presentation, where'd he go? Is he in here? Yeah, there you are. But you might want to come up here and say, damn it, get out of here. We'll see if I can wrap up here. But this is the punchline for me. When I came into the room, there were three teams working together on a revision of this big content management system and they all had their respective backlogs on paper and they were arguing and I said, guys, you've got three different teams and it's a big project and you've divided up this work and you can't figure out how to start and proceed but this is one product. To get value, you each have to deliver something and you can't imagine it and plan this so get it on the wall and they did and they were happy. I came back a couple of days later and they were sad and I said, well, what's wrong? And they said, we can't possibly deliver all of this on time and I said, well, how long's it gonna take you to do this? And they said, a year or more, which is how developers say two years and I said, gosh, I know your CEO and he won't tolerate anything that takes longer than a few months and they said, yeah, we need this to go live for Brazilian elections and that's in four months. And I said, you know, you can't get all this stuff done. If we say, what do we need to go live successfully for Brazilian elections, what would that be? And they thought, well, what does it mean to go live successfully for Brazilian elections? Well, we probably just need to do the news website and maybe a couple of these political blogs and we just need things that give us these animated real-time charting stuff and let's focus on that. So they add tape lines in here and they go to work moving stories up and down and they slice this map up into what our successful release is. Where everything above that line is what they need to go live for Brazilian elections, all those yellow stories and what's written on that orange thing out there, that's that goal. That's what success means for this release which is going live for Brazilian elections and getting the outcomes they want for that. Now, everything else lays it out there in a roadmap of other releases. We've not talked about all those details with story maps, with stories, we've not figured out acceptance criteria, we've just talked enough to start to imagine this product and start to make a first sensible break of things. I'm gonna do one last thing and we're gonna wrap this up. Well, I always have to do this demonstration because it's meaningful and maybe I can do this, maybe not. Yeah, start getting set up here. Cory, if I were to, this may be a big feature, a big new product and if I release this, I get all this business benefit. But when I look at it, it's gonna take me too long to release. So my first layer of planning is to sort of break it down into smaller chunks that each have some value or benefit. And it's those chunks that I use to make change for that big story and those may be a series of incremental releases. Now, but those are still too big to fit in a single sprint. So let's focus on this first release because I can build that first and I know that it has value. But I need small things that I can deliver in every single sprint. And each one of these that I build that adds to this product and builds this up. Now, a stupid thing to say is, can you prioritize these by business value? What is the value of this versus that? If you ask a business stakeholder, which one do you need first? They're gonna say, fuck, I don't know. I need them all. The way you prioritize these is by building the thing that you can learn from first that you can validate assumptions first and learn fastest from first. Those are the ones that you have all those detailed story conversations on. And I wanted you to see this transition, this flow from big stories to little stories and how we prioritize for value at release time versus how we prioritize for value later. I'll leave you with this. That first off, these stories are for telling stories. You've got to be able to imagine users using things. If you can't imagine it, you can't build it. And a story map is about, well, seeing the whole structure, the big thing. And it's about seeing the whole tree and seeing the whole product and not about piling things up in a leaf bag and tossing them away at people. That's that. Thanks for staying longer for the people that could and let's get to the next thing.