 in the middle of the room and then possibly it's that shower thing, but the truth is I did do an awful lot of talking and this is an awful lot of reflection about user stories and what they're used for. We are going from now until 4.30, what is our time we're supposed to be done? 75. No. 4.45. 4.45. Roughly, I guess. Is Alistair still on the floor over there? Alistair gave me a piece of advice years ago when it came to teaching or speaking. He said start late and end early. 4.45. So I'm going to set an alarm for something that I can live with to warn me. What was that? I have an app for that. There's an app for that. I want to talk through a few concepts and I'd rather, I've got a lot that I want to communicate and say, but I want to see if we can contextualize it just a little bit. So let's start from the beginning. This slide deck would go through a bit of a process of having us think through and write a user scenario and then as we were writing this user scenario we can extract tasks from it. It's the thinking through what people are doing that helps us find what people, what people are doing, what actions they're doing. So the way you guys did things by talking with each other and writing down stickies as you went is actually the way that this is commonly done. There are these little quick reference guides that I quickly put together yesterday to try and describe a little bit about how this works. The front side has just a little bit of a taxonomy about what I mean by a story map and what are the concepts or what are the things in it. And on the back side is a little bit of a process. So where I want to go through now is talk about a little bit of a process. Actually, before a process, let's talk about composition really quick. I like organizing these things into maps of what the user's experience is, map of what people are doing, of what, from a user's perspective, the system is about. And of all those constituencies wanting to get things out of user stories, I end up thinking from a user's perspective an awful lot. And I end up, my dominant concern actually starts to be understanding the user. Now, because I'm concerned with understanding the user, I like organizing things by stuff that people do. And the biggest thing or a big-ish thing that people do are these things that I refer to as an activity. Now, if we were to speak abstractly for a minute, if I were to arrange doing stuff in my house by activity, I might have things like taking a shower and getting dressed and eating breakfast and doing stuff before going to work and then going to work. And that would be a map arranged along those big things. Now, if I was thinking, if that bothered me, I might start to arrange things by the structure of the house. I might start to arrange things by bathroom and bedroom and kitchen and garage. And that's, I can still sort of get that. And the only reason I can get that is because I happen to live in a house and a lot of other people do. And if I was really getting technical about it, I might start to arrange all my stories about a house into plumbing, electrical, heating and air conditioning. Yeah, I must be driving people crazy. You got to step on my iPhone. I could arrange stuff in my house by plumbing, electrical, heating, air conditioning, things like that. So for folks that have user story backlogs, how many have a big epic called security in their backlog? You laughed. Is that common? I've seen it. So security is often a big thing that people organize backlogs by. What's another weird, big thing that people organize backlogs by? Bugs. What was it again? Bugs. Are you talking about the cross-cutting concern? Well, is it a cross-cutting? Yeah, exactly. Is it a cross-cutting concern? Just like, again, I'm talking about different organizing mechanisms. A cross-cutting concern in a house is plumbing. And for someone who is a contractor building a house, I'd want to separate out all those plumbing things. But from a user perspective, plumbing really isn't... I don't get up in the morning, wander to the bathroom, and think about the toilets as a cross-cutting concern. It's something I need right here now. And security is one of those things that kind of hits you or is relevant at different times in the system. So, yes, it is a cross-cutting characteristic. But sometimes the temptation is, in the absence of understanding where security is relevant, we'll organize things that way. Let's... Oh, sorry. I had a product owner on a big project come to us and hit us with a whole bunch of ill-ities. You know, reliability, you know. And security events and all like that. There was a reliability story. There was all these different ill-ities that came up that were just monsters. And so how did you attack decomposing those monsters? To be honest, it was really kind of going back and saying, wait, we can't work with these. Let's look at it from a different perspective. Slicing differently. You would reject it, though. Good tactic. A tactic that works for me sometimes is tell me a story about where reliability is really important. Give me a concrete example, and it's back to the storytelling we're just doing. And this is also something that resonates with Brian Merrick mantra is an example would be handy right about now. So Brian Merrick's example-driven thinking is exactly the scenario-driven kind of thing that we're talking about here. So where scenarios are concrete examples, but they're concrete fictitious examples, when we're talking about reliability, then we can start to find out where and when reliability is important, just like when we're dealing with security. Tell me about a situation where security is important. And then we can start to actually find stories that are about people and where they're relevant and ways to test that they're there. And to spin through the structure of one of these really fast, the structure of one of these things is at the top or the highest level are some sort of sequence of user activities, stuff that people do and they're just big things. And as a colleague said, Jeff, don't get wound up in what they are, and I'll tell you don't get wound up in what they are. They're big things. They're epics. They're whatever you want to call them. But they're big things. I like activity because it works for me. Below big things are less big things. And for me, these are user tasks. These are bigger things that people end up doing. And when you're arranging things left to right, just like when you tried to arrange things that you did when you got ready for work this morning, there's no right order. People don't do things in the same order every time. Arrange things in an order that helps you tell the story. These are a token for a conversation. And we're building the mother of all tokens. So build something that supports a better conversation about what the system is and does. When I find some tasks that occur roughly at the same time, for instance, if I'm building a kiosk and I might search by artist or search by title or search by a combination of genre and language, I can start to pile tasks below each other because there are variations or alternative ways I can do things and start to build down. But I find that in practice, people just do things kind of in a nice, organic way. And so the important thing is that when I'm done left to right, I have something that I can see and understand that describes what the product is, that is useful for telling stories about the product. And I've got this functional decomposition. I've got this big things and little things that fall inside of it. So I can talk about things at the level that stakeholders might prefer to talk about it, which is at a high level. And I can talk about things at a detail level. In practice, a long conversation, a day's worth of conversation results in a model that looks a little bit like this. That's Gary and Gary and I talked for a day about a product and the product is on the web now. It's something called madmeme.com. Meme was originally supposed to be Music Industry Marketing Interface. It was something for musicians to market their work and collaborate with other musicians and that's where the term Meme comes from. But at the end of the day, when we talked about his goals and what it was necessary to get to market, this ended up being just an e-mail promoting product. It's something that competes with constant contact. It's actually an extremely cool little product and it's pretty well reviewed and it's newish. And there's a competitor to it called Emma. He kept the name Meme because it looks like Emma's mean little sister. So the product was good but at the end of this, Gary saw, ah crap, what I'm thinking about is really big. Before we did this, had this conversation, he had no sense of how big the thing was he was thinking of. He had a lot of grounded ideas and interesting things and he'd been actually working with an agile team for several months and doing highest priority story first and he said, you know, these guys are getting nowhere. These new stuff arrive and it's just not it. It's not getting me where I want. And having this conversation was a bit of a breath of fresh air. In practice, again, it's another kind of a big demonstration. This is a big, long, wide model of taking photos all around the room. The thing on the bottom is that strung together. So it does end up being big but where I've seen, one of the problems I see in traditional story writing workshops is who in the room has done a traditional story writing workshop? How long did they take and how many stories do you normally get out of one? Well, in a few experiences they took upwards of half a day to a day and we ended up with somewhere around 400 to 500 stories in those cases. Good. That's a lot of stories. Yeah, I'm not sure good is the word I'm talking about. Yeah, exactly. In hindsight. Wow. What is the SPM on that? The stories per minute. It was brought in. It was bringing in product owners with a lot of this sort of already, they had lists and basically taking their lists and turning them into these stories. So this wasn't necessarily the dynamic of the customer conversation. Yeah. Different kind of dynamic. It was more of an offload of a dump of what they had. I had a completely different experience. I'm talking about a group transitioning to Agile who brought in a product requirements document to spend a better part of a half day and have 20 stories out of it because that's all they could do without getting frustrated. Yeah. So a lot of times you see things on the opposite extreme as well where when you're trying to get someone to understand this concept, they struggle. So if you try to get someone to understand it, you end up getting 20 and my guess is that when you got 400, no one was focusing on understanding the stuff. Let's say there was a lot of waste. There was a lot of waste, how so? Well, because many of those stories were never going to be implemented and they were hard to manage. They were very hard to comprehend. So we create a monster backlog which other people will argue that that's bad. You know, in lean terms of something else. Yeah. So why would it be such a big backlog based upon what we've talked about today? Well, part of it was just the organization had all this stuff stored up and we were transitioning them and it was kind of their sort of cathartic. I think that there was a lot of fine grained things. Yes. There were the... Where's the guy that took the many-step shower? He's gone. I can't tease him anymore. But there were a lot of those sorts of things. So it's tough to make sense of 400 of anything. So what I find in practice is that days worth of doing this or half days worth of doing this is very productive and you end up with more stories that you understand than other mechanisms and certainly less than 400 stories. So the magic number for me is somewhere in the 100-ish range and of course it depends on how big the product is. One of the things that naturally happens is you're starting to build these. If I were to give you a list of anything and tell you to arrange it, people start to naturally deal with... Ah, well, I'm sorry, I'm skipping to a different sort of slide. Actually, looking at process... There is my... This deal is... I set aside the one that I've got. So I find that there's an initial kind of constructing this thing that goes on and I wrote down in this quick reference that there's three ways. In process I find that if we know users and we can collaborate with them, we can sit across and we can write the stories as we talk to them. We can collaboratively write stories. So I'm calling that a user interview method and that's what you guys just did. If we really know the domain well and it's just stuff we know and we can rattle off or think through them, we would brainstorm tasks that we do and then organize those. That's what you started doing by everybody brainstorming what they specifically did and I find that when I've got domain experts that know the room, I can just say, okay, let's think about this particular user and let's brainstorm everything they do and everybody can dump it out and then we can organize it. And then finally, if you the people that need to organize this backlog actually aren't your users, don't know your users and can't get them to sit across from you to do this, you're left with needing to do something to understand them, to research, to observe, to do something else and then to get your understanding straight, writing something like a user scenario or a use case or something to understand the narrative words. In the past, I've struggled teaching this because I'll try to teach it one way or then another way and the truth is there's lots of successful ways to build these things. So the slide there is about the discussion and the truth is that discussion is the way that I fall back on most often in an agile context but the discussion requires that you know what you're building. The really cool thing about starting to build one of these and use cards and lay it out in front of people as you're working is they catch on so quickly it's shocking. I can remember sitting with a compliance officer at a big drug company and writing down something she said and her telling me, no, no, no, that's on a purple. It's not on a green. She knew what I wrote down wasn't big enough. It was a bigger thing. She already had after us talking for 15 minutes she had a sense for how this worked and could start to have, we had a richer conversation and as soon as I start to get this thing left to right it enables fabulous words and conversations like this and that and over here and down there we and up there we did and we start to have really quick conversation where a conversation around a singular card just isn't that way. I find that once we build these things it's sort of cathartic, we get it all out there but we end up then needing to go through a bit of a process of discussing these things. We'll walk through these things and talk about them over and over and we'll get more and more details and sometimes they grow to backlogs of hundreds and hundreds and a trick stolen from Ward Cunningham for CRC cards is to write down everything they say and then shovel them underneath the cards and when building a sticky note model I'll write down a lot of sticky notes for details put them all together and put them underneath a top sticky note so that I can just focus on the hundred but not lose the details. So we do a lot of shoveling, writing down really small details and maybe using a different color of card build this right for little details and then sliding the details underneath ah, darn, built too fast just a photo there is of somebody doing this in a bit of a training class you can see yellow cards slid under green cards it's a nice trick for pulling the conversation up a level and the reason this model is so moronically simple is because it's really easy to drag it all together and put a rubber band around it and stick it in your bag when you leave it doesn't have to hang on the wall the slides will be available to download okay now here's where it was going there is a natural tendency for people when they've got stacks of anything to put important things at the top we keep talking about those important things and they naturally bubble up so whether you want it to or not things will start to arrange themselves vertically in these sorts of lists and when you start to do this explicitly you start to see that stuff along the top is really important and if we were going to build the system it really has to have support for this stuff on the top that's the necessary stuff you can test this by walking it and telling stories about the domain and I end up using a well the users might do this as a bit of a test because if it's low then it means that they don't have to it means that they might and I'd asked somebody about somebody who had picked this up and done a bit of work with story mapping and I said well what's the thing that really worked well or was really important for you as a take away and he said well that walking through it and talking through it thing was really critical or important to us and I would have never guessed that but the testing whether things are optional or necessary turned out to be pretty darn important for them and the walking and talking part is I find that in practice we'll build one of these things and we may build it in a day but then we will walk and talk through it with lots of different users and stakeholders for weeks afterwards and we keep harvesting it and building up more so there's a second step on your hand in that says fill in and validate and I find that that goes on quite a while so if I can just for color this ends up being a little bit like one of these this is one of these conversations over story map and the conversation was Brian is the guy talking and the guy's name writing the sticky note is Sparky Sparky is writing down stuff that Brian is saying and in particular we're trying to write down stuff that's really difficult for Brian where is his work a problem and so now we can have you don't have to have Brian tell him about his process we can have him talk through the process and we can start to talk about what's difficult here and you notice the rich conversation and big hand gestures and productive conversation about the system between somebody who is an analyst and someone who's a user and the guy drinking coffee at the back is the lead developer and he's really trying hard to look interested at least he's there anyway so these are good conversations and now we're all on the same page about this when you start to raise these things by priority you end up with a couple of important anatomical components of a story map the things at the top are these absolutely necessary things these are quick ways to talk about the system end up being what I refer to as a backbone which is a term stolen from another person who uses it slightly different the backbone of the application ends up being these core capabilities these things that we need to have in the application what's important about them is they're big and they're stupid to prioritize against each other if I were to boil down the necessary big capabilities or big things in a car I might end up with engine and transmission and brakes and a dumb question for me to ask you is what's more important the engine or the brakes can you prioritize these for me what ends up happening is we start to prioritize things underneath those things and the stuff at the very top the stuff that we absolutely need to have ends up being what Alastair Coburn refers to as a walking skeleton if we were to build that part of the application we've got something that demonstrates end to end functionality we've got a car that will drive us to work it may not be the car we want but it's functionally complete in some way I'm going to skip over that in the handouts but there's a lot of things that you do when you're walking through this stuff so any so here we could have you build this thing and arrange a story map who has energy for that not us not good speaking it's a and any questions about that sort of stuff before I move on sort of like in Alastair's nano-development thing yesterday we're saying that developing a nano-reference can lead to really bad code if you design stories for the minimal car that will get you to imagine it's sort of like you know, geo-metro with no body panels and is that really a suitable skeleton for growth as you build out if everybody knew the question is if we built the minimum for everything you know, if we were to want a Mercedes, I'm going to start to paraphrase you if we were to build a geo-metro with body panels missing it may not feel so good it would be sufficient it would cover all those basic things we need to drive to work but it's not good so do we address that or is that more of a software engineering issue we're really talking about the user experience and gather requirements we are talking about moving from this understanding of people what they're doing and starting to as soon as we start jiggling things around my necessity we're starting to think about what they absolutely need to do to succeed and then we start to think about what happened here we start to think about what we absolutely have to build or support so mark that and yeah, actually I want to come to there's some of my slides are a bit about best of here you're talking about an aspect that referred to as I don't refer to it, we'll talk about subjective quality in a minute what quality is for me who wants a car I don't care if I have a geo-metro that doesn't break that's not the kind of quality I'm thinking of when I want a Mercedes every folks seeing the planning onion before who has seen this model before and wants to give me a basic definition of them that isn't a certified scrumtrain anyway can I pick on you no okay you've seen it because you've heard me talk about it okay so anybody can somebody give me a quick thumbnail of, yeah please starting with a vision and then a milestones or a roadmap and then going out is that the kind of thing you're talking about it's what a PMI people like to think of as agile developments, rolling wave planning kind of thinking basically there are layers of planning that we end up doing starting with understanding something about the product and its vision moving down to something about incremental releases or what we release and then moving farther down to talk about what we will build in the next iteration or sprint and then I put at the center of my planning onion the user story where some people put the day inside of there to plan what we're going to do today but for me as someone who's thinking about the product and what I'm building the sprint is composed out of stories or the iteration is composed out of stories so we have lots of different layers of planning that we need to go through and so what I want to focus on is this release thing the release thing is the thing we put in front of people and it needs to deliver some benefit or some value and I couldn't deliver a car even if it is a geo metro without engine and transmission and brakes now I could develop a sprint with little bits of stuff I could build an engine in the first sprint and I could build a suspension system in a second sprint but I certainly couldn't release without it so when we think about release planning we need to think about slices of value or slicing about what's beneficial and I started using this sort of approach and what happens is you start to really see what the stuff is that's valuable by being able to quickly cut slices through it I found that in practice I used to cut weird slices and they would come out a little bit jagged and things would cross over things and the models looked a little bit weird but I found it was really easy to start to facilitate an activity if I just took a roll of tape and started putting tape lines across there from left to right and having people start to juggle or move things up and down so this is a butt ugly story map after working with some folks and prioritizing and annotating things and attaching estimates and attaching some notion of what business benefit is and it starts to get decorated with a lot of valuable information but it's still a place where we can have conversations about the whole system each one of those vertical slices is a bit of a release so we end up starting and arranging the top, the backbone the stuff that is kind of durable and then moving from that backbone to an arrangement of stickies that lets us know what's in a first release, what's in a second release and what's in a subsequent release and right away you can see how fat each release is relative to the others and how difficult it is this is a bit of a play by play from doing a large collaborative release planning exercise at an insurance major insurance company the person who is the product owner that knows this backbone has written all these stories, starts by laying out a big wall and she printed these out on white paper so they're a little rough to see but it's going to get a little crowded and getting the basic structure of the organization of the stories arranged after getting them organized, she talks through them, she'll talk about this is the experience someone has of selling a policy and making a claim and this is the basic, these are the big things that people have to do I hear a question bubbling up then everybody gets a stack of stories and they go to work piling them in or filling in the structure now she knows where they go and she's not putting them there, if the whole team puts them there then they know where they go, now they understand where they go and once we get them into the basic structure and we start to have this sort of inverted cityscape thing we talk a little bit about them and fill them in and then the tape lines come out and we say okay we've got to build this thing in some series of incremental releases these are our general goals for each release so where should this go and this ends up being a big collaborative activity punctuated by strong discussions around specific areas and lots of beginnings of decoration of estimates and dependencies and other concerns that people have and at the end of the day we end up with what feels like a release plan that we can live with that was built collaboratively so that's the way this kind of planning goes when you've got to one of these folks done any similar planning sorts of activities before anybody this looks more grown up, I'm glad you did the common mechanism of just sort of arranging things left to right by release order and that's a good common way but we start to lose the plot, we lose the structure so this is planning on the back of that structure and seems to work, people can look across the structure and they can imagine a whole product based on everything in this left to right lane and it sort of speaks to them I've generally used in or out for the next build and this is better because out feels, to the business over out can feel really not good we're going to talk about the person for rally and we're talking about the puppy so you just put it down on the bottom there it's okay people will keep track of their puppies because this is big and spatial people can still see them they're there so there's a secret to prioritization before I go on what is the secret good prioritization important stuff first okay so anybody else have any tricks to prioritization negotiation everybody else out of the room send everybody out of the room and call them in when I'm done having the right people doing the prioritization yeah what makes people right basically the ones who key stakeholders key customers the people who are going to be the ones saying yay or nay sometimes it's technically we actually we're going through a process right now for IT prioritization so we can balance operations with project work so we've done through a huge process over several weeks figuring this out and after the first couple we actually need to technical people in the room because the people who are on the business side although they can say these are business drivers we didn't have enough understanding what technical people were doing on their side to be able to fit the prioritization into a real time, real world that's right so sometimes it is you need those people in the room that really knows where the business benefit is exactly right but sometimes I just stepped through with the insurance company lead developers were in there the business person kind of knew what they wanted but they didn't want to suggest anything stupid they knew they had to hook up to rules engines for determining policy pricing and there was a lot of and they were trying to release in multiple states and multiple states have different rules and we got to figure out which states to roll out before other states there was a lot of technical junk they just didn't know so it needed to be a little bit of a discussion so my trick for prioritization is the idea of not thinking about the functionality back to this gold task tool thing is to try and distill and name what the business goals are what does the business get or what's important to them and I coach people to these three vocabulary words have been kind of valuable to me and they were laid out doesn't matter who they came from but output is what we build the stories are often times about functionality or things that we're trying to build and it's difficult to prioritize output so at the end of a release we will have some software but outcome is what I get after the release that's what I hope to the benefit I hope to get from a business perspective and impact is the longer range benefit I want to describe this these three terms was talking used as an example what is the organization who are the guys that the kid band that wears these rings on their finger that pledge chastity or the Jonas Brothers what is that organization that does that Disney you've seen the South Park episode there is an organization that promotes abstinence and that's the US government a lot of policy supports that they had come up this particular organization had come up with an idea that they would have what they're referring to as an abstinence ball this was a nice kind of a daddy daughter event where we would invite fathers and daughters and they would come to this kind of a black tie affair and they would show up and it would be a nice uplifting sort of experience where bonding experience for fathers and daughters and they would make this pledge and both fathers and daughters would wear a ring and this would be a neat event to kind of commemorate this pledge so they came up, they had the idea of hosting these and hosting these things and the output for them was sort of the execution of these kinds of events and the outcome by all respects was good people showed up, they were well attended and people really loved them, they had a great time and everybody said on the way out and later this was a great experience for them and they would definitely do this again and they proceeded to plan more of these sorts of sorts of balls and what they were shooting for was this good positive outcome there was a problem though after doing some research a little bit later they found that the teenage pregnancy rate for women girls who had attended these balls was higher than women who had not attended the ball so while the outcome was good the impact was bad so I find that a lot of organizations are struggling with strategic goals, we want to have better customer service and we want to improve our net promoter index the thing that causes customer to recommend us and then we have these short term tactical things we want to stop customer service from getting so many damn calls or we want to get rid of the bugs in these areas or basically getting rid of the bugs in the areas is output but basically we find that we are juggling sometimes different types of things one of the things I focus on is just getting people to name those things these I'm sorry I don't know, the one with the output outcome in your model the impact is something that people think about in advance or this is something that we learn you know, there seems to be if the outcome that I want this kind of thing or another in the market would I be also speaking about an impact for example another result we should be the dominant player or the or would it be something that I learn just as an example with the fathers and the daughters as things evolve how much of it is preclin or vision and how much of it is the feedback that I get once I have my outcome so how much of that is envisioned and how much of that is emergent how much comes out so we'll answer the question first of all both output and impact are not something you can there's something that they're very lagging indicators I don't know what the I don't know what the real output impact is until later that's the nasty thing about them it's easy to measure velocity and story points complete it's difficult to measure output it's incredibly difficult to measure impact or it just takes a long time so yes there is emergent output outcome and impact but in the example I gave they clearly went about it with the idea of what the impact the impact was their strategic goal as an organization to reduce teenage pregnancy rates cause people to make better decisions about premarital sex they knew that that was their strategic goal so it certainly was a target and they chose the thing to do these balls as a way to drive towards that impact and it missed but they only knew that a long time afterwards and I find that when I'm working with stakeholders to talk about a little bit of a model like that they often come to me with we've got to build this feature we have to add this capability to the system and you need to pull out your y-stick and you need to start poking what will you get when we build this when we release that what's going to happen and we can start to understand what the outcome is and some organizations are kind of in tune with my strategic things they can name those so we can ask the question how is this helping us meet this strategic objective I'm not sure if I answered your question but you there's no simple answer there's no simple answer so what I would find my trick or secret to prioritization is to push people up and to talk about something other than user stories to talk about the benefits that we're trying to strive for if we can name those benefits or those things that we're looking for and we know that some of them are short term are outcome centric and some of them are long term that they weigh in on strategic and sometimes there's a bit of a benefit soup going on with any product if we can just name them we know that good benefits eventually result in our organization saving money or earning money and a good if it's articulated well describes something that's relevant to this product this big benefits like earn more money is not so specific for the Barney's example we were discussing there's a lot of ways to earn more money there are we could launch better marketing campaigns we could hire people with less tattoos we could do lots of things but we want to articulate a product goal that says this chaos is going to earn more money because it's going to stop people from leaving without finding what they want so at some of your handouts there is a I didn't print out a lot of these but they're available someplace there is a page that has product goals a candidate product goals for Barney's those give an idea of the simple one sentence things that I seek to describe to help people prioritize and going deeper we can start to ask the question if you're realizing that product goal how would we know it what would we see change in our environment and again more cash in the bank is a trailing indicator it doesn't help so much sometimes these measurable product goals if we can understand them sorry page too soon here if we can understand them we can start to prioritize towards them if we can name six or seven or eight of these things and have people rank these product goals then we can say okay well in the first release we want to realize these one or two then we can start to deal with building a bit of a product roadmap because what's necessary is necessary with respect to what I'm trying to achieve a lot of dog my just spat does anybody has anybody done anything similar to that when they're trying to deal with prioritization yes no more roadmap never at this level it doesn't have a roadmap do you think there's a couple slides in the deck that deal with this hierarchy we know that we have business goals and those business goals require that people use our software and those people will do things and we will figure out what we'll support them doing with with user stories about the tasks that they're doing and when we start slicing things up into incremental releases what we need to be sort of aware of is that we are slicing top to bottom if I slice off a particular piece of scope I need to talk about what can users not now do with the product and are there different users that we're serving are we taking some users off the table so I find it's a lot easier to prioritize business goals and user constituencies that it is to prioritize user stories but if we don't have language for our business goals or language for our users it's extremely difficult if we can't say that at Barney's to really solve the problem we need to deal with impatient buyers first and casual browsers later and so we will build a user interface that allows people to find things when they know what they're looking for and we'll deal with these kind of meandering with the product in a subsequent release you're talking about software at the bottom level use at the second level user constituencies at the third of the business goal yeah where is the business case for building the software for a particular use in particular constituencies come into play as a way of achieving those business goals so where does the business case come in for building the software this way for this constituency to achieve these goals how do I have a good answer for that frankly not for me personally I go into I walk into organizations who in their organization builds business cases for their software does anybody doing that no hands who is still here so nobody's organization builds business cases for things so the vertical lines that you've drawn aren't those somewhat of a channeling station of that do you have to make those decisions for this version 1, 2, 3 what these are you just turned it 90 degrees off what you have on the board how's that for cognitive dissonance how you're making those decisions is okay somebody in marketing somebody in sales these people are collaborating together as we show this picture and we're moving stickies for a while until it starts to gel and solidify and stick it there because it supports the business case I'm not sure if that's what you were even asking but that's what I was drilling out of that it's the question how do you know to the extent or how can you recently believe that building the software 10 to 10 release one there building release one with the activities and tasks for that use and that constituency that slice of the bullet how do you know that or how can you reasonably believe that is that a crapshin all software this is a mantra in the agile community is prioritized by business value I'll make a bold assertion that the business value of software that never gets used is fairly low and we don't get value from software until it's delivered and used and all estimates of business value are a crapshoot we are always making a hypothesis that someone will use it and it will generate the value we expect so what I find in practices organizations have these business cases drawn up and they're absolute crap they sort of obfuscate what's going on with lots of bogus ROI numbers and bad assumptions and no specifics about who will use the product and things like that and they're often impenetrable so what I find is that I get ahead by pushing and often times when they engage in prioritization discussions they're working at the leaf node level or the bottom of this stack or at big pieces of functionality if we can make if we can build a backlog of business goals and prioritize those we get farther out of that of being fairly short statements about what the benefits are that we'll get you go to an investor and he says well I want to make money with this investment and you just said earlier that there are lots of ways you can make money I mean you used the example of parking store but there's a lot of ways they could make money improve parking plan you can ask the same question about reaching the business goals maybe there are a lot of different ways they can reach the business goals you come up with one product roadmap what's called that you think will lead to those business goals but why is that even better than the other one I mean don't you have to have some kind of what you're doing is making your hypothesis visible that's all and that's all I'm suggesting let's have the conversation about it before we start prioritizing prioritization fistfights often are because we have different hypotheses about where the value comes from so let's go let's talk about that specifically so that's all it's the best well it's the best answer I've got and frankly it's these discussions about where the business value is coming from in most organizations that I participate in and it's been a few by now are wacky crazy discussions that have never happened before now so it's a it's a good incremental step so though I'm sure there may be methods here some of it says plans are bound to fail but that doesn't think you should that's correct so if I argue that having a business phase for achieving the business goal and you fail but that doesn't mean you don't do it that's correct it could be a good thing to do and what I see is people not doing it or doing it in a way that's if stories are a token for a conversation and I want to plow on forward but this is an interesting this actually is a thing that I spend a lot of time ruminating on is if stories are a token for a conversation about what to build beneficial to us as an organization and if it really is one of these boundary objects that's a good token for a conversation what do I write down so that it facilitates a conversation between multiple people between people who know why we're building things and people who know how we're building things and that's what I'm sort of shooting for is something outside the backlog and it's as perfect as stories are which is not well through really quick the last sort of statement in here is that and this is kind of in the quick hand out here is I find it very valuable to build a roadmap that's composed of not the stories that we will ship each iteration or each sprint or excuse me or each release but what the benefits are for each release so my quick roadmap recipe is to give each release a name and then in a sentence answer the question what does the business get or what outcome or what benefit do they get after each release and what do users get after each release this is the thing we'll prioritize by this is the thing we'll make decisions with and by let's say what I mean by that we might have prioritized for a variety of reasons but if we can distill back up and say what's important why are we building this release and then we might bullet list some big stories or big pieces of functionality or at least it was off target if it didn't get us this benefit it's not on target if it delivers the functionality it's on target if it delivers the benefit so we draw attention to the right thing for the right discussion I'm going to go into a little bit of a best of and we're going to go to the last box in this thing and this is on construction and I want to before I move on I'm doing a lot of talking and this is very extremely self-indulgent for me to talk about there and any questions before moving on folks seen that everybody seen that particular model with traditional software development and it's dsdm that talks about this idea of and it's bleeding off the slide on the left of things being fixed and estimated we fix scope when we launch into a software project a traditional approach might fix what we're going to build and then based upon that seek to estimate how long it will take to build and how many people we need or how many resources we need and the idea is that in agile development we are trying to flip or invert that triangle we're trying to fix things like the time we'll fix the release date and we'll fix things like the number of people on the team or how long it will take to build but then we will estimate scope which is pretty unfulfilling the stakeholders at that sort of thing but if we sort of get through our heads that what people aren't fishing for is scope people are fishing for benefit and by doing that articulating the roadmap as a series of business goals or outcomes we have leverage on scope and when I mention this is how we make fine-grained prioritization decisions and as we edge into delivery this becomes extremely important we need to start as we dig in and elaborate these stories and have more conversations about what they mean exactly we can keep asking the question how does it get us this benefit I have to tell the Kentucky fried stick chicken story I can't tell but go ahead I kind of like to call shenanigans on that one I'm looking for more people to call on that just changing the terminology for the same conversation which is the one where the team says we can't deliver the scope that we thought we would and what do you want to sacrifice that horrible conversation that almost mentally occurs when you have fixed the time, fixed the resources and the negotiable thing is the scope I'm not sure it matters whether I call it business goals or I call it scope I know the thought I'll give you a couple tangible examples of how we've used this kind of idea that's helpful so it is important to name these things I've talked a lot about folks heard me talk a little bit about the what's the difference in agile development we say iterative and incremental and awful lot does anybody have a definition that works for them on those two terms or do people see them as kind of muddy and blended it's about good to hear from you back there I see them as kind of different just because increment tends to say we're going to take chunks and do it whereas iterative is almost like a loop it's almost like an incremental loop where you're going to look at it go back and re-evaluate look at it and go back and re-evaluate so you wind up doing a lot of rework in an iterative approach and an incremental is kind of like one idea chopped up and has multiple ways is everybody by that definition that's a good definition and increment is doing things a chunk at a time and iterating is rework but the cool new word for rework is refactor so it's okay oh except if you're making the code better it's refactor if you're making the interface better it's rework so there's no term for that sorry so the quick visualization is I see a lot of teams suffer from purely incremental thinking they start with a vision or an idea of what they want to build and we break things into time boxes and we build some and build some more and build some more and build some more and at the end we finish everything is fabulous and it's great but it does require that we have a really strong idea of what we were heading for and it does require dead accurate estimation both of which are trivial correct? so what we seek to do is to take a more iterative approach and that is the idea that we will tolerate change and tolerate thinking and we don't know what we don't know we start with a rough idea of what we want and given a rough idea the most appropriate thing to build is a rough thing so if we take a more iterative and incremental approach we might first start by building something that helps us understand what we're building and we might look at this and say you know really I'm thinking the smile is the most important thing about this picture I need you to move her hand away from her smile and I had thought of it more kind of in a farmy kind of setting and those rugged mountains are bothering me let's write a user story for moving the hand out of the mountains to to be trees instead that's looking good and now we need to get this thing closer to releasable so let's add more richness to this I just didn't see her as a blonde and this isn't California this is Italy no one wears that orange here that's the somber feel that I'm looking for let's really refine this and get this ready so a more iterative and incremental approach builds up over time and written on a board at ThoughtWorks where I spent a long time was the reminder to us all that it's not iteration if you only do it once please be aware that this story will come back again Alistair on his blog has something that he refers to was a three card method for every story that you write and slip two more under it because you'll need them the first one is the story the second one is fix the first one and the third one is fix it again it's basically we can think of it that way but we do need an opportunity to iterate the problem we run into with the typical scrum snowman is that there is this box at the end that says potentially shipable software and it doesn't mean what you think it means it's something that does get people in a bunch when they're looking at software it makes them afraid to try things or put stories out that aren't complete or aren't perfect aren't shipable because shipable from a product or product ownership perspective means I would use it this way and we talked about the Mercedes versus the what were we talking about the Geo Metro if I'm building a car and I have a Mercedes in my mind and the first story is for steering wheel and you deliver me a plastic steering wheel I was thinking of one that was wrapped in leather and it looked much nicer and we really can't move off that steering wheel until it's the shipable steering wheel it's the story it is the steering wheel that I want and this is where we start to run into a bit of a trap we talked about user tasks because we've done deferring of conversations we might have had a task for steering the car and now it's time to say it's time for us to build a steering wheel if we talk about tasks we did this late so that we could have discussions based with more context if I've got this flower and I want to dig a hole to put it into we now we held our options open by saying I want to dig a hole and now it's time to decide based upon how much money we have in our wallet and how much time we have what we want to dig and this might be an appropriate solution or given the time a better shovel is good or really I think we can imagine a great shovel and someone recommended that we need a really architecturally robust shovel and someone said we could outsource this to another we could buy it we could integrate something that would be digging holes for us and then somebody looks back in their wallet and we decide what gives us the capability is something else so we did all this deferring thing and so we couldn't decide up front so that we can decide with context of where we are now I've got a lot of interesting visual faces I want to do here when we think of cars and it's good to use this car maybe I want a car we build the essential backlog for a car it does have engine and transmission and brakes but we know that all cars are not the same I'm going to do this example with a bus because I've extracted this and I had the visualizations and we know that there are low cost buses and moderate cost buses and higher cost buses and we know that all buses don't cost the same but that backlog there is true of all those buses it's not just that it's the decisions we make lower who has heard of Noriyaki Kano before and who would say something about Noriyaki Kano say what is Kano stand for who is that doing so what I know for us is the Kano analysis which is basically trying to break up your features into some kind of goals that they're serving such as gosh we absolutely have to have this or we just can't go to our car and ask to have brakes period things that are more is better the more horsepower our engine has the better so and then there's the things that are really differentiators so I don't know wow we could have a heads up display no one's got that I guess people haven't known that yeah there are your things so to get that Kano talks about kind of splitting up features into things and what is the can you say what is the characteristic of why would I categorize features that way what's what's going on with with that so the usefulness of being able to characterize it that way is that to figure out what mix of those makes sense to go to market so for instance the ones that are got to have absolutely got to have as well got to have a first the more is better the more those you put in the better right so you can you can play around with those a lot but if you can get a something like a really differentiator the lighter kind of thing in there that can be a big game change right you might even be able to go back and throw out some of the stuff you need to have you can get the one game change the discussion about the product not just what the functionality is so what I'm going to get to is what Kano is really focusing on is this idea of subjective quality the idea that what people like is a function of what will delight them but there's I've never seen the acceptance criteria on a story as delighted but I can classify features of the lighter but this is back to what you were saying I'm hypothesizing that this is a delighter I have no evidence and I can't green mar that delighting thing but the idea what Kano was really talking about and what the Kano method was a simple distillation of is the idea that there is objective quality the stuff I can measure and see and validate and test and subjective quality the stuff that is relevant that pertains to the satisfaction of individual users the nasty thing about subjective quality is that it's subjective and the difficult thing in an agile context where we put our engineering hats tightly on and we want all acceptance criteria to pass to get to done done is ignoring the fact that there is subjective quality done in the eyes of a car buyer is done when I say it's done when it is exciting and delighting to me so there is more to Kano than the silly survey the important thing here to focus on is subjective quality now you said the basics of Kano there are must haves cars have wheels and steering wheels and engines and there are one dimensionals but better gas mileage is better and there are delighters there are sunroofs and leather seats and things like that and there is this realization of this understanding the quote from New York Times is that this car has many flaws by it anyway it's so much fun to drive and the dirty secret I've carried with me for years is you can deliver a lot of shitty software if people think it's cool or like the way it works and looking at Gwen as I say this who's been on my team and seeing stuff that people liked well enough and we knew under the hood it was had many flaws but the important thing is we sort of focus on making sure that we're really capturing what people are trying to accomplish with the product and doing it well basically it's strong and agile approaches that the idea of objective quality is the non-negotiable that's the stuff we're measuring done on and the idea of subjective quality is the thing that product owners or agile customers or people like that pay attention to these things have a nasty way of decomposing brakes are must have but what we mean really by that is stopping is a must have and basic brakes will do that for us but the stopping distance is a one-dimensional thing I can upscale a break by making it stop shorter and I can make it even better by making it anti-locking and my Volkswagen has this light on the dashboard that flickers when the anti-locking is engaged so I know why my pedal vibrates and that's even more delightful so features have features have features and we can chop things up this way but what we're chopping on is not presence of feature we're chopping up subjective quality this is the thing that we manage late in an agile context cool visualization the standard mode that people fall into is that we've got a product with lots of big features and we will build this iteratively in four sprints let's say in the first sprint we get all of one or some of the next and all of another one and all of another one and all of another one and at the end we simply we have a car with no tires or a car up on blocks it's not complete the approach that I suggest is that we take this kind of building up quality over time and by quality I mean subjective quality and therefore we need a better story splitting mechanism so this is kind of what's covered in your last box of your handout is now given a story map and giving an understanding of user experience how do we start to iteratively chop up stories even finer grade these stories need to be tiny size when they go into a sprint and it's now time to move them there my chopping mechanism is based on my bastardization of Gerard Mazzaro's story types but I look at what is absolutely necessary like stopping the car is necessary for a product a forum with just all the fields it has to have but no real validation or other stuff no it's not shippable but it's bare necessities I can do that and I can see it work I could drive it around the block that way if I add up capability or flexibility more fields different ways to enter things additional data ways to look up information that I furnish by myself looking up product numbers versus furnishing them so you might see things like optional input fields and lookups and data translation there's a category that is curious for me that Gerard put in there and it actually works really well it gives me a good talking point for this thing that I'm calling safety these are the things that you don't see in your software if things are going well these are things that prevent errors things that preserve the integrity of data things that these are the fire extinguishers in your house these are the features or the characteristics of features that you don't want to have to use but need there and we can scale those up also and then finally we've got this usability performance and sex appeal this is where we start to deal with the lighters making the product easier to use easier to learn faster to use more effective to use and then just plain sexy and when you look at an Apple product Apple is very good about cutting away features and cranking up sex appeal on their products they know what that mix is and they know how to mix these things so if we take this approach and we know that there are at least four ways to slice something and we were to take the same iterative development approach we might start by first building all the splitting stories into just fine brain just the necessities the things that I absolutely need in a second iteration I might start to add in more flexibility or other sorts of things and what's going on at the top there are some grades one of the things that I work with people doing agile to do is to say that yes we're building iteration by iteration or sprint by sprint but it's really important is whether we're ready to release so a simplest way to that again stole from someone else to assess release readiness is to just grade things across big features so if I were to give my product a report card at this point it does everything that it needs to do I've got a walking skeleton I can see it work but my grade point average is pretty low a B minus and a C and a C minus and some Ds but I've got two more sprints to go if I build up more and build up more and now it's time for me to release and I didn't get straight A's but I didn't get any incompletes in any subject I've got a releaseable product and from a subjective perspective it's as good as it could have been and by tracking release ability or whether this product is ready to release or looking at that subjective quality it's a sort of a handy thing is anybody doing stuff like that already naturally because I really said people are smart they just do this stuff you raised your hand there yeah we saw this with something we're doing for our photo studio to get items in there for them to shoot the interface they use to control what goes in there to shoot right now looks like total crap but it works and they can get stuff pulled in and while we're getting stuff pulled in we're improving what it actually looks like it's kind of subjective people you've got people in your organization building it as you use the product or is this a commercial product no this is us building it as we use it and you have a necessity you start you start doing stuff like that it's not a it's not a in hindsight it's sort of an obvious way to start doing this but I see it's a failure mode that a lot of projects follow and a lot of people who are new to the product ownership role don't actively think about it we don't plan that way they really won't let that steering wheel go until it is wrapped in leather it looks like a Mercedes steering wheel oh we had to fight you had to fight them say that again I had to fight them for a little bit but we got there the fight them to make it look better or feel better not so good looking but at least we can have it in your studio and I've found that in some organizations we find that people will fight for building the D plus version of the product but the product owners are very suspicious or business is very suspicious that you will never get back and improve the grade on that thing so by actually giving it a subjective rating a quality rating you put make it visible and understand it now and there is so much attention to objective things in the Agile Contacts dealing with subjectivity is not an engineer's favorite thing to do so Jeff, how does this work with trying to complete a story to mark a story as complete you know the only thing you can specify is objective quality this is a nasty truth so here we have four sprints and in four sprints we've completed a story I'm not kind of my question what I've done is sliced these stories I've taken one story that's big and broke it into a lot of constituent parts so at the very end each of these slices that you've created are still obviously customer consumable each slice is done and it has acceptance criteria it's built and people we can use it and see it and touch it but the grade level is over the original story the grade level is over the capability is over the I end up using user activities for this sort of thing or user tasks the grade level is at a higher thing and you might ask the hell does this have to do with this story mapping thing Jeff given some sort of story map I can look up the tree and I can grade at a higher level and we can have a conversation and walk to the map and say what would we call this area over here that's a B plus what about this area over here that's a B plus there that's good the next we ought to put some stories into this B plus area yeah that's a good idea we start to drive conversations like that putting more stories it brings up the grade at the higher level thing the reason for the map is that I can still see what the higher level things are and still have discussions about them without that you start to lose the plot so Jeff can you just clarify whether your grades are activity based or task based or whichever team prefers whichever team prefers at the end of the day my dogmatism about using tasks and activities is just that is dogmatism big things and little things useful to grade 400 stories it is useful to grade a useful grading might be on 10 to 12 things in a release or less ideally so sorry to raise my hand for you but I still have a question what was the satisfaction level what's your customer satisfaction level now that you've done that shockingly high actually they talk a lot about their subjective needs but when you give them the objective they tend to be pretty pleased that they got something so if you have something with the same customer to compare with where you didn't do that really now see if we can start to we're at the tail end here I'm thinking of something there's a famous person called named Jim Highsmith who used to live here at Salt Lake and was moved on are people familiar people know the name Jim Highsmith before I credit him with popularizing the term barely sufficient we want processes to be barely sufficient and at a functionality level there is this idea of being barely sufficient well recently I caught Jim Highsmith saying I don't say barely sufficient anymore because that's usually too much because what you can do with these stories is build something far less than anybody reasonably accept and if you can tell him it's just the first sprint but if it's functional it does something and allows someone to accomplish something you sometimes find that barely sufficient is a few launches below what you could have hypothesized it was before you saw it back to software is all hypothesis we're just guessing at some level we need to start getting some feedback and leveraging it and it does definitely come back to the business case that you guys were talking about over here it seems like when you're dealing with this iterative approach you're dealing with a scenario where you've got your core things there it can become a business decision much more earlier whether you decide to throw more money at it throw more time at it but at the end of the day you haven't wasted a year and a half of development to come out with something that really doesn't add much value you're going to know a lot sooner whether it's going to have value at it exactly and we're trying to get to that point and we're starting the discussion early about that whether we're getting this rating of a release is relative to the business case is this an A in light of what we're trying to achieve in this product for this release not A in light of all other perfect products in the world so it is a relative relative rating to that compared to that kind of a dumb comment really if you start delivering iterative strengths and you get the bare minimum kind of thing aren't you inviting basically an increase in your scope because people see it and then they want more and more and it becomes this huge never ending project wouldn't that be wonderful what was that again what about something else this one's been delivered to some extent for a whole other thing what I keep increases in scope for me go back to having a good understanding of what our product goals are again what are we trying to achieve here as people increase what I'm talking about now is a bit of a construction strategy of getting all the basics in there before we make it better but then what we do is say if people start suggesting more now that they do this that would be great if we did this we could say you know is that aiding the product goal this is why we can't build road maps based around scope because then they're scope creep but what I start looking for is goal creep are we trying to achieve more with this product and people will say you know you're right it isn't part of the goal it isn't going to give us more of that or less of that I was waiting for the excuse to use the Kentucky Fried Chicken mantra that plays in my head here in Salt Lake City know that Salt Lake City is the home of the first Kentucky Fried Chicken yes I mean probably you know put grease into the arteries of millions around the world and it all started here and it came from a southern yeah Utah guy bought it from his southern friend does anybody work in IT at Kentucky Fried Chicken so they can validate my stories true good then I can tell it any way I want there is I knew of somebody who did work in IT for Kentucky Fried Chicken and did somebody that used to work in the place that Gwen and I used to work at and they in putting together the business case they end up having to if they're building a report that they use in business that the bottom of this kind of one page business case they have to produce is the question how does this help us sell more chicken and they have to draw the dot in line from this strategic business goal and it's selling more chicken is actually very strategic it's just we want more chicken how do we how does building this report get us there in some way and they require people to connect those dots I do that exercise often with product goals and I can keep those posted and say that's a great idea for this feature how does that help us stop people from leaving the store when they know what they want we're talking about adding this thing to the kiosk which shows a lot of rich information about the album we're talking we've targeted users who know what they want they need that now is that going to help us get there now okay let's put it in the the next release bucket but without those goals you just don't have the leverage on the bottom of that you know triangle we were talking about earlier see if I can come up to a big finish you know what we're talking about is this the folks might have seen this cone of uncertainty thing that basically we know less at the beginning of a project that we do at the end and I mentally divide project into three phases and this is what's again summarized on the back here the chess metaphor works well there's a few other people in the agile community that are doing that there are stories that are appropriate for opening game that help us build this functional walking skeleton and validate we've got what we want and help us start to better answer the question is this it help us better address the hypothesis is this going to get us the business value we intended it to and the mid game which is fattening it up getting it ready for release and then the end game which is dealing with a lot of unforeseen stuff and making it really sharp getting it ready for release and we're striving for this kind of build up effect and in my head I usually do use third third third and if a third of the way through the project I don't have a third of the way through the release I don't have a way to get end to end through the value chain of the software that I get very twitchy and if we're adding whole new features or whole new capabilities during the last sprinter iteration I know we've really not followed this sort of strategy and we've adopted a high risk agile approach the last thing in talking about this this is something that Alistair talks this ability to slice up stories finally and what Alistair Coburn refers to as elephant carpaccio how would you eat an elephant and you slice it thinly enough that you could eat it a little bit of time and so thinly that it starts to look like a carpaccio and if we build things in an order that makes sense that's sensible we end up in early days is building things that lay in big basic functionality they have more architectural junk in them than they do values sometimes it's the stuff that I use to put something in the computer and make something happen but as we get this foundation going the whole functional walking skeleton and we start to lay in things that really make it rich we get the business value starts to increase a lot so we're adding a lot of business value with every story we play and then at the tail and each story just doesn't it's making it better but it's polishing and it's good so Alistair refers to this releasing on time thing but leaving stories in your backlog is trimming the tail for me burn down charts don't work very well because I always leave something undone and burn down charts make me feel bad about it and I don't want to so what what's important to me is that I get a product that delivers benefit not that I finish all the scope that's not it's not about scope it's not about output it's about outcome now let's skip over that I'm not going to have you with split some stories I decided to do all talking I have parting thoughts here and I have none this is the second to the last slide I've unloaded a lot of stuff on you and again very in a very self-indulgent way can someone any questions or did someone have a what what is her name she referred to recently as a light bulb moment did something strike you as ah this is a problem for us oh yeah we're doing this naturally we just haven't pointed it out did anybody have an aha that's interesting aha was the idea of classifying you know the thing the extra stories with the is this a lighter is it one of the mutual things the breaks and the basic breaks aha was to categorize the breakdown so what are the teams that I'm working with that I'll go to tomorrow they do this with their stories and they'll say we're about to play this story and it's a lighter and what they interpret that to mean is we have an opportunity to make people really happy with it so we will spend more time discussing and talking about how happy it is what we would talking about that subjective experience and they will tend to invest more time on it what it really means for the person who's the product owner is they will talk to me a lot more and then iterate a bit more inside the sprint and show me more stuff then they mark tag things as baseline as essential stuff what it means to the product owner is just get this shit done and spend as little money as possible I don't care about it it's got to be in there so you put it in and don't talk to me about it so we all know that there's a dial a quality dial of how much twiddling we can do to make this story really good and he's using that as his dial setting mechanism to tell people about that now I've been waiting for the one other last thing to say I said the nasty thing about subjective quality is that it's subjective and let's go back to the car example possibly a good example of what's a linear thing that's in a car where the more of it we have the better cup holders so for people buying Ferraris are lots of cup holders a delighter why not it's a delighter you said it's a delighter is he full of crap he's wrong it's just a delighter it's a delighter for a different customer so the nasty trick and if anybody has read Monty Cone's Agile Estimating and Planning and we talk about classing 5 features based upon desirability for me the elephant in the room or the thing not discussed in the chapter is the idea of identifying who your customers are stuff for people buying minivans lots of seating is a delighter for people buying Ferraris lots of seating is crap it's not what I'm interested in and so we need to really decide for these customers are not those customers so the tricks to prioritization again are understanding the stuff outside the user stories and articulating them or being clear about them and it is, I think it's time I am really really happy to stay and answer questions and things like that but thanks so much for sticking around and listening to this whole everything you ever wanted to know about user stories but we're afraid to ask sort of discussion