 Okay, let's get started. My name is Raj. I'm glad to see all of you here. How are the sections so far? Good stuff? Well, we're going to be prepared to be disappointed then, right? So... I'm only slightly joking. The reason I even submitted this talk was based on my experiences. None of the material that I'm going to present here is earth-shatteringly new or revolutionary. It's been done by thought leaders and disseminated to the agile community for over 10 years. But what I see is as a practitioner and as a coach with a lot of teams, especially with new teams moving towards agile, it's a constant struggle dealing with preparing stories for consumption within their sprints or Kanban, whatever the framework it is that they're using, as well as getting stories to done. So I thought, you know, why not just sort of submit this talk and narration is nice enough to accept the talk and here I am and I'm happy to see lots of people here. So, as I mentioned, I just want a quick show of hands as to who's... I'm assuming a lot of you are either with undergoing an agile transformation or working on agile teams. Is that fair? Yeah, lots of them? So how many of you are dealing with user stories and have... user stories? Everybody, right? It's nothing new, right? It's been around since the early days of agile. And how many of you have taken a deliberate approach to splitting stories, looking at splitting patterns for stories and so forth? A lot of you. There's nothing new here then. Just a refresher. So, in terms of... looks like the majority of you folks are pretty familiar with stories and splitting strategies. Just a quick show of hands and there's no shame here. Anybody who's not applied any splitting patterns towards story splitting and so forth at all. Good. Oh, there's quite a few. Okay. So those subset of folks, are you dealing with user stories at all and just still in traditional methods moving towards agile? Just curious. You're using user stories but lots of pain, right? Okay. Sorry. Okay, that's informational. So I will be introducing the idea of several different splitting strategies, of course. And for those who are already doing this, perhaps it's a nice refresher and you can chime in and maybe mention strategies but we'll start off the session and the outline is pretty straightforward. We'll just quickly ground ourselves and ourselves in stories, what the purpose is and then very quickly delve into story splitting strategies and how do we really prepare stories so as to get them to done in an efficient manner using these splitting strategies and then we'll have some time for Q&A. I want to keep this pretty conversational especially when we start coming to the different splitting strategies, I'll sort of throw out an example and we'll try to see how we can apply a given strategy towards breaking up these stories, if you will, into smaller bite size chunk. I want to make sure that this is pretty conversational and it's back and forth especially because all of you have done this quite a bit. All right, ready to get started? Yeah? All right. So thinking in stories, before we even talk about story splitting what the heck is a user story anyway? Anybody? What is it? User role, value, a chunk of what? A chunk of requirement. Yeah? Anything else? I heard somebody else scream something else. Would somebody say this? No? All right. So a user story is a lightweight expression of a given user segment or a user's need, the business proposition, if you will. And I know the most popular template out there is this connector format, a microns template, which is as it's such and such, as a certain user I want to invoke some capability, some function so that it achieves some larger outcome. So these are the essential considerations regardless of whether you stick to this format or some other format, it's sort of useful to consider those three perspectives. Role and then what do you want the system to do and why do you want this to do it? What larger outcome are you trying to go after? And this is perfect even for, whether it's for software or even non-software initiatives. I deal with a lot of software as well as non-software transformations and we use these aspects to define our user needs in this specific format. So what I want to first draw to your attention is don't get too caught up, at least this has been my experience. I've been in the agile community a long time. My introduction was through Scrum and XP in 2003. What I see is there's, especially these days with the mass adoption of agile user stories obviously are central to most of these teams in terms of how they're thinking about requirements is there is this blind adherence to this format. The format is not that important. What's important is who the audience is, what it is they're trying to do and to what larger outcome. That's really the important facets of this lightweight expression. And how many of you have heard of Ron Jeffries, the three C's of a user story? Quite a few people, right? Every story, no matter how you express it in whatever format, needs to conform to these three guiding principles. The first C in the three C is it's a card. A card is essentially a token. And it's intentionally meant to be this little small index card because you don't want to write the entire requirement. Details are meant to emerge over time. They're not locked down up front. Very different than our traditional approaches. So I would be hesitant to call it a requirement because a user story is not intended to be a replacement for a requirement. It never was. I don't think it is ever going to be. The details will emerge in time. The second C in the three C's that Ron Jeffries mentions is the idea that it's a token for having a conversation. The real details of what it is that you're trying to build that capability emerge during conversations. And conversations are going to trump all other aspects of trying to jot it down into a format or put it into a Jira tool or whatever else it is. That's the second part of the three C's. And finally, and importantly at least it's been my experience that lots of stories in the teams that I'm working with that perhaps are small enough to fit on a card. People we do have these grooming sessions. You're talking about the details. But oftentimes the third C is forgotten which is every user's story should have unambiguous condition of satisfaction. You need to know what it is that needs to be satisfied to say that the story is done. And many a time I see teams sort of ignoring this aspect. This is critical because this is what's going to ensure you're getting to done. What's a practical aspect of this confirmation aspect from a technique perspective? We talk about acceptance criteria. That's really essentially what that is. But the important aspect is it should represent a shared understanding for programmers testers and business. Unambiguous. We've talked a little bit about what a story is, the three C's and finally who's heard of the mnemonic word, invest. Invest. Again, it's a normal idea. It's often good for us to as we write our user stories to think about the validity of the story through the lens of invest. Invest stands for the eye is independent, negotiable, valuable, estimable. I don't necessarily want to sort of go through each of these aspects. For those who haven't sort of been exposed to this yet, I want you to go Google, look it up. Bill Wake is the guy who sort of came up with that mnemonic and definitely read up on it. What I want to focus on from our splitting perspective is two aspects. Every story ought to be valuable. Valuable to whom? Customer. Do you think there's no value in knowledge acquisition, meaning that sometimes you're doing some things where you don't really have true end user value just yet, but perhaps you're doing something that ultimate goal of end user value. So I believe that every now and then knowledge acquisition has a place in terms of being valuable. Right? And small, what does that imply? Within the iteration, somebody said. What else? Does one thing? Can be completed in one sprint. Smaller. It has a value. Yes, of course. Every story, if you look through a lens, has to be valuable. So oftentimes what it seems is at least in my experiences, when you say I want a given story to be valuable and I want it to be small, teams say it can be done. Because inherently when you think about value to end user, you think about a fully featured capability. Not necessarily. And small, at least in my opinion, humble opinion, doesn't necessarily mean your job is to split stories to fit in a sprint. Whether using time boxes or whether using flow-based frameworks, the point of small stories is to discover our direction and value. These are all little experiments that are guiding us as frameworks are all empirical frameworks. The point is about getting feedback. The goal shouldn't be about trying to fit into a sprint. That should be the natural outcome but it should not be the root reason. I concur with you in the point that a lot of teams are really thinking about stories about I want it to split so it fits in my time box. That should just naturally emerge and I would challenge you guys to go back and think about it from a value proposition and a feedback proposition rather than think about my goal is to split it to fit into a sprint. That should be the consequence. We've talked a little bit about all of these aspects. Let's get into the actual sprinting strategies because we want them to be valuable be it knowledge acquisition or end user value and we want them to be small. But why small? Why should they be small? Besides the whole fitting into my time box thing because now I'm doing agile so you want QA to test feedback, okay? To be able to fail fast, rapid feedback because it's an iterative process and if we're going in the wrong direction we want to know that sooner, right? What else? Maybe you are releasing these incremental it's not fully featured but it's fully functional, that tiny sliver maybe your business cases you will deploy that into production and whatnot but that's not necessarily the business case for everybody but it's still valuable. It's about short feedback cycles, what else? What's that? But maybe the idea of breaking things up will make the implicit requirements emerge, right? That's a powerful reason to make things small. There's lots of hidden requirements that don't emerge if you don't break things, right? Another reason would be so we talked about feedback, we talked about requirements sort of emerge, implicit requirements emerging. It also means you're giving your product owner if you're in that sort of setup options real options to say I just want to do these certain things the rest are not that important just yet or maybe ever, right? It helps with prioritization and sequencing things there's lots of benefits to being small other than just the fact that it fits in the sprint in the sprint, okay? All right, any questions thus far before we sort of go into the different splitting strategies? Right? So you understand the purpose of things being small you understand what the notion of value so let's explore some strategies and as I've mentioned, all of these strategies are not new, they've been around a long time. In fact because of the time constraints that we have I'm going to probably just explore ten of them, right? I would strongly encourage you to go back and look there's folks, people like Kent McDonald who's actually speaking on some other topic has done lots of work on strategies and so forth so they're there and I'll share a few resources and my slides will be available so you can look them up. There's lots of other strategies beyond the ones that I'm talking about, okay? All right, let's talk a little bit about how requirements really emerge, right? I'm assuming in most organizations be it traditional or agile you are starting with some higher level business objective or outcome that you're trying to reach which you're then going to break it up into these broad big chunks of activity or features, call it features epics, I'm not going to get into the battle of whether you call it an epic or a feature these are big things, right? Big borders and you're going to sort of progressively, if you're in an agile environment, break them into these bite-sized chunks or these little pebbles which are then subsequently decomposed into if you're in a product development environment, coding tasks or if you're a non-software still there are some tasks that make up these stories, right? And as I mentioned an ambiguous conditions of satisfaction are distilled as acceptance criteria and these days through testable examples and I'll revisit that pattern later on as a spreading strategy but this is essentially what happens in some form in most organizations. True, not true, right? Absolutely, nothing new here. So we talked about a small pattern that I see and perhaps you can share your experiences especially with new teams, we understand we want to split these, we want to progressively elaborate our epics and features and so forth but what I often see is the breaking up of these big borders happens across architectural layers, right? People are nodding their heads. Absolutely, right? Because that's our comfort zone especially we don't have full stack developers, maybe I'm a DBA then there's a front-end expert there's a middle-tier person, whatever we're always breaking our things into what we know best which is our architectural layer, right? Not very valuable. Why is it not valuable? You can't test it and there's no business value I mean the end user can't do anything else. It doesn't give opportunities of prioritization. It's not a fully working thing saying that I finished my data model saying who cares, right? So the feedback cycle is deferred if you start breaking things but this seems to be a very natural tendency for folks to break this way also it sort of continues to keep that silo mentality, yes we have our role specialties but it sort of reinforces that I'm done with it, I'm going to hand it to somebody else we want to eliminate that silo mentality, we want to minimize these handoffs so the right way to approach splitting first and foremost is to, if we are doing horizontal slices by architectural layer is to look at it from a cross-cutting perspective. All the layers of whatever makes up your slice of the pie, right? If it's a traditional 3-tier app, user interface, business value database, some thin sliver, so that should be our first goal. If you're not doing it we have to make sure that at least we are starting there, right? So once we sort of get that in play how do I go about splitting these stories, vertical slices? So first and foremost I'll give you some of the most obvious ones, right? This strategy called workflow steps is useful when you're given story it describes a sequence of steps or activities that the user is going to have to do in order to realize that outcome that they're interested in. So I'm going to give an example, right? As a learner, somebody who wants to take a class somewhere I want to register for a class and pay for it using a credit card so that I'm better informed about Agile. Maybe I want to take a class on Scrum or something, right? So that's my story. Perfectly articulated, right? Conforms to all the different aspects you draw, what and how, what I want the outcome, everything, right? So take a look at the story and the way it's articulated I'm made sure that this story there are some workflow steps. What are some of the workflow steps you can think about when you read that? Registration. What does registration entail? Looking for a class registering for the class payment and what payment itself can be broken down into what? Payment method Payment method Maybe prior to payment reviewing my order, right? Post payment, maybe acknowledgement of a receipt, yeah, notifications. As you can see you're all smart people here and you're already broken down to like a million different things, right? When you think about all the things you said this feels like it's an entire application in itself, right? Expresses a nice little story if it's on a card, right? So again, some of this is pretty common sense. View the course, select the course review, pay notification, you get the picture. So some of the key questions you might want to think about when sort of breaking these down by workflow stuff this is pretty straightforward is can you take a thin slice through all aspects clearly you won't be able to finish all of this in a sprint, well you won't be able to finish this in two sprints, right? So we know we need to break this down. One tactic is can I sort of do a little thin needle through all aspects maybe it's not fully featured but can I do little pieces of it, right? That's one thing to consider. Short of that you say no, that's not possible for me to weave a narrative through all of those pieces but the other thing to think about is can I do the first one and can I do the last one because the real value is in where? Find the I want to take the darned class right? So maybe think of your stories in that manner when you talk about workflow. First step, last step can I do those? You should do that. And then all the other things we've talked about become additional stories that will come in time. Now this gives real options for a product owner because clearly these are all valuable things but especially valuable if you're doing the first and the last because that gives them the ability to actually sign up for the class Make sense? Alright, second one. This is fairly straightforward and perhaps you guys are using this all the time which is breaking up a story by operations, right? So in this one, and I want you guys to play along, right? As a training provider I will take the same theme. As a training provider I want to manage my course offerings so that learners can actually view them and sign up for some classes, right? That's my story, right? What are the implicit operations here? Creating my classes? What else? Deleting, editing? Yeah, absolutely. Searching, everything, right? There's lots of things that are happening here when you hear the word manage configure, administer right away, you know that you're doing multiple things, right? So operations. Break it down by that. And again, look at it. This down through this these different activities it seems common sense but also in addition, make sure that you're doing the most valuable one first in terms of look at it through invest. Is it really that valuable that I can do delete first? Not really, right? Is this that valuable adding a class? Yes, I would question that. Right? Why? Because I can easily have a flat file that I present and the ability for the user to select that. It's possible. Even edit. I can reupload a CS3 file, right? So you got to be a little more deliberate about how you apply these strategies, right? Yeah, so so my pet peeve with a lot of stories and I don't know about you guys is when I see stories that say as a user do this as a user do that, as a user do that what's especially of course is when I say as a developer do this, right? The problem with it is we're not thinking, we're blindly applying that format without thinking about who is this user? Is there nuances? There's always nuances to the different kinds of roles or personas in tracking the system, right? So in this case, as a learner I want to register for a class. Sounds simple enough but perhaps if you think about it, if I'm a learning organization there's the learners and there's the training providers perhaps and sometimes I might want to be able to register you into a class, right? So I'm doing the same operation but with a slightly different perspective, right? I'm a different role, right? So these kind of distinctions also have a powerful way for us to split things because they are similar but maybe not exactly the same and if you go back, if you're not doing this I would strongly urge you to go back and look at your story and say are you truly being deliberate about the actual user segment in tracking with your capability or function, right? So first of all, good? Useful stuff? You guys doing all of this already? So let me take a quick pause here. We enter workflow operations role. You guys do all of these? Good. Only two people? A few. So nothing new. No new learnings for them here. All right. So another simple one is data boundaries, right? So this is about when your initial story does interact with a certain entity but different facets, different pieces of data on that one entity that it's operating on. So in this example I present to you, as a learner I want to view course information so that blah blah blah. So what are the different pieces of data that you think that I can break this story up by? Say that again? And so on and so forth, right? Anything else? You mentioned something else? Course, the actual course, right? So maybe in this case the data boundaries are there's different facets, right? There's different attributes to what a course means. Maybe a first pass name and description is sufficient to get me going. And then the course agenda. Instructor qualifications. Is RADS qualified to teach this silly class? I don't know. So maybe the facility information. There's lots of things when you start delving into a given entity there's lots of facets. The question is, is it worthwhile for us to break it up along those channels so that we can get this going and then come back and add the additional details later, right? So one thing I want to sort of stop, pause here and mention. Just because these stories are small enough it doesn't mean it's one and done. What I mean by that is this is not something agile is not about saying I touch this, I finish this, I'm going to move on to something else. It never was. Agile is incremental and iterative. Iterative means you will be revisiting these things again. It's not a question that you won't ever come back to that capability. So it's okay that you take a thin sliver but you're going to come back and revisit it and add additional nuances to this capability, right? So perhaps that's a split that may well be worth it for you guys in terms of breaking things up. So now we'll look at a few more as we go through a few more examples that will get a little more complex in terms of these scenarios. So simple first and then enhanced again is a strategy where the initial story as this indicates has some base set of functionality that provides most of the value, either value from an end user perspective or from a knowledge acquisition perspective. Okay? So this is really tight to the whole notion of 80-20 rule, right? You heard of the 80-20 rule, right? Most capabilities, 80% of the value is realized by 20% of the work, right? So, I won't give a solution. So as a learner, I want to see my past courses so that I can do something, right? So what is the base functionality that we're trying to provide here? Just show me all the darn things, right? That's my simplest use case. Of course, all of us are work on systems where we have lots of searching for things and then you want dynamic searching, yada yada yada. It essentially is adding complexity. I'm not saying it's not needed, but the question is, is it needed just yet, right? But I want to filter by topic. I want to just show me only the past two months. Whatever else your particular domain is, almost always you will find a natural base functionality that maybe it's not necessarily simple, but still maybe worthwhile for you to take a look and say, is it going to save me some time in terms of feedback, because I just at least get my basic search in and then I'll come back and make it more dynamic and so forth. Right? So, an ad hoc. Major effort. So this is again a typical pattern that you might come across. So, where there's a lot of effort that may have to be expended in order to get that first little bit of capability going, right? So as a learner, I want to pay for my class with Visa, American Express, MasterCard, yada yada yada. You get the picture. So where do you think the major effort here is? Payment gateway, right? I want to get that in place. That's my biggest effort. And that may take some more time. So be it. It's going to take the time it's going to take. Right? So the question is, when we're building a payment gateway, do we still want to at least pick one card to ensure that it works? Now the question is, does it matter whether it's Visa or American Express? Given my experience about American Express here, I'd say, yes, it matters because nobody wants to take American Express here. So maybe I want to just try mine with Visa, because perhaps that's more valuable, right? And then is it worthwhile then to break them up into separate stories for MasterCard and American Express and PayPal and whatnot? Why not? Okay. That's what I'm saying. Yeah, this is fine. We said we'll play with one. What is the next logical split after that? All the cards together. All the cards together, right? Absolutely, right? There's no point creating a profusion of cards, one for MasterCard, one for PayPal because the majority of the work is already done, that's the major effort. Maybe you'll just combine the all the others, right? You just don't want to have a profusion of cards all over the place with little, little micro stories, right? If it doesn't make sense, don't do it. Combine things, right? All right, let me just take one quick pause here. Still relevant? Yeah? Applicable? Right? Yeah. So here's another interesting one. Zero, one and many. So here, we're often dealing with collections of things, searching for things, deleting collections of things, managing collections of things. So as an online shopper, I want to delete items from a shopping cart. The zero, one, many principle essentially says doing nothing is the simplest thing you can do, right? You really need to do it at all, right? That's the zero case. And perhaps handling the zero case is relevant and the easiest thing to do. The only one thing is easier than many things. So you tackle that. Maybe I'll only allow you to delete one thing at a time. Yeah, it's a little painful for you as a user, but this is a short-term thing, right? So... Oops. And then so deleting one thing and then finally, you know, broadening it to many things. So this is another very common pattern to apply, right? As I mentioned, there's a host of other patterns. I've just selected some nine representative ones. There's one important one that I want to sort of spend some time on talking about next, which is about business rules, right? And I'm going to tie that with the notion of acceptance criteria as well, right? So any questions on the patterns we've studied so far, you know? Okay. So business rules provide a strong way for us to sort of make things smaller from a splitting perspective. And you guys mentioned that every story should conform to the three C's, confirmation being an integral part of a story. So... So... To tease out the business rules is obviously what you're doing when you talk about acceptance criteria you imagine, right? So if I had to sort of play along with you here, right? Say, I'm a product owner, you're my team. The programmers, the testers, the business me's, whatever. And as a user, I want to essentially create, let my learner log into my organization and create a password that's not easy to crack. Okay, that's the story. Now, what are the business rules there? I want to let my learners create an account and provide a password that's not easy to crack. You're my team. So, minimum 6 and maximum 12. Okay, that's one business rule. What else? Should be changed every three months, special characters, log equal to last five parts, should not be a dictionary word. So you guys have pros at this, right? What are all of these? These are business rules. Right? Now, what do I mean by example? So let's take the minimum character and maximum character thing, right? Exactly. If you're the tester types, they're always thinking the boundary cases, right? How can I break this thing? I'm mentioning the rule is one thing. Examples essentially exemplify the happy paths and the crappy paths for all of these different rules. And oftentimes, that's what test cases are made of, right? Are these various scenarios that exemplify either the rule being met or being broken, right? That's essentially an example. So Matt, when the guy who gave us an example, introduced his idea of example mapping and there's a nice blog post on example mapping. It's a technique that I use heavily in the organization that I am on in order to engage less technical people in the conversation on defining the boundaries of a story. Give me the rules. I'm not going to say acceptance test. I'm not going to say give and then, gherkin, blah, blah, blah, none of that. Just give me the rules surrounding and then engage the testers in the business piece. Give me examples because this is powerful as a program for me to guide my development. So we're doing this before development begins on any story. Lots of little things happen by thinking about this of these acceptance criteria in this manner. And also it provides a natural seam to break the story up. Maybe the last five passwords or change every three months is not important enough but let the product owner make that choice. As a team we're giving them real options by doing this. So that could be a natural seam to break stories into small things. And then also these rules are nothing but your acceptance criteria and if you get your testers engaged in this process early enough, perhaps they can give us these examples, illustrative examples and these become nothing but your acceptance scenario. Now whether you express them as give and then and make them automated tests, you can see the choices are limitless but this gives us a way to move towards the right kind of behavior in terms of how we want to get these stories to done while also providing a mechanism to split stories. Any questions about this? How many of you use the example mapping or some similar technique for gleaning acceptance criteria? There's a few. Do you guys concur with me? Lightweight powerful way to do this. When all else fails we have our spikes. You went through all these techniques I still don't know how to break this story up. Perhaps the domain is such that there's just not enough information or knowledge intrinsic within the team that you can break this down. You spike it away to not necessarily split but essentially you're giving yourself a time box amount of time to investigate whatever it is question that you're trying to answer so that that information can help you break things up into bite size chunks. I'm assuming all of us have used spikes. All right. For those who haven't seen this none of these techniques are new and there's lots of techniques but I really like this particular one by Richard Lawrence. It's their story splitting strategies. I love that in one pager he's depicted all the different strategies that we've discussed and more but again even this is not the complete list. Look up look up look at the reference list that I have in the back of the slides lots of different strategies but this is a nice little cheat sheet. Richard Lawrence Richard Lawrence and you can just look up story splitting cheat sheet and you'll find it. So we print this off in our team rooms it's just a little useful for it to be there. So any questions thus far? All right. No not in this session but I can happy to have a conversation later. I have five minutes I want to sort of close this out with a few other thoughts. So over the session we've talked a little bit about the story splitting strategies and so forth. I just recently discovered this idea that Goiko mentions it's about thinking about stories whether they're good stories or whether these are really burger stories looking at it through the lens of what he calls the zone of control and sphere of influence. These are systems thinking concepts that he's very elegantly applied to stories. So before we talk about good stories, bad stories let me just quickly explain to the best of my understanding what this means. So zone of control is things that's fully within our control. So things like coding and testing things that we can do fully control of. Sphere of influence are things that we're not directly in control of but we can impact them in some way. So given these and then there's also the third aspect which is external influences that we cannot control at all. It's not in our control it can be really influence it. This is just third party external dependencies that we can't deal with. So given these systems thinking tools of a zone of control sphere of influence, what Goiko suggests is take a look at your stories the deliverables the I want part of a user story. The I want part of a user story and then he looks at the user need which is so that the larger outcome going back to that user story format he essentially what he's what he's suggesting is good stories are things from a deliverable perspective that we as a team can actually control but the outcome is not really our control but it's within the it's really we can influence it. That's what we're doing. We're building these things in order to influence the right outcome. So what Goiko suggests is good stories generally if you look at it through this lens should fall there within our control when I say our the teams control in terms of the what the functions are creating and they can impact but not fully control the the outcome. Bad stories and this is where I think a light went off for me because often times I see teams creating stories for the sake of creating stories because we have to fit these things and my scum master is shouting at me if I don't have at least 4 stories 10 stories in one of the case maybe. Now misleading stories will usually be in this quadrant where the team is in full control of the function the I want part also in full control of the the outcome as a database person I want to create a database table so that I can do a joint ok that is right here right? So be wary of those sorts of stories of micro stories, misleading stories fake stories in lots of different terms and when I saw these examples that makes a lot of sense so good stories usually reside in this quadrant. It's also good too for us to think about those stories that there's nothing we can do about certain things if I cannot control a certain delivered because I have a dependence on somebody else there's little you can do about it outside your zone of control then you really have unrealistic expectations and things that are just not actionable what do you do about those sorts of things often times we have dependencies with security teams infrastructure teams whatever the case may be the idea then is if you're starting to see stories in those quadrants we do the best we can to bring them here by splitting and so forth and if there are still some outlets that are here then you're assuming a risk because you can't control the outcome make sense? So I thought it was a useful way to sort of think about stories questions or thoughts I just sort of wrapped this up and leave some time questions that's an anti-pattern right yeah let me answer that question first right so you have lots of spikes in your sprints okay but typically right you have some I think to me it's an anti pattern because you're not doing enough upfront grooming right we looked at all these strategies as if that things are happening just in time and in order to have good flow in and a good rhythm you have to do look ahead planning right so some of you may have heard about 3 amigos sessions and so forth right you heard of 3 amigos sessions 3 amigos grooming sessions so 3 amigos grooming sessions is the 3 amigos or friends are business, testing and development a subset of those 3 facets are looking at your backlog and doing this decomposition ahead maybe a sprint ahead maybe just in I don't know what the right duration is but it's not all during your sprint planning because if you start to do this sort of decomposition just in sprint planning good luck with that because it's going to be a complete nightmare right so you are doing some deliberate upfront front just in time but a little ahead right to help mitigate some of those concerns if you start to see 50% of your story spikes that there's a deeper problem with how you're dealing with stories and your agile rhythm there's always going to be the idea of technical stories and then you have to build enough runway so as to actually build the stories so that's a good question and again you have to balance some of those architectural stories with your business value stories as first class citizens in your sprint backlog we do this all the time but be wary don't completely jam 10 sprints worth of just saying runway stories that I need to do this but a good question you still have one prioritized backlog you have enough trust or maybe you have a technical P.O. in additional business P.O. what are the strategies but you're balancing those concerns with your business value stories when is it going to be done right and that's a it's a difficult question it depends but let's talk a little bit about that because there's multiple answers to that question and no straightforward way to say I have to meet a certain date how do I there's uncertainties essentially spikes are trying to mitigate uncertainties to me even some of these stories are about mitigating uncertainties uncertainties in the real value proposition to make them small let me summarize and then maybe we'll have just another minute I'm getting the evil eye there to wrap this up so what do you export is definitely if you're not looking at invest definitely look at it look at all your stories through the invest model you don't be sort of stuck to that format it doesn't matter whether you use the connext format or not as long as your role what and why are being answered and also small stories are not about fitting into a sprint it's really about making sure you're discovering what really matters right that's how you present stories pretty and that's how you you presented to your business as why you need them engaged in this process it's not something that you do in isolation it's not just the teams job and it's not just the PS job either it's a collaborative effort again to somebody mentioned it's about fitting things into a sprint if you are adhering to these ideas they will naturally fit into a sprint I wouldn't go about saying I want to make them small because I want to fit them into a sprint that should not be the really the reason explore the patterns and be very very dog-manable about actionable acceptance criteria and scenarios and try this example mapping and see if that helps try that zone of control thing and look at your go back and try stories and say where they really fall it may reveal at least at least you'll be informed are these really valuable stories are they not so that's that maybe I have time for one or two questions maybe or yeah he's going to allow it so we've run out of time and we need to clear the partitions for the next session I'm going to upload this I'm going to upload it I tried this morning thank you for your participation and I'm happy to hang around here and answer some questions