 I've got a lot of stuff I wanna cover today and with your permission, I'm going to improvise just a little bit. I've got a deck that's full of stuff that I wanna talk about and there's a lot that we could do. The more we do, the less we talk and the more I talk, the less we do. So the first part is gonna go fairly smoothly but after that we could decide whether we wanna do more talking or more discussion or more doing. In way of self-introduction, my name is Jeff Patton. I've been involved with Agile stuff since first extreme programming project in 2000 and the term Agile was coined in 2001. So I was thrown in pretty head first into an extreme programming project where the consultant hired to get the team up and running was Kent Beck. So I got a good first taste of at least what XP is supposed to be like but I walked away with this weird feeling. This was the coolest thing I'd ever seen in my life and at the same time it was one of the most disturbing things I'd ever seen in my life. This was a team that worked very well together. They were very well organized. They collaborated well and they built very high quality software. Only I just felt like the product they were building was stupid and it just wasn't good. And I was hired at the organization because I was a bit of a domain expert and so I initially spent time on the customer team arguing with other people on the customer team about why this product was dumb or it wasn't a good idea or this wasn't a good plan why we were not going to get a product to market that everybody would like and that would deliver this benefit that we wanted. To make a long story short I threw my arms and quit and they wouldn't let me quit so they let me be an engineer so I got to learn, test, or develop with a real way from hardcore engineers. But I came away thinking that we've got to do a better job at understanding what people in an agile customer or product ownership role are doing. This particular class tutorial thing that we're talking about is a bit of a thing that I'm referring to as user story mapping and like all pretty good things it's stolen. This is a concept that I've seen emerge across a number of different organizations in a number of different ways and I'm trying to collect what I've seen as good practices about this pattern and I'd like to see more people doing this. So what we're going to talk about is building better products using story mapping and user story mapping is just the next step of how we think about user stories or this base thing that goes inside of agile development. So my goal today is that you start to feel comfortable with building this weird arrangement of user stories to understand your product. In the first half before the break we're going to talk about some underlying concepts and practice something and build at least one story map and if we're lucky two. When are we taking our break? We started at one 10, correct? Yeah. Does this have us taking the break out? We'll get there now. Okay. See this really is improvising. That's two 40s. Is it two 40 or two 30 or? Yeah. Good. Two 40. I'll shoot for somewhere in there. Yeah. In the second half, once we've built a story map or once we understand our backlog or once we understand a potential product in terms of the stuff that we might build we have to start to figure out how to plan to incrementally release this. And then a distant third here and I've graded a little bit because hopefully we'll get there. Yes, once we've planned an incremental release then we need to figure out how to execute on that plan. How do we build a good product a little bit at a time? And preserve that big picture that we were shooting for. So the last bits are a lot of tactics that I could share and if we actually practice building a good plan it'll kind of jeopardize our ability to talk about construction tactics. So we'll see where it goes. So I wanna start with the idea of a user's story. This is a real disparate audience, I believe. I think there are people in the room that have been doing Agile development for a very long time and there are people for whom Agile development is new. So in the room, can someone offer me a definition for user's story? For what is a user's story to you? Please. Placeholder for a conversation. So it's the Kent Beck mantra prevails which is good. So I'm gonna write down the placeholder for a conversation. Why don't we call them user placeholders or something? Something the user wants to do. Something the user wants to do. I don't need to write down all these but I wanna get a couple things up. Jim? To apply. I'll just go for applying. Anybody else, any other definitions out there? To linger on this, somebody who's using stories, tell me a story about why you like them. Think of a time a user's story has really solved a problem for you. Anybody can offer a story about something that's great about user's stories? That's easy to say. They're abstract so you don't get caught in details. They're abstract so you don't get caught in details. Can somebody tell a counter to that? Where have user's stories really done you wrong? All the way to the back. Who's gonna answer the first question? Oh, that's okay. Oh yeah, please, the first question too. Yeah, there's a lot of great things about user's stories. I mean, they describe something from the user's perspective rather than just giving you a feature, right? You know why the feature is there. It helps us to start to talk about why the feature is yet there. Understand the reasons. Understand more about the story or why we're building what we're building. Can anybody offer something, a problem with stories? Yeah, a few hands out. Well, I mean, if you say that you're building middleware, are there very few kind of human actors in the world? Yeah, so it's hard to. The expression of desire. The idea of a user's story isn't almost appropriate for what we're doing. Which is an interesting thing to talk about. This is a good subject to bring up later about these things. They're not sufficient to fully document. I mean, it doesn't seem to satisfy all the needs we have for documenting other features of working inside. Anyway, have you had a specific problem? Can you tell a story about when they've hurt you that way? One of the other projects is write stories and throw them away when I'm done. And sometimes there are people who need to know those things who perhaps somewhere down the line and want to know more. And I've lost it. Yeah, I know. They're not documentation for the system or the reasons why we made these decisions. Supports like that. Okay, all right. Okay, I wanted to get from the room what you understand about user stories before I give a short little primer. And based upon what I've just heard, it can be very short. You guys do understand a lot. See if I can plug in. In my mind, user stories have a bit of a problem. They are a multi-purpose thing. Let's see if this works. New shimmer is a dessert topping. It's a dessert topping. Fimmers of floor wax and a dessert topping. And some on your butterscotch pudding. So user stories are encumbered by needing to do a lot of things. How many are old enough to have saw that originally when it aired? Good. Respect your elders. Encumbered by needing to do a lot for a lot of people. Stories are, and we wrote down, a user's need or they describe what a user wants out of the system or desires. They are a description of the product eventually. We might give all that need to something very precise about what the product is or should be or should do. They're a planning token. Once I've got more than one of them, I can start to say this, let's talk about this one first or talk about this one next or put one in front of another. They are a token for a conversation because they aren't big enough or they don't contain all the details. We've got to talk more about them to better understand them. There are mechanisms for deferring conversation. If I don't want to talk about it now, I can at least name it and I can schedule a time to talk about that in some distant iteration or release when I really care to. The user's story, let's go back, well I don't wanna go back to Kent, but the user's story was originally coined by, that the term was written about by Kent Beck and I'm not sure who invented the term. But the name is for me more or less a neutral name that doesn't mean use case, doesn't mean requirement, doesn't mean all the other potentially poison terms in software development. It needed to be something new that we could stuff in our own definition for. Stories have this issue of gaining detail over time. We might start with by writing something on a card. It's a title. We might add further description and that there is the now popular user story format as a type of user. I wanna perform some task or do something with this system so that I can get some sort of benefit. Who in the room is using that format to do things? Some I heard sometimes. Are you apologetic about that? It's a good format because it draws attention to a user and what they need and I'll rant on that a little bit later. But over time we may have conversations about these. We may add notes and sketches and user interface details, business rules, all sorts of things we might add to this. And then as we get ready to build this, eventually we want concrete, we want acceptance criteria. We wanna know when we'll be done with this story if we build it. We don't start with acceptance criteria and if we were to write up a whole bunch of stories and carry every one of them through this entire life cycle, it would suck. It would take a long time and it would start to smell like the things we're avoiding with agile development. There is my little rant on that. For me, this template is a bit of a thinking template. If one of our goals of user stories are to be a user, something we can use to plan effectively with, has anybody tried to move around a plan where all the stories are written in that format? And is it easy? It becomes very difficult to move around stories when their whole sentences, short titles are valuable, but it's extremely important that we think about who's using it and what benefit they get. These are good conversations to have, not good templates to be dogmatic about. When we, again, last little thing to hit is if we get a story that they never travel alone, we will need to assemble a whole bunch of these stories into a product backlog. So we've got a lot of these. That's all I have to say about user stories. But I want to, this is a multi-purpose thing and I want to talk just a little bit about the nature of multi-purpose things. This is a, I added this quickly during lunch, but it's sort of important and I saw people this morning really going meta, really thinking about why Agile works and why we do what we do. And this is the Agile Roots conference and for me it's, I wanted to reflect a little bit on what's important about a user story. User story is a boundary object. Who has heard that term boundary object before? Enough folks, I've used the term but I actually looked up the definition earlier today and I have to read through it a little bit. A boundary object is a concept in sociology to describe information used in different ways by different communities. Sort of sounds like what we're using user stories for. They're plastic, interpreted differently across communities but with enough immutable content to maintain integrity. That's the distillation that's in Wikipedia but the quote from this Lee and Gricemer paper that described it, paper, book, something that described it had some more information that I liked. They're weakly structured in common use but become strongly structured in individual use. So as I add more detail to these things over time for my purpose, they start to gain more structure and gain more properties but they're no longer for common use when they do that. They may be abstract or concrete which sort of implies they kind of move from abstract to concrete. They have different meetings in different social worlds but the structure is common enough to more than one role to make them a recognizable means of translation. So they always at least need to maintain this ability to be recognized by other people. The creation and management of boundary objects is key in developing and maintaining coherence across an intersection of social worlds. And that was the last sentence in there that sort of threw me that we're maintaining this stack of boundary objects and it's really important that they stay coherent, that we understand them. Otherwise we've sort of lost our boundary. So who in the room has a large user story backlog and struggles with keeping it alive as a conversation? Can I get an amen? Or is it? So that's really what we're talking about. So two aspects to hit is basically user stories are a boundary object. They form boundaries between a lot of different people. They mean different things to different people. Ideally if I've got a user, the user wants to describe what they want. So I can say what I want and ideally there was this developer who yes I wanna know what you want but really what I'm concerned about is getting at the details of what I need to build right now. And before too long users just can't talk to developers. Some business stakeholder will weigh in with what the product needs to have in it to be successful. These features that will make the product sell or be beneficial. And before long the stakeholder will wave arms and say something big and leave the room and then a business analyst needs to carry that conversation forward and describe what the stakeholder meant by something specific that would be successful. And then before too long we get a bunch of these things and a project manager needs to weigh in and decide when things are gonna be done and start to schedule things. So a project manager needs something that they can move around and schedule. And as quality starts to slip, we need to start really validating this stuff. So someone else needs to look at that thing, that story and decide how to validate it or test it. And then because quality still sucks, a user experience person may weigh in and start to describe, want to understand the whole system and what users are doing so that they can make a product that people actually like. So this poor little index card is burdened by needing to be meaningful to all these people. And it's difficult. So I have no big answers for that. I've got an answer, but size always matters. So when we're talking about a story, is it a story or is it a story? Is it the one that goes into the sprint? Or is it the one the stakeholder came to us with to talk about this is the one I wanna have the conversation about? And when we get a bunch of these stories, it's easy to lose the forest in the trees. If there's a lot of them, how do I keep straight what the thing is? And as I start to construct things, how do I know where I'm going or how do I stay on some course or at least know there is a course? So these are problems we start to meddle with. And it's in my view that the prioritized backlog as the sole mechanism for dealing with these concerns isn't sufficient. But I may be just a squeaky wheel. So the thing that I've been using for a little while is this idea of story mapping. It was Luke Holman that had mentioned to me Jeff, what you're concerned with is organizing the backlog, not prioritizing the backlog. And those are different things. And what I'm driving at is trying to understand or make sense of the backlog at the same time we're prioritizing it. So I wanna quickly say what it is first. It's a way to make the backlog visible so I can see it so that we can indeed have these conversations. It's a way to talk about relationships of stories that start out big and get smaller or break down and decompose over time. It's a way of looking at the whole thing and starting to assess completeness. It's starting to get scratched that itch of do I have all the stories I need to ship this product? Is it going to be a good product when it ships or am I going to find something just before ship time that's big and important? If I want to have a conversation about prioritization or about what this product does that this kind of big visualization gives us a context for having that conversation. In practice they end up looking like great big gobs of sticky notes all over the wall and hopefully these will start to be coherent. And in practice when we've got one of these we start to have very rich discussions about what people are doing with the system instead of tiny little discussions. So that's the end of the talk about what a story map is now we have to start doing something. There is a foundational element that I compose my story maps out of and I get to teach this the way that I'm doing it and as I said before I've seen a lot of other people do this. So they use different things as a foundation and at the end of the day frankly it's not really important what you use unless you're working with me. The foundation of a story map for me is this idea of a user's task something that I as a user want to accomplish with this system. So I want you guys to start to get used to thinking about this and we're going to build a bit of a map. So let's start. I want you to start by imagining or remembering when you woke up this morning and think through the things that you did in order to get ready to be here today. So think about the series of things that you did from the time you woke up to the time that you left and don't move just yet. What I'd like you to do is to write those things down for me one thing at a time and I want you to use sticky notes and sharpie markers. Don't get up yet. So if I were to have some sticky notes here I've got a yellow sticky note I might grab my sharpie marker and the first thing I might write would be a hit snooze button and that would be my first act of the day. So it's something I did on my journey to getting ready. So I'm gonna write one thing per sticky and pull it off and set it aside and write another thing. So what everybody needs is a few sticky notes and let's just start with the yellow ones right now. And everybody needs a sharpie marker. There should be enough sharpie markers for everybody and there's a method behind I get crazy about people using sharpie markers so that we can all read them. So everybody needs a sharpie marker and a few yellow stickies. And I'm gonna ask you to all get up now and get them but one of the things I want you to do that's gonna be disruptive is to not sit with people you know or people you normally sit with. Sit with people that look like interesting strangers. But get away from your coworkers for a little bit. So some of you may have to move but some of you may already be sitting with interesting strangers. I feel like I'm gonna have to move the table. Okay, some of you were already started. Some of you are still grabbing stickies. If you're going just get going. Start writing one item per sticky and start writing everything that you did in order to get ready today. And I am going to set a timer for five minutes. Actually I'm lying, that's too long. I'm gonna set a timer for three minutes and let's see how many you can get. All right, if I can get everybody back, don't make me use this. All right, our next step is to organize these. It doesn't help if we know what we did. I wanna put all these together into some sort of shared understanding of what it takes to get ready for a conference in the morning. So I want you to work in a small group which turns out that your table is probably as good as any although there's probably more than five people at tables. And I want you to arrange these things in a left to right order. It's something that feels a little bit like a timeline to you. So it's easy to take one end of the table, grab a sticky and wrote since these are round you can start at any end of the table. And right, I woke up and then near it or someplace later, right, I left to come here and let everybody start to pile in and put things in an order that makes sense for them. But then I want you to start to work to organize these a little bit. So ideally people will have done similar things like brushing teeth. I always make it a point to count the number of stickies that say brush teeth and compare that with the number of people at the table. But after doing that, eliminate duplicates and then I want you to try and go a little bit further and look for things that seem similar, clusters of things. And I'd like you to go a little bit farther and see if you can put a label on top of those clusters. Three big instructions, but I know you guys can do this and I'm gonna set a timer for about seven or eight minutes and I'm gonna walk around a little bit, see how people are doing. Let's just chat a little bit about what just happened here and first off, what's common about what, what do you find in common about what you all wrote down? Everybody took showers. Somebody said something back there. Everybody woke up. Everybody put clothes on. Nobody had breakfast. Did anybody write down something that said skip breakfast? Just curious. So one of the things I always notice is that every, all these start with a verb. They're all these simple little verb phrases. Aren't they? Does anybody, did anybody write down something that starts with a noun? What did you write? We tried going room by room. So starting with the bedroom, then the showers, then the kitchen, then, you know, that didn't work out. We decided we could like it. Oh, so you were talking about the big organizational structure at the top. Okay. So yeah, that's, good, good. So what was different about the way people wrote things down? Did you, as you started putting these things in, did you see that somebody took a very approach, a very different approach to the way that you did it? What was that? Yeah, I mean, the level of granularity. The level of granularity. What's an example of a low, of fine grain? It's something that, Somebody said they turn the lights off. I never got out of the shower. Yeah, you never got out of the shower. This is a, so I suspect you were writing a very fine grain. How many steps in your shower? Just out of curiosity. I realized I was writing a session in Stanley, by the way, I didn't think nine. No, so did anybody else have a nine-step shower? No. Did anybody write, just take a shower? I usually skip steps four through six of my shower, but yeah. So I'm describing the travel, like the actual activity of going to a room, instead of just, I woke up and took a shower, I woke up, got out of bed, went to the bathroom, and went back to the room. They describe the commuting, from room to room, from a walk down to kitchen, things like that. So people describe different things, or saw different things, or bubbled up different things. Different tasks, no. So unrelated tasks, but combining them as a two-step, somewhere from now, as independent tasks. Yeah, and then there's a little bit about composition there. No, actually, maybe I'm not getting it. Say more about unrelated tasks. Well, I eat my breakfast and paid some bills. Did you like eating breakfast and paid bills on one sticky? Yeah. That's interesting, the operation. I never returned, I was eating them at the same time. So this eating breakfast thing involves taking a bite and writing a check, and taking a bite and writing a check, kind of a thing, or typing in something on the internet. Did anybody else have combined activities like that? So what did you do with them when you started to organize them? You threw them away. Good. Flex stories than others, because some of us have lots of kids and lots of men, and others don't have any of that. So their stories were a lot more elegant. Because they could have all of the computer details. So the people with longer stories were less elegant, or more messy. My daughter didn't have pants this morning, so. So that's really weird to put it to the user. I don't have any pants. You don't have to find pants. Talk about organization just for a minute. As soon as you start organizing these things together, you all had different mornings. Can somebody read, somebody who did the organizational structure found groups across the top. Can you read me the structure across the top for you guys there? Sure, we've got sort of online activity, hygiene or physical needs, feeding ourselves, feeding kids or pets, personal activities, spousal interaction, pre-exit, stuff gathering, and stuff done in the car. Pre-exit, stuff gathering, stuff done in the car. It's interesting that the computer activity precedes the hygiene sorts of things. Is it true? Is that the order? No, it's an interesting observation about you guys. I get on, my bladder's really full, but I gotta check email. Once I know, there's nothing urgent, then I can. They like to take it to the other urgent matters. Yeah, yeah. There was a, there was a, there was a, there was a, there was a, there was a, there was a, there was a, there was a, there was a, there was a, there was a, there are usually, there's two kinds of people in the world. People that brush teeth before breakfast and the people who brush teeth after breakfast. Did you have splits of when brushing teeth occurred? We, in general, we sort of gathered them by activities, not chronologically. No. Some of us went for a run, so they got dressed twice. Some of us, some of us probably ate breakfast in a different sequence, but we just gathered the activities, not, it's more or less chronological left to right, but we gathered the right tasks rather than time tasks. So it's no longer a real representation of how getting up in the morning works for you guys. It's close. I mean, it's, It's close. In that eating generally comes before walking out the door. Yes, yes. So yeah, definitely the eating is to the left of the door. But there are some variations, so I, I, I mean, right first one, I, I, I mean, yeah, there's two of us. Anybody else do the thing across the top? I'm curious, can I get one more? Yeah, for, for you guys, could you read me the things across the top loud as you can? Wake up routine. Wake up routine. Get clean. Get clean, yeah. Then pets. Then screwing off. What are the stickies that are under that? Read these stickies. Here are the stickers. We're just screwing off, read comics, watch TV, read MSDM magazine art. Got it. Okay. It's dead. It's off the top. We have gear up and then transportation. Gear up and then transportation. Okay, good. So what you guys have done is create what for me is a story map and it's built and it describes the shape of getting ready for work in the morning. And if we were to build one of the robots from Brian's discussion this morning that helped you get ready for work in the morning, the robot would need to know this stuff and we could make feature choices about the robot that actually did things other than vacuum the floor. Maybe the robot would feed dogs and make breakfast and all these other things. So we could start to actually use these as features of the robot that helps us around the house. But right now they're describing the experience of getting ready for work in the morning. So what you did, everybody wrote down things that started with verbs and these are what I'm going to refer to as a user task. I'm gonna spin very quickly through a mental model that I cannot shed, get out of my head. It's, I simplify everything into one of three things. This is a distillation of a simple interaction model that I think I might have overly distilled from Don Norman book. But it starts, the story that starts this way. People have some sort of problem or goal or thing they're trying to accomplish or achieve. It's in their head. It's get here to this conference in the morning. It's eat food so I'm not hungry. It's the goal is don't be hungry or not be hungry. They start with this desire and to do something about it, to not be hungry, I have to take some sort of action and that action occurs in the world. If I'm going to not be hungry, I need to eat some food and I have to start to look around in the world and find out what I can specifically do to not be hungry, to find food in the house or make cold cereal or cook breakfast or pick something up on the way as I'm driving in. But I do these things and then my head stops and evaluates did the thing I intended to do go okay. If I pour cereal into a bowl and I pour but nothing comes out of the box, my immediate reaction is to check whether I'm still hungry or not is to say well no I expected cereal to come out of the box, what's up with that? And so I will check to see if that action I took worked and if it didn't, I'll do it again. So I'll shake the box over and over or jiggle the doorknob or push the elevator button over and over as we have this, if we try things we want to keep doing them, humans are slow that way. At some point in time if I execute an action I will stop and check my goal. I've pulled a bowl of cereal, I'm still hungry? Yeah I still am, I better do some more things and I keep doing this loop until I finally check and I'm happy my goal is met. So for me everything boils down into these three levels of goals, things that people want and these are things that are out of the system, tasks, these things that people do in order to reach goals and tools, these things that people find in their environment to manipulate to use to help them reach goals. We are people that build software and we build software for lots of people and these people have lots of goals and do lots of tasks and therefore need lots of tools and in software development we commonly refer to those tools as features of our product. And we have the capability of talking about features of our product or we have the capability of talking about what people are doing or trying to accomplish and deferring discussions about the features. This model for me scales up, I can start with this simple goal task tool model but I can think of businesses that have business objectives to dominate specific markets and earn more profit and kill competitors and they will build products or put in business processes and they will hire employees and vendors and build systems and that's the way they act on their, that's the way that they build the tools or harness the tools they need to act. But at the end of the day they're not gonna be happy unless they've got those goals met unless we understand what those goals are and drive from that perspective. So tasks require this intentional action. Tasks have a somewhat more of an objective finishing. I know when I'm done with the task. We all saw that tasks decompose into littler tasks. We can either take a shower or we can write the 20 steps to taking a shower. It's a bit of a problem when we try and describe things as tasks because we have to figure out how big is this one. Tasks cluster together in what I'm going to refer to as related tasks and I'm gonna refer to this as an activity. So everybody folks had activities that were getting stuff ready before I leave in the morning, getting stuff ready before I exit the door. The specific tasks that people did to get stuff ready is different but people do different things. But all those tasks kind of go together. I make a pause in my cycle here and I get a bunch of stuff ready. So this activity is a bigger thing and oftentimes people don't think about it or describe the bigger thing. You almost have to find that you have to bottom up to get at what it is. People can't say what it is. That's a difficult thing. The tangible example is sitting down to read email. I may send messages, receive messages, prioritize my mail, get back to people, put things in folders and all of that is part of this monkeying around with email before I leave in the morning. And it's all part of managing email. So what's important to me is I can do all these things in support of this big thing. I just want to skip over this. These activities are important for me to think about. Activities have that pile of tasks but activities by themselves have a goal that's sort of important to understand that's sort of big-ish. Activities have a person. They have other people that are often around there. They have a place where they occur in and they often have other peripheral tools or other things that I'll use to make that activity go well. Boy, that's enough language. I want to do something. Oh no, I have one more thing here. I leveraged Alistair Coburn's idea of goal level to talk about how big one of these things is. In the middle is this idea of functional or C-level, something I would reasonably expect to complete before stopping. Eating breakfast is one of those. I don't stop halfway through eating breakfast and take a break. But I might stop halfway through and pay a bill depending on who I am. But eating breakfast is composed of other things like poor cereal and poor milk and pouring milk by itself has no value. And there's sometimes some order of pouring milk ahead of putting bowl on table has really no value. And some things are bigger like getting myself fed, maybe eating a bowl of cereal is functional but eating a bowl of cereal and getting cereal ready and making toast and pouring juice, things like that are all parts of it. I might jettison one of those tasks in support of this activity of getting breakfast. And above that and below that are big things or little things and big things. But when we think about what people are doing, the problem is people think at a big level. And if we're gonna start to describe what people do and we're all driving towards user stories here, I promise we'll get there, it's the important level where it's important that products work is at something higher than functional level. It's important that we think about experience or what people do at that level and releasing a piece of software or releasing a new robot that helps you get ready for ready for work in the morning but in this first version it only pours milk. Isn't as valuable as one that will make me a bowl of cereal? And ideally one that would make me breakfast is even better than that. So again, this is Alistair's idea of classifying use cases but I find it's helpful for me to detect whether I'm going in the weeds or not. As I'm writing user stories, for the person that was describing their day and had only gotten to the shower level, and I'm pointing at you, at some point detected you were in the weeds, correct? How did you determine that? I just felt like I was going through too many sheets of white paper and yellow paper. No, I mean, actually that's what I was describing more of a process than I was in abstraction and what difficulty I was in. Being aware of this kind of thing allows you to do a little bit of a test and say, are we talking in the weeds here? Are we talking up at a higher level? So we can steer a little bit of a discussion about things. So user tasks make ideal user stories. This is an assertion I'm going to make and this is where we start. They're about what people do and it's important for us to understand what people do and I can give a user story a title like take a shower and they fit cleanly into this. As an instructor, I want to take a shower so that I don't offend my colleague. So I can quickly slam them into that template and test whether they, yeah, so that feels like a good user story and I can write user stories about tasks or things that I do, like let's say as a weekend gardener I want to dig a hole so that I can plant a tree or I can write them about stuff or things that I need. As a weekend gardener I want to shovel so that I can dig a hole to plant a tree and I comb backlogs looking for shovels and are people talking about what they want built versus are people talking about real user stories what people are trying to accomplish? So how much have I deferred? Now it is 2.13 and we're going to take a break at 2.40 and I want people to start thinking about actual building up a backlog that is about user stories. It's a lot of people in a room and I've been talking for a while so before I go on, questions? A lot of information. Yeah, Joe, I saw your reason for distinguishing tasks and activities and for putting the activities at a higher level of generality than tasks, tasks are more specific than activities but I think in English there's a grammatical distinction between tasks and activities or actions and activities or acts and activities and you can actually do it any way you please and it doesn't make much difference which means that your way is as good as any way of doing it but I think for example in English if you say I'm walking, that's an activity. If you say I took a walk, that's a task. Yes. And if you say I am managing email, that's an activity. If you say managing mail, that's a task and I think that there's a grammatical distinction there between the two ways of putting them but ultimately there are quotes. If you are managing email, then you manage email. Yes. So it doesn't matter which way you go and which one you pick to be more general than the other one. I think there are quotes on them. So there's a paraphrase that, there's tangled grammar around this and I do often use this continuing form of a verb to indicate it's an activity to end it with ing so that it sounds like it's something that's continuing or it's a bigish thing. Don't know why, just feels better. But I've got a colleague who does this. This is just a way of separating big things from little things and maybe the point I want to emphasize is I've given a lot of details here. Try and forget everything I said. The colleague of mine says, Jeff, you just over-analyze this stuff. There's just big things and little things. It really doesn't matter. I don't care what you call them. I'm just going to call them big things. At the end of the day, what we're trying to do is detect a big thing from a little thing. And this is one organization mechanism that's worked pretty well for me and the trick is that it's also an organization that works pretty well for user experience design. If I understand what an activity is, I know that the tasks hang together and they sort of belong together in the user interface and it starts to give me a clue about the structure of the product from the outside as well. So it's a useful structure for that. So yeah, to your point, it's don't get tangled up in the definitions. They're not very firm in my head either so I break my rules all the time. So directly right behind me. I'm new to agile and so I'm also a developer and I'm trying to understand what I would do then with these user stories and what they interpret to what they will turn out to be. And what I'm seeing is there's a lot of focus on the tasks, the verbs, on the actions. Now I was originally trained in object-oriented design and developer now. So this is like blowing up all my concepts. I did not go to the session on personas and I wonder if you really have the tasks together with the personas and then you have a user story and then is this design agnostic or is this really gonna translate into the way I'm gonna design the software? Who are you? Table that. So and by design the software you're talking about the object-oriented design, the internals. And think about the system as objects. What am I gonna just start coding up algorithms for tasks, you know, like functional programming? We may come back to that a little bit later. We forgot to make the rant about design. Alistair's a good one for that. Basically if it's my decision to make is design, if it's not my decision to make it's a requirement. So decisions about whether the software helps somebody do something or not is a design decision but it's a user interface design decision or an outward design decision. And then subsequent to that we have design decisions about how we will represent it in code. So if I can cut to the chase a little bit, right now we're trying to understand a little bit about what the software is and does and drive to a position where we can prioritize and we're about to hit a problem that has us building an information kiosk for a record store. And a few of you who've been in classes of mine, you'll, sorry, you're gonna get belted with that problem again. But we will have a task like searching for a CD by its title and we will make a choice to say, yeah, that's in scope. And then we have to move forward from there in the life cycle of that story and say, okay, I've got to build some code for that. What objects do I need to build? I need a CD title and I need a way to look for a search for it. So I need something that's a searching thing and a method to search for that. So yes, it's later, but you've got to carry that work on after we make some decisions about what we're going to build. Might have been an unsatisfying answer. Okay, there, I'm not going to have you read this design problem exactly. Let's see if I can get it up on here. All right, on up here, I'm wondering if a couple per table, I can have somebody come up and grab maybe two of these design problems per table and two of these things that's an example user scenario. So you're gonna need two of each of these things and while we're doing that, when people get set down, I don't want you to read this two page thing, I'm gonna summarize it for you because it's fairly easy to think about. And then we want to, I want to do something to talk through the experience so that we can start to understand that as a potential story map. Okay, a couple people from each table. Okay, I want to talk through this just quickly because it's not that important to read but I want you to have it to refer to. We're gonna go through a quick exercise before the break at 2.40 and I'm gonna try this a slightly different way to see if we can get there from here. So let me describe the problem here. There is a fictitious store that I'm calling Barney's which was a scrabble name between Barney's and Borns and Noble and Borders and actually when I'm thinking of Barney's, is anybody familiar with Grey Whale's CD in Salt Lake? So I'm thinking of a smallish store that is packed with stuff. So Barney's has CDs and DVDs and games and Barney specializes in digital media and they sell new stuff and new stuff and they kind of pride themselves on carrying a lot of hard to find stuff and eclectic stuff and it's sort of a cool funky experience when people come in there. They can find a music aficionados or people that know what they're talking about when it comes to music or video games or weird foreign movies but there starts to be a problem that there's not that many people working there and if you want to buy something and you know what it is, you show up in the store and you can't find it and it's not exactly Barney's fault because CDs are hard to classify. Is this punk or is this rock or something else? Is this movie an action movie? Is it a mystery? Is it a romance? Is it a comedy? And it kind of fits into both and Barney's puts new and new stuff in separate areas of the store. If I find the right section, is it in the new section or the used section and if I'm not finding it, is it because it's not here or because I'm just looking in the wrong place and is it new or used? So people want to buy stuff, they don't have enough people to help them find things and people have to walk up and have them use the computer to look up things. So Barney's has the bright idea that they will save a lot of money or earn a lot more money if people could walk up to some simple information kiosk that looks like that and has a keyboard and a little bit of a mouse and they could type in what they're looking for and know if it's in stock and know where it is in the store so they could take a beeline to it and buy it and they'd sell more that way. So we want to describe a simple way for them to look up things. Now, when we were, well, let's think through here. I want to start at the goal level. So can someone, based upon what I was saying, what goal or pain or problem does Barney's want to solve? What is satisfied for Barney's as a business? If I increase customer satisfaction by providing a way for customers to find what they're looking for and whether or not it's there without a search of an analyst or something they can't find. Something, do you want to hear that? It was a very mission statement-ish. But it was right. So I was head on. Someone else had a hand up there. Maybe not. What does Barney's want to do? What's the itch they need to scratch? Increase turnover for obscure items. Increase turnover for obscure items or hard to, yeah. Sell more stuff. Sell more stuff. When we'd say things like sell more stuff and increase turnover for hard to find items, you'd sort of start to sense the decomposition in there. You see the same thing with goals as you do tasks. So, but Barney's has something they want to do. They want something. What kinds of people did you, when we think about people using this thing, can you name a couple kinds of people? Are they just users or are there different kinds of users? It'll be an employee who enters inventory. So there'll be an employee who enters stuff into the system. John or a fan, somebody who's a real fan of funky horror movies. It's someone who's an aficionado at things. What else? Who else or what other kinds of people do we have? The person who knows specifically what they want. Yeah, the person who knows specifically what they want. In contrast to browser. Someone who is just looking around today, trying to find something that's interesting. So what are these users, we talked a little bit about for our user, what are their goals or pains? What's their motivation for using this thing? You know, expedite their shopping experience instead of having to go to the computer in front. It's a little bit of expedite their shopping experience. They can, yeah, what can I say? Why is that important to expedite? Self-service. Self-service, so for people that don't really like interacting with those weird tattooed earring people behind the counter. Possibly self-services are better options. Any other, yeah. It might help them. If you don't even know what piece it fits into, maybe it's a good search, you can actually find something. You don't even know what it is, but you kind of know what it is. You kind of know what it is. It helps me avoid it. You can remember the title or you can remember the actor's name, but if you remember something about it. So I can imagine avoiding a bit of an embarrassing conversation with the... So I don't want to ask the tattooed piercing guy because he'll probably laugh at me. Yeah, exactly. You know, you can't say Neil Diamond out loud in a store like this. Right. And play backstreet boys on the line. Yeah, exactly. I'm looking for a Backstreet Boys album. For a friend. For a friend, it's for a friend. I don't know if this is covered, but, you know, the kiosk provides an opportunity for people to get information they may not otherwise know. Like what's new, what's... Yeah, they get information that they might not otherwise know, that what's new. And again, this is information I could only get from talking to a person and then, you know, maybe information that they don't even know. So it's giving me, you know, for people who want more information or are interested in more contact. So we can think about a lot of goals that people have, but again, this is at this goal level. So we have to think about what people need to do in the system to get it. And we need to start, then we need to start thinking about how people will reach their goals. Now, you guys did something this morning to think about how you, it was easy for you to talk about how you reached your goal this morning because you did it. It was past tense and you were you and you, ideally, you're intimately familiar with what you did to get ready this morning. And if you can't remember, there's other problems. But if we're building a piece of software, how would we figure out how these people reach their goals? What do they do? They walk out with something they're happy with so that we know at the end point, what are all the points look like in between that? And how do we figure that part out? Market survey. Second, market, market survey. You go to some place that has kiosks and kind of follow somebody along and see what they do. I'll follow somebody along and see what they do. What else? Sales. Sales? Ask sales or look at what's sold? Look at what's sold. Look at what's sold. That'll give us some ideas about what they buy, but it'll give us some ideas of what steps are involved so that we can build a piece of software that supports those steps. So I don't know, again, if this question is right, but you sort of take the end goal, which is user walks out with a purchase and then you back up and say, well, what are the necessary steps to get there? So you're sort of working in reverse. Yes. So they can't possibly walk out without putting something in their shopping cart. They can't possibly check out without entering their credentials. They can't possibly check out without selecting an item. So you work backwards from that goal. So we've got 10 minutes left and I'm wanting to hear you guys talk more than me, but we need some sort of to understand how we use a system to do something and write these sorts of stories and map something that represents what the system is and looks like. We need to start with some understanding of user experience. Now, we've chosen a problem here that's fairly specific. First off, does anyone shop in stores? Well, a lot of people, good. Does anyone have to find anything in a store? Good, good, okay. We can all imagine a little bit of what this is like. So we have an application here that we sort of built for self-substitution. We can track back from the goals. Now, if on the other hand we were building a piece of software for nurses to administer medication, it may be a difficult thing to work backwards from goals. Starting with medication administered, what was the previous step to that? Maybe a little tougher. So we don't have anything to think through. So we would need to talk to some people. One of the things we end up, I'm looking around for hands here, I'm gonna put on the screen. One of the things that's commonly used to think through what people are doing is a concrete user scenario. It is a description of what people do. Now, what I'm about to suggest in five minutes here is that you not write a concrete user scenario about buying something in the store, but you think in terms of a story. And I wrote an example of a user scenario here. There are some interesting parts in a user scenario. They start with a person. They start with a person in a context so that we can understand what they're doing or why they're doing what they're doing, what's important. And they sort of go step by step or task by task through what they do. And a scenario has a starting to try and imagine sort of vividly. It's a little bit like writing a novel here. And it contains interesting details. It contains motivations for why people do things. It contains some hints about what the user interface might look like or what it might have to look like in order to satisfy those. But it turns out writing one of these things is a good way of, after you've talked to a few users, after you've watched a few people, it's a good way to confirm that you understand what they're talking about. This particular scenario was one from a project changed slightly to protect the innocent. But it's going through this scenario where they say, oh yeah, you've got it. You really understand it. Oh, except for this part here. It doesn't happen that way. It happens this way. And no, we have a lot more people that we work with than that. And we correct some things. And it's a good way for us to test our understanding. Now, we can write down a user scenario like this after we've talked to some people. Or if we're lucky enough to just be sitting in front of someone, we can talk to them and ask them about the last time they did something. And if we're sort of clever about this, we can just sit down and write down tasks or things that they're doing as they do it. So this is going to be the tough part that I want to jump ahead. I would like you guys to work in pairs. I would like you guys to, I might change these instructions a little bit during a break here. But I'd like you to work in pairs. And this is going to be, I'm looking for people who are method actors. Is anyone a method actor? Your hand. Where? Good. I need one of the, in these packs are, there were a few simpler lightweight personas. But I want someone to be Carol. Carol is a casual browser. She kind of likes wandering around and looking for interesting things. And she doesn't know what she's looking for today. And I want somebody to describe or talk through the experience of being Carol. While someone else who's their pair sits down with sticky notes and a Sharpie marker and starts to write tasks as they go. Write some things, write tasks down. These are the same kinds of things that you wrote down for getting ready in the morning. And they're going to be, the person speaking may speak with context like the scenario. And it may be interesting to write a few things, but write a little bit about the context, but record these tasks. So someone being Carol, you could be Carol. I could be Carol? Yes, you look like a good Carol. And so you could describe, you have to imagine yourself as not having a specific goal and talk about walking the store, finding the kiosk. And then I enter something and talk very concretely. Say, don't say I could have or I might do this or I might do this and this and this. Say, I might have seen these options, but what I did then is this. Just talk as though you really are a user doing it. And say, speak concretely. I need somebody else at a table to be Isaac. Isaac is an impatient buyer. He knows exactly what he's looking for. And I'm missing a T and want. He wants to find a specific hard to find for and fill. He knows what he's looking for. He doesn't have a lot of time and really does not want to talk to these flaky people behind the counter because they're posers and he's hipper than they are. So be Isaac and talk about finding this kiosk and talk about the things you would do to go through and the person pairing with you trap tasks. We've got about five minutes to do this and I'd like you to have a five minute conversation and see how it goes. Any questions before I let you go? So, Rick, into pairs, one of us is Carol, one of us is Isaac. Yes, one of you is Carol and one of you is Isaac. Talk about things or discuss things and I want you to not, in this slide, it says write out a scenario and you should have an example scenario somewhere at your table so you can see what it looks like. Don't write out a scenario. Let's go straight to writing these yellow stickies with simple verb statements, what people did. So I searched using the title name. I saw a list of movies. I checked to see if it was in stock, things like that. Yes. Just to get an understanding, at each table, is there a full table for one pair of pink carols? One pair. Yes, at each table, it's self-select and if we end up with a whole table full of carols then I'll, so yeah, at each table, take your choice who you want to be. This will go back. Okay, first off, I know I, well, I saw some people doing really well and some people, it was kind of a hard or a different conversation to have. Somebody who had a productive conversation and can say something about it, I'm not shocked about that at all. How did that go? What did you get out of that? How many stickies did you write? Let's get the metrics here first. One, two, three, four, five, six, seven, eight stickies. Eight stickies? Can you read me around a round of sticky? And I'm gonna guess what it says, normally good. It's a face of clubs. What does it say? Distinguished by actor or director. Distinguished by actor or director, so by distinguished by actor or director, you mean you were searching for a name of somebody and you wanted to indicate whether it was an actor or director. Yeah, that would tell you. Were you being Isaac or Carol? I was being Isaac. You were being Isaac, so as a patient buyer, I want to refine my search by entering a name and indicating whether it's an actor or a director. So I can fashion that into a specific story. It is kind of down in the weeds. Search among various translations on titles and extrapolate near misses to the real title. Yowch, that's an epic if I remember. Jeff, it starts with a verb, so it's okay. Yeah, it's a big verb. So how did the conversation go? Is it, did you get more or different kinds of stories from this kind of conversation than you would normally? I think so. Who had a non-conversation or a dumb conversation or a bumby conversation? I don't know. What was that? We definitely had a dumb conversation. You had a dumb conversation. What did you write down? You wrote something down in your dumb conversation. Well, we had to go back to the beginning and kind of start over again because I left the posse out of this. I actually went up buying a bunch of pennies and Starbucks. That's not a good one. That's a bad one. That's a good one. That's a good one. That's a good one. That's a good one. That's a good one. Yeah, since you know, what's my motivation here? I'm feeling like a copy now in the stories. So in the things you wrote down, we're really about interaction with a kiosk or finding a thing. Yeah, so we kind of had, you know, brows the sword a little bit and that is kind of catching interest in the kiosk. I was playing kiosk. That was obvious. So, I just started browsing through genres and noticed that an ad for a specific book that the book store was promoting, read the description, saw that there were ratings and reviews, read some of the reviews and then got the directions and he actually bought it in the store. So you, Carol, are you wiser? Yes, you look like a Carol. Maybe you're probably old. But you've got actually good user stories. Yeah, so these are the crap. And these are the stories. So, you know, as a casual browser, I want to read the description so I can see if this is a movie or a thing I'd like to buy, a title I'd like to buy. As a casual browser, I'd like to review ratings and reviews so I could tell if this was interesting. These all passed the story template test to see if they're good and I know there are some good things about experience. All right, we want to take a break right now. We are eight minutes and 31 seconds late and we're supposed to come back at three o'clock, come back at three o'five where we will then talk about how to build a story map and how to plan and how to drive through development of a kiosk that satisfies lots of people.