AA164 - 10 Proven Techniques to Split User Stories

welcome to the arguing the Agile podcast where enterprise business agility coach Om Patel and me product manager Brian Orlando debate the real world challenges Agile professionals will face. We are not here to sell you anything. We are here to argue about Agile so that you don't have to. So Om and I discussed and we decided we needed to have a session that we've never had before about backlog refinement and splitting stories, breaking stories down into much smaller segments of work. We've actually never had a podcast on this. Yeah, I'm gonna do a separate podcast on backlog refinement. That's right on the on the process the framework the process the actual day to day Of backlog refinement, I guess. Best practices. Is that a right? Some good practices. We don't say best practices. Yeah. Good, good practice. Yeah, yeah, yeah. But yeah, today's focus is on splitting work down to smaller chunks so that the team can get things done. And in case this is your first time on the arguing agile podcast. Mr. Om Patel enterprise business agility coach, and I'm Brian Orlando. I'm product manager. We both work in the field. Neither of us have yachts that I know of. Definitely don't have yachts, not even paper ones. Maybe one, maybe one, maybe one day. let's get some high level stuff out of the way when it comes to splitting stories, the high level stuff that I want to get out of the way right away is we all agree in vertical slicing of stories. Like there's not going to be anything on this podcast about, Oh, do all the database stuff and then do all the UI stuff and then do all the QA and all the whatever, like that's, Absolutely not we'll not the, the, we're, we're, we're also not going into working agreements. We're not going into a lot of, a lot of tangents we can get into. We're going to stay away from on this podcast just because we have so much content to get into on the podcast. Yeah. Slicing stories like you slice your cake. I know somebody's going to say, but I love just the frosting, but that's cake, not stories. That's me. I do love icing. All right. That's all right., the other thing that you will encounter if you ever Google for how to slice stories. You're going to come up with the INVEST acronym. The INVEST principle. Yes. Yes. I I don't know what INVEST means. I can't, in, in, in, individual, negligible. I, I think it just means when you're wearing a vest. When you're wearing a vest? In, in a vest. In a vest. So, we're not going to necessarily go into that because you can find that on disparate different sources out there on the worldwide interwebs. So that leaves one more thing and that is splitting your stories down to roughly about the same size. And again, we're not prescribing necessarily that thou shall do that, but it's not a bad idea to look at a fairly good distribution like that. Most of your stories are about the same size, and then your team can feel empowered to take on as a, as a stretch once they get to that point, a story that's a bit bigger, that's okay. You don't necessarily have to have everything the same size, but about the same size. Right right. Well, it so let me, let me go back to invest for a second before I harp on same size stories. Let's, yeah. So, so the invest, I like why I'm not a big fan of the Invest acronym. Like I, I like, I it's independent, negotiable, valuable. Estimable, estimatable. I can never remember. Yeah, that's the mobile small. Whatever that means and testable. Okay, so there we go. We got we got invest. It's out of the way Why I don't like invest is because like people will say hey, well does this fit the invest principle and I'll say Yeah, sure And then that's about all I think about it. Cause it's cause invest basically is useless to me. Cause when I'm in when I'm in a backlog refinement and I'm trying to split things, I'm not going through every single letter of the I N V E and also some of that is like is this independent? Like, does it work by, I mean, yes. Is it estimable? I think it's estimable. You might not. You know, well, it's just so what do we all have to completely agree? I don't want to spend a lot of time on on this acronym. I understand people will use it. You're not going to get around it if you go and you Google this topic. But what we're going to give you here is going to be a lot more actionable than this ambiguous acronym that you're not quite sure how to apply each. So, so I I want to stay away from it. I guess we could apply it to each of these categories if we're really, we're going all in on a very long podcast. I was going to say also boring. Yeah. Yeah. But stories of similar size. I agree with this one. I think this one is the end goal of everything we're about to go through. If you're trying to take your larger stories, you bring them in and you say, Hey the team says we can't do this in a sprint. There's nothing we can do with this story. It needs to be broken down. And then you say, okay, well, how can we? Break it and divide it where it breaks into several things that are of similar size. I had a scrum trainer one time. I'm not going to mention who it was. I had a scrum trainer one time who said one of the smartest things with regard to breaking down stories he said the similarity here is to fluid mechanics. Meaning, if you have objects in your water that flow through pipes the, the fastest flow that you will get is when all of the objects in the water are small and the same size. You get clogs when things are multiple different sizes all over the place. But if everything, everything is small in the same size, then you will always have flow through the plumbing system. I like that. I like that. And then just to extend that given a fixed size pipe, if you had things That were small, small, small. You'll have a faster flow, right? So that's what we're trying to say. Here's we're not saying similar size means they should all be the same size. Just to be clear, right? Similar. That's all. So you don't have rocks, boulders and pebbles. You have mostly pebbles where you look somewhere a little bigger. That's fine. That's fine. But they can still flow nicely through this despite who we're talking about. And for people who have started with a new team, like the team obviously is in the Forming stage or norming stage when it comes to breaking down stories. And there's a lot of friction and then the developers don't really understand why they have to do vertical slicing. Why? Oh, I don't understand where the value is. We got to do everything all the requirements up front, that kind of stuff, and you're kind of fighting the good fight here, The vertical slicing suggestions that we're about to give here you're looking for the end of a two week cycle or three cycle to say, Hey, we're getting to our next demo with the users and what can we demo in front of the user? So the, the, the really, the only way you can do that. And be in production. This is a caveat right there, right? Real live working software is if you're doing a slice down the whole stack. Yeah, I agree. And everything you just said also, I feel like applies to those people out there that are working in a Kanban way as well, because if you've got larger chunks, On your stories, then the flow that we talked about is going to be rather erratic at best, right? Or clogged in some cases when you have stories that are stuck in the same column for days on end. You might not have stories that are about the same size. And your forecast is going to be unpredictable on the product side of the equation. Your forecast is going to be very unpredictable and the business is going to be very going to be very discontent. I don't know. Yeah. Yeah. this is a really good topic because I feel like most teams that form don't spend enough time discussing all of this. They just go straight in and get on with the work and stumble and struggle. I think so. I think so. So what which, which workflow? Workflow via value I think I think the workflow is fine because you know, given that most people working on systems that are more complex than a simple, a simple workflow, right? Most of the time, then splitting stories by workflow would be a pretty good place to start. So, so when I think about workflow, workflow is I, I do operation X and then I do operation Y and then I do operation Zed. That's right. I'm learning dry operation or operation a B and C that's right. There's no, there's no, that's a B and C. Right. Okay. All right. Just check it unless you have 26, unless I have a lot. Yeah, right. 58 easy steps. Look, I'll give you an example here, right? So, so you've got a website that people can log in and browse and whatever typical e commerce scenario, step a might be just to be able to log in. That's it. So all you can do is log in, but, but, but what about if I don't know my password, password recovery? Well, okay. But those could be separate stories. That's completely all right. Yeah. Yeah. Right. You can bring those into another sprint if you had to. Sure. Yeah. Right. A lot of people call that happy path. And I've launched new systems before where you had no password reset functionality. People had to email support to have their new password sent out. Oh, I forgot my password. I don't know what to do. It stinks. It certainly does. Like it doesn't smack of a modern system, but I mean, it's not a permanent situation anyway. So it may be sprint X, you have that, and then sprint, YX plus whatever you bring in the other functionality. So it's just a question of delivering. Going back to our other point horizontally delivering value every, every time. Mm-Hmm.. I also think about this workflow via value. I think about like, well, what is the most valuable thing I spent a lot of time in logistics so software for truck drivers and whatnot and shipping and stuff like that. So I think about if the most valuable thing in the software is you have to be able to get your collection of documents signed and then send off the signed documents to somebody. Like there, there's, there's a pathway that is most valuable. I mean, you, you need to get the documents that you have. For the cargo that you're carrying signed off by the appropriate person. And then that signed off document has to go back to your home office and be received by your home office. Now there's some backend tasks that they probably do with it. There's a couple of steps I just outlined that probably are really, really, valuable or critical. Which is, can you collect all your signatures in the application? How does the application handle that? And then, once you have all your signatures, how do you package it all up? And then send it back to home office, whatever that looks like. In logistics it was a PDF signature and What's, what's the PDF DocuSign? Is that the DocuSign? Yeah. It was integration with DocuSign and stuff on the back end. The technical was integration with DocuSign and stuff like that. But those were very critical business operations. So the workflow through the application was, I log in the application, I open up the current job that I'm working on. I have documents for that job. And then I take them to a certain step, and then I get the signatures I need, and I submit them, and they get back to the home office. That's a couple of major stories. Back to back to back. we're not going down all the little side routes of exceptions and problems and doing whatever. If everything goes well, the perfect route through the application, Is the one that we consider is the most valuable. So let's document every single one of those as a story. Can we log in for the first time successfully? Yes. Can we view our current work that we are currently engaged in as the main operation, the docket as our, our, our document that we're currently working, can we pull it up? Yes. Can we take signatures in it? Yes. Can we submit it when we're done? And send it to the home office. Yes. Okay. So I just wrote like four or five, six different stories , and then everything else you think of, well, we got to have a password reset. And we, what happens if only one signature is filled out? What happens if no signatures are filled out? What happens if the path to the home office fails? What happens if you don't have internet? What, I mean, do you have to do this operation online, offline, whatever? There's a million different things. Sure. But. That main path of the most value. Let's walk through that workflow and build that workflow. We when we all used to work in offices, you would, you would write it on the whiteboard and also you would like back in the old, back in the back, in the old school days, back in the two thousands, mm-Hmm., single digit number, single digit. You would have, flow documents. Yeah. Right. Of like how data and how a business operation is moved. DFDs and whatnot. Yeah. Stuff like that. Yeah. I was gonna, I was trying not to say UML. I was trying not to, but I don't know why. The example you just cited in that you know, in that industry, that exists in a lot of places. Like, I'll give you an example here. If you're applying for a mortgage with a bank, right. So you would make your application online. You'd have to create, At least a log in and then chances are, they're going to ask you for some baseline documentation, right? Which might be things like copy of a pay stub or a tax return or W2. Yeah. So same thing get, get all of those things in the happy path. Really? It's really the most valuable path, right? If you get those in. Then your application review process starts. But if you miss one of those, now you're in the exception. Yeah. Right. And they can, these are all valid still, but they can follow a little bit later. That's all we're saying. The path through the application, this category. Of workflow. Why we started with this one is because there clearly is a highest value path through the application, but back in the day, way back in the project management day, they would call this critical path. Like what is it? They would make little work breakdowns and they would identify the critical path. These are things that are highest value, but it's regardless of what it is called , it is the highest value flow through the application. So this would be a way to start with. What is my has flow and then each of those steps, maybe we start by breaking that into an individual story. Perfect. I agree. Absolutely. All right. So, we're already talking about paths through the application. And the workflow that you take as you take a path through the application. The other way to consider is when you log in and you're a different type of persona using the software, like the easiest one is the old school windows of remember when windows had guest accounts, you'd log in as a guest, right? So you're going to log in as an administrator. You're going to log in as a regular user who has a user account on the computer, or you're going to log in as a guest, the accounts guests before they got ready. Well, yeah. And T actually started all that stuff. I remember that. The guest account. And then you always like, Oh, disable the guest account. But it's, it's a great illustration of, a role-based access. Now that our, RBAC is a normal thing in that yeah. These days, or IDM or whatever, I dm, there's lots of acronyms for this now, but the point is by the role that's logging in that user , they have specific things that they're allowed to do. So you could split your story by persona for sure. And in e commerce you have that too, right? You can be a guest user, go browse, and then. Before you buy it, they make you create a profile, but until then you could do all of these things, searching, et cetera. Yeah. For a freemium versus paid users, another persona based split. Absolutely. Absolutely. Admin user is another one, right? As a user versus an, as an admin user. So there are lots of different ways to figure out the role of a persona and then Focus your story around the journey or the experience of that role. Yeah. And in parallel, you can flesh out the other stories. Maybe, maybe not like detail out, but you could say, well, these are placeholders for stories that we'll take care of later. Right. Yeah, this is a great one. I mean, you could do a lot. Like if you combine the previous category, Of the workflow value through the system with the roles. I mean, now you can really get granular if you, if you need to, I don't know if you need to, I don't know if your system has, I think it's contextual. It depends on your application. You might not have roles. Everyone might be one one user or whatever. But now you have a you know, a potential factoring of different stories so personally in my backlog. I break everything by persona. I have a persona, and it goes on a story. Yeah. So if we were to do the same functionality for different personas, theoretically I would break it into multiple stories, servicing different personas. This persona sees it like this, this persona sees it like this. In, in the case that that, that a feature actually has different views for the different personas. I would not do that if it was like, well, we're mainly building this. For system users, but admins and guests and whoever else that logs in the system, they're going to see the exact same experience. So then I wouldn't, I wouldn't break it. You know, I would, I would specify the main persona we're building it for and then everyone else gets it as a bonus. So that's the highest value one again. Yeah, yeah. Makes sense. But if we were building something specifically for admins oh, an administrator needs to be able to see all the see and manage all the new guest users that go with their accounts or whatever. I've built systems before where you declare a customer admin and then they can like, it's an admin that works at the customer site and then they can have administrative functions over users. That live in their system. So it was like, I would build stuff for the admin that the users would never see. So I would create a persona field in my ALM tool, whatever ALM tool you're using. They're all pretty flexible to be able to do, to create custom fields like this. I, I am particularly using Jira, but you know, you can use any tool. I mean, maybe a tool is good. I don't know. Yeah. I mean, yeah, you're right. Most tools allow that. It's not all of them these days. So that's a good way to do it because then when you're discussing the details of that story, You can kind of empathize with that role, the persona and say, as you know, so and so. So that's a good way to kind of really deep dive into the story. And now it's focused around one persona and not all and sundry. And bonus points. If you actually have a persona slick sheet I don't say slick sheet a lot on the podcast, but I. I like, I like that term, Slick Sheet. If you have a template that tells you about that persona then new, mainly it's for new team members. Cause mostly if you have those persona templates and your team helped create them or were participated in some way then, They're probably going to know right away when they see the persona name. But if you have new team members who on board and they see a story is for this new persona, they can go look at your slick sheet and say, Oh, this is what they do. This is a normal pain points. This is the jobs you're trying to, to, to accomplish along the way. And then just a quick 30, 45 seconds reading the points on the sheet, what matters, what, what really matters to that user. And then, and then they're on board with the rest of the team. So that's a. A different podcast. I think you get bonuses points if you can work with your customer and use the actual name if they're okay with it, right as your persona name. Then, yeah, because people can just in everyday conversations say John or Mary or whatever, and there's a real John who's the persona, right? I said, that's a different podcast. So that is that is a way to split user stories is by role and persona. What about by the borders of the system or technology? Like I I spent a good deal of my career working with systems that had like web applications that had a database. Yeah. At the core of the system. So we either would and you know, API and the API access. So either the customer's API or our API or our database or any of the, any of the divisions that the user interface, any of the divisions. Of the system or technology, because also you have, in a modern web application system, you might have a mobile application and the mobile application is looking to hit a API that is served by one of your web servers that communicates with the database. So there, there's several different pieces of technology in the system and potentially splitting a story to say, well, we want to create a new APA endpoint that the mobile clients can hit in order to retrieve a piece of information or whatever. And where normally I would say, well, you want a vertical slice this work. Okay. People will say, wow, I got to add a new database table and then I got to add this new API endpoint and it's got to have all the data. Particular responses or non responses or successes, failures or whatever. And also I've got to edit my mobile applications. This is, there's no way we can have this done in one Sprint. There's no way. Yeah, it's not true. You can't have it all done in one Sprint. But you can have working software that gives you a sliver of functionality, right? So you don't have to deliver everything, first of all, on that API. You can mock out some stuff. And then you can just say here are all the stubs, but here's the valid stuff that we're working on. Go test that and then a separate story could unravel another stub, right? So you could do it that way incrementally, sort of like just simulating stuff in a payload, right? You're only working on a piece of it, not the entire payload, especially in some cases where the payload could be huge. You have to do it all. So that's a, that's a good way to split things. Yeah. The interesting thing to this is a lot of times when I, when I bring this up as a, Product manager. The team, the team has never considered the fact that in the version that we demo we can just fake the response okay, so, so I'm going to add this new API endpoint and all the mobile applications are going to hit it. Maybe it brings back your customer profile information and Amazon, for example. Right. If I'm, if I'm rebuilding the Amazon app, Brian and Ohm software development company. Purchasing app, which is a clone of the Amazon app. And you're going to say, okay, well, you're going to hit this end point. And it's going to bring you back all the orders that you've put into our system. That's the API endpoint and API endpoint. So in the same sprint, we're going to go up with an API endpoint that, that brings back all the orders. For the specified mobile user. And then in the mobile application, it has to call the endpoint and pass your, I authentication user id, something like that. Yeah. So mobile application has to pass your authentication user id. API endpoint has to be enhanced to have this new endpoint to bring back your orders. The database has to maybe there's auditing tables. I don't know, maybe the database needs to be enhanced to somehow handle for this. Right. So potentially there's three different stories about three different. Three different pieces of technology that have to be modified. And you can say, well Brian, why would you break your stories along technology lines? So the mobile application gets a story, the API, web service gets a story and the database gets a story for this new table or store procedure, whatever you need to do. When you do it that way usually I will say, well, the development team should swarm on things. But in this particular case, the person who does database development, the person who does the mobile development. They are likely not going to be the same people. Yeah, different skill sets to begin with. They most likely will be, either separate teams, definitely separate developers. Yeah. Again, just my experience, maybe there are some full stack people who do mobile application, web services, and database design. Maybe there are some people out there that will be like, no, I totally do all that. Good for you, you're in the minority as well. Also, can you get all of those things done? Right. Mr. Hero, developer in one sprint. So that's another reason why you'd want to split it. But I would definitely split this up. Where I started down the road of this item where people don't consider is. Okay. Well, my database team doesn't have bandwidth or my, you know web services team doesn't have bandwidth right now. My mobile, my mobile team can add the button or the screen and the compromise will be, I'll add the endpoint and it'll just give you back dummy data. It'll give you back the same 10 orders. No matter who you are. What you are brand new user, never had an order. A user that has hundreds of orders. It doesn't matter. You hit the new API endpoint and you get like the same 10 stock grouping of order. Like that's okay. That's completely okay. Because I can demonstrate that real live in, in production. I can demonstrate that and show people, this is what the new feature is going to look like. Please give me feedback and they can give me, even though it's not their orders, they can give me the feedback I need to go back to the backlog to say, okay, you just saw what we're about to do. It's mock up data, but it was enough for them to say they didn't like this or they wanted more of this or whatever. Sequencing of it may be or whatever. Yeah, exactly. So we covered the workflow through the system via value. We covered the workflow through the system via persona or role based. And we covered , the workflow through the system with regard to the borders of technology spaces , or systems another more broad general way is if you're talking about stories and your stories and or acceptance criteria have a bunch of And ors inside of it, that is a good way to break up your story. If you see a bunch of ands like as, as a podcast listener, I want to easily be able to download all my podcasts. So that I can listen to them and so I can read the transcription and so I can whatever like if you have a bunch of ands in there, you probably have a good trigger to say, Oh, maybe I can just copy this and paste it out to another story and take the easy route, right? Another super easy example of this is anytime you're talking about, I already brought up database, right? Anytime you talk about interacting with the database, you immediately have the CRUD command. Operation the create, read, update, delete operation right there in front of you. Right. So there's some easy splits with and or operations. I fully agree with that. So any of these conjugations as well as, and in addition, you'll see a lot of times you won't even necessarily see that in the. Title of your user story, but in the description, it would say that, right? I want to X, Y, Z and blah, blah, blah. So that's a good point. This is a really easy lift. We, all you have to do is look for those and make sure when you split the story, that it's vertical. So in the case of your example of CRUD, I mean, my definition, it is vertical because you can still deliver the C and the R and then deliver the others later. Right. It's still value. Typically what I have is started with, with this CRUD operation is I will just have the developers insert into the database, the main records or users or whatever it's going to be and then I'll just give you read access and then the, the C and the U and the D, well, the D usually follows late. Whoa, hey, calm down. Yeah. It's just too much. It's a little bit more work deleting. We got this thing called referential integrity that gets in the way. There's also like, multiple operations also could cover the fact that we have to give a in a user interface we have to give like a the ability to edit a record or whatever like you could look at this rather than like purely database operations, you could look at it and As I got to configure something, set it up for the first time, that kind of stuff. All my examples go back to crud now that we talking about multiple operations. I don't know why attaching documents to something that already exists. You know, that, that kind of thing. Multiple operations. before we move off of that. So often the red flag to look for in stories is the words configure, manage manage. What do you mean by manage? Well, we want to be able to read and, and update and, and right. So that's manage is just another pseudonym for too many things going on in this story. So we were, talking about interfaces slightly and I wanted to bring up splitting things by the complexity of the interface, I've worked in a lot of interfaces that, that, that you bring up one panel and the user would never know there's like 10 API calls happening to build that panel or, or Even applications that seem simple like the chat GPT interface where the chat GPT interface actually is is pretty smart because when you submit something, you're submitting it to the model you're, you're submitting it to the model for an answer and then it adds it. To the left on the panel to your series of things that you search for. You see that it's actually kind of a smart interface. If you think about what's going on in the open AI chat GPT interface, there's a call to summarization happening, right? There's a basic end point, summarization end point. There is a saving of the operation in your previous search histories. There's a moving the current operation to the top. So that the most recent thing is shown at the top, and then there's a saving that for all sessions that you will log into later. You'll always see your thing in order. There's a lot of things actually happening in that interface. if you were to break down stories in that interface, well, obviously you have to, whatever you're typing in now, Has to be sent to the model for, for a response. Right, right. With whatever parameter settings or whatever you have. I don't know what you can configure in their interface. I can't remember. I think the user can configure very little, but behind the scenes, you've all these weights, et cetera, et cetera. Right. Yeah. So, but you don't really have access to that. Yeah. Right. All right. But I mean, you potentially, you could have access to it. Well, based on your prompt, you could, yeah. That's a, that's a great example because it's not a super complex interface, but it's, I think it's easy enough for people to understand that, Oh, there's actually multiple things happening in this interface. The version one could have been something like a, just a prompt that you put in your thing, it gives you the answer, and then you can't You can't, you're going to see it again, like there are no turns in the conversation because really what's happening also is you put in your first prompt, you get a response and then every additional prompt is a turn in the conversation. So the model knows that you want to ask about the question you just asked about. It could. Not let you continue. Yeah. You have to like, Hey, refresh your screen to do a new prompt. Yeah, basically you could do that. Like that could be like version one or version one could be like that. Plus it doesn't save any of your conversations because we haven't figured out how to store user profile information or stuff like that. You know, maybe there's no login, like version one, maybe there's no login. Right. Could be the freemium. Yeah. Yeah. It's not complex, I've just taken their fairly involved UI and made it extremely simple, what is the main value out of chat GPT? I mean, well, you can put it in the prompt, you can ask a question and you can get an answer. That's the main value. So prioritize that first. So let's prioritize that first and have that be the first story. Right. You know, and then multiple stories as well. Like capture all my previous conversations. Let me do turns in conversations and then we'd figure out the priority. Cool. Well, I was going to use the Amazon example, but this one's, this one's a pretty good one too. Amazon for a complex UI. They have a very complex UI, Amazon. Exactly. So simplifying that you don't necessarily have to do everything up front. Simplifying that would simply be search for something and then be able to one click into a cart, right? Forget about the fact that you have bought this before on this date or people also bought this that, that sort of thing can happen in sequential stories. Could be much later, depending on where they're prioritized. Yeah. I was going to say this, there's so much stuff happening in Amazon's app, the functions available in the UI, you could break those off and send those stuff completely different teams I mean, you can probably on Amazon's main screen of all the things you can do, you probably could come up with a dozen different paths and send those to different teams to all develop in parallel just because it's so complicated. It's so complex. It's not really complicated. It's so complex, all the different paths. Okay. another interesting one is by business rules. Business rules is an interesting one. Cause we don't think about. The business rules that go into creating software too often. There's business rules that meet the eye and there are business rules that are beyond what you can see, and there's usually a lot more of them. So a development team needs to understand that if they're creating software both sides, right. The user facing side, as well as what's being created. Beyond the screen on the other side. If they can understand them, what I usually advise people to do here is just get a blank canvas flip chart used to be and just write down what happens right in a simple terms. Like it's like. Do this, then that yields this, and that's it. But if it if you do this other thing instead, then it yields this. And based on those, you'd have actions that are taken. Now you're in the realm of business rules. Those actions happen because again, happy path versus, What if something else fails? So yeah stories by business rules are good. As long as you're bearing in mind all the other things we've talked about. Vertically sliced, highest value first, right? If you're doing that, and then this, this is also a layer. So it's not like you pick any one of the topics we're talking about and say, That's the way to do it. That is just one factor in the bigger picture. Obviously it depends on your complexity. You could be in a simple environment where some of these considerations could be thrown away. Maybe you don't have lots and lots of interfaces, then you don't have to worry too much about the interface aspect of what we are discussing here. Yeah. I'm trying to think of business rules for applications that I've worked on to connect this to a concrete example. if we go back to logistics, for example, truck drivers have a lot of rules that they have to comply with. For example, if you're a truck driver and You have a, a electronic logging device plugged into your truck. It's interfacing directly with your truck's computer. Right? Your truck's computer will tell it when you're driving. Like there's no kind of beat in the process in this. Right? Yeah. If your truck is moving, you are driving. So one of the business rules is if, if you are in any status other than driving And your truck starts moving change your status to driving automatically change it, right? There's some caveats in there. You can be driving around a yard For example, if you're if you're inside of a controlled area, But generally if you're out on the road and it knows this because it has access to your GPS and whatnot, right? and Then it needs to switch you to driving. That's a, that's a business rule. There are many different reasons you can switch to other statuses, but this one particular action with this one particular trigger is one business rule. And we can write that in a story and take care of that as a story. And like that, this is a great, a great solid example of where that would live by itself. Right. If you want to say, Oh, Well, I'm I'm done driving for the day. I'm I'm on my rest, right? You want to click the status of rest and put yourself in the rest. Okay, you can do that. The driver wants to put himself into a status of rest to say he's done with his day. He's beginning his rest. Start the clock or whatever. You know, whatever the clock is. I can't remember what it is because it's been years ago. Start my rest. This is what I'm trying to say. Okay, well, what are the business rules of a rest when you be so long when you when you click start my rest like obviously you can't be You can't be driving when you say it. Your speed has to be zero, right? I mean, I guess. But well, there are some people that tag team driving, like two drivers in one truck. You're right, you're right. But, there are business rules that the business can say. I'm like the, the thing we were talking about earlier with signatures, or if you're talking about like buying a home like every page has to have a signature and certain things have to be filled out before other things can be filled out. Like those are business rules. Absolutely. So I think you could break down your stories by business rules. Whereas maybe you could say like, well, I mean, is it, is it valuable to have You know the first three documents signed and not the last 15 why don't we just have the story say sign all 30 documents and each document has its own business rules, right? Yeah, look maybe in that scenario after having the first three documents signed Another process could be spawned off, right? Instead of waiting for all of the documents to be signed, right? Like, for example, in the example of applying for a mortgage, maybe once you've got to a certain point, then the bank can start doing things like your background check, your credit checks, all of that stuff. They don't have to wait until you've signed all of the documents. Right. So there's reasons why you want to fork the workflow in this way. Yeah, you may want to trigger to say. This process has been started. It's not finished yet, but this process has been started in order to kick off some other, some other processes, unless you're in the UK and it's processes, but whatever, it's fine. If you're in project management, that's the start to start. So something starts and something else can start once that other thing has already started, but you do this via business rules, correct? So that just means though, that you have to understand your business rules. Clearly, so that you can align your stories up along the lines of business rules. So what about dependencies that are stuck in your way? Oh, dependencies. Cause sometimes it's not necessarily you're writing stories about dependencies. Although, I mean, I guess theoretically you could. I try not to. I try to write my stories around dependencies. And I use, again, in the ALM tool I use, I have the block status. And I will move things into the block status to indicate I cannot move this story because it is waiting on this thing to become available or this thing to be on block basically. So sometimes I will write things like we were talking about APIs for mobile development. Yes. And if we're talking about, well, I need to go get all my orders from Amazon but maybe I haven't been approved as an Amazon vendor or something, right? Like a seller. Yeah, something. Yeah. So I can't return all the orders through Amazon. So I'm still going to create the story to pull Amazon orders in my mobile app. But again, like we said earlier in the example it's all going to be fake orders, right? It's all good. So, so my mobile app will be pulling the orders. They'll all just be fake orders. Or maybe they'll come back and say, you know feature coming soon. Couldn't retrieve orders feature coming soon or something like that. Because we haven't been approved yet by Amazon to be able to actively pull the orders. So I, but I've got the work done. I like that, that particular story can be done and can be demonstrated and the, and I can get people excited. I can get the sales group ready and out there in the field the idea is I'm energizing the whole apparatus in the company marketing sales all my account reps, all my customer people, I'm getting them ready to understand how the feature is about to be used before we actually connect the back end of the feature. I think this is okay. Working around obstacles, I think is okay. It's perfectly fine. I agree. And in that example of yours, right? So once you have mock data coming back, I almost don't want to even call it fake. Right? It's mock data that's come coming back once you get approved in that scenario, there's no other change needed. It's just that mock data will be replaced by real data, right? So you can deploy that in production all day long. And it was always going to say is, like you said earlier, right? You know, data to come or whatever the disclaimer is, right? And then when data comes, it comes. There's nothing else to be done. We were talking about it in terms of obstacles, I think the same thing with dependencies. Yeah. Yeah. And in most ALM tools, you can create that as a relationship between stories. Right. So you can then sequence them. Coming soon. Go pull my orders and the response comes back with coming soon. It's like, it's like the trailers at the movies. I feel coming soon. we haven't touched on fake door type of features, right? Whereas like, well, well, which kind of goes along with this working around obstacles category is. Well, we don't know if we want to commit to actually pulling orders. Like Ohm thinks it's really important because he works on Amazon adjacent app, but I don't really like Amazon personally and I don't you know, I think we should go with some other marketplace or whatever. So, so, so but Ohm can implement the feature that says coming soon or whatever. And he can start gathering metrics with his story that he actually implemented to say, Well, actually, Brian 65 percent of users do click this order pass through function and they get the coming soon screen. So we probably should elevate the connecting the database story or connecting the whatever vendor API store, whatever it is That's a great example of using something to test out a theory or hypothesis and then being data driven and say, yeah, let's move this story up or down, right? Because you now have data, right? So it's an empirical decision rather than just a emotional or a gut decision. Yeah. And there might be people listening to this and say, well, why would I want to have a feature that I don't know if I'm ever going to turn on? Well, if you're building your applications in a modern way where you have feature flags, we can say, well, we're going to enable a flag for two weeks and then we're going to turn it off. If we haven't committed to pushing the story through in the API and connecting to the Amazon backend or whatever, then we're going to turn the feature off because we don't want to aggravate users. And it will be transparent to them. Sure, yeah. Some people might have a hard time with this because they don't work in this way. Not only, not only not vertical slicing, but also not feature flags. So they might have a little difficulty with this, but again, plenty of teams work like this. So it is a normal thing, it is possible push for it. You know, it is possible. Definitely. Definitely. There's many ways of doing this too, right? You can have a feature toggle that basically is, is turned on at a certain point on a date, time horizon, and then turned off again automatically. So you don't, your team doesn't have to do anything all the way down to the other end of the spectrum where. You can give the customers the key to turn on the toggle and turn it off. So they can try it and if they don't like it, they can turn it off. No other customer could have that. So it's restricted audience. Role based, role based. Exactly. So a lot of this stuff is interweaved. And I like that. That's as good. All right. So let's talk about spikes. I've said this many times before on the podcast, in my backlog, I have a component which tells you the type of story, basically a category of story. Is it a new feature? You know, something that we can capitalize basically, is it just kind of like recurring maintenance, something that we can't capitalize it has to go into OPEX. I've broken things down so that, so that finance can very easily take the buckets of work and, and, and do what they need, although they don't, they do things the hard way. Cause their finance so. Spike stories are, I want to engage in this line of work, but we're all unsure about it. So we need to spend some time and learn about something, learn about technology, learn about business processes, learn about applications, potentially, like if you, I think about if you take over, like if you take over an application from a, another team and your team has no skill in it, they have to spend some time learning about the application. And basically their, their time. Spent learning how to do things. I call that a capability. My team is now learning a capability. they're taking on and advancing a new skill basically. So I have a category for that in my backlog. Okay. So I can in the, on the finance balance sheet, I can show time spent. It can be assigned to an, it's own little GL code for spikes. I will preface this by saying. I don't like. Assigning points to spike stories. I personally think spike story should be just time box, spend X amount of time. Whatever the team decides is the time box. Spend X amount of time learning how this works. When you're done with that time come together, get the team together and review with us how it works and walk us through it. It's my team has chosen a time box of two days. It could be a lot less. It could be more. I'm trying not to get into what is best for your team, but the way my team handles it is A spike is just a time box. I don't put points to it because the spike is, I don't know go figure out what we know and don't know, and then bring it back, bring those learnings back to the team. there's not really a podcast about talking about, but it's not, if you're putting points, then put points, right? Just be consistent. Yeah. What we have, . I'm sorry. I even brought up points. The, the, my, my, my objective with bringing this thing up is. Sometimes you cannot break a story because you don't understand it. So you have to create this type of work item. Yeah. It's to learn something. First of all, I categorize it. Yeah. Because if you start seeing this big, this big uptick in, we have to learn how to do whatever. Like that is your trigger to say like, wait a minute why do we have to relearn all this stuff? What are we doing? Like, wow, how are we doing so much unknowns? You know, and, and, and kind of what are we doing in our, in our business. Right. Yeah. But I categorize it, I time box it, and that's how I keep real tight. Track of things, track of, of, yeah, of this kind of like unknowns, you know? Yeah. I mean, it's spot on when you say, if you have a lot of spikes, Then that's an indication of something else not going right. Maybe your refinements are lacking or something. The team's always unsure. Spikes are also around external things. Like you might want to do a spike to prove the market to learn something. Sure. Right. So in that case. It might be more than a day or two. It doesn't really matter. If you're gonna do spikes, they should have an outcome out of the spikes. And that outcome should be to learn more, to reduce the cone of uncertainty, so that you can create stories and move on from there. So stories are spikes when the only outcome is something that you're not really putting into production, but you're using that output to create stories, other stories. I've used spike stories for that as well to say, when this spike ends, the acceptance criteria is. We are now able to create an architecture to do some specific thing. For example, a recent spike story that one of my teams took on was to investigate different queuing systems. So there's a lot of different queuing systems on the market and AWS has its own built in queuing system, but it's only appropriate for some, some people. Particular types of uses and the spike story was investigate several types of queuing mechanisms, kind of the team kind of listed out a few of them that they want to try and figure out which one was the best best fit for purpose for what we were trying to do because the team had a, we had a defined business case that we were trying to accomplish. And there were a couple of different technologies of queuing systems that we were investigating. And that was a spike, which one is gonna be best for us based on all the things we want to do. And here's the things we want to, like we listed in the spike story, here's all the different things that we, Think we want to do not that we're certain, absolutely certain and then the developer took a bit of time. And then at the end of the sprint, they were able to come to the sprint review, a separate sprint review, just with the technical staff, basically to talk about this technology does this. And then the lead developers, I was on the call, you know what I mean? That was like, we all would ask different questions from perspective. And then the developers who investigated the spike would be able to answer all of our questions. That's a good example of using a spike in case of a situation where you want to evaluate things, those spikes are longer because you've got to do the same thing across multiple options. So this developer might've looked at. The criteria for success, right? These are the things that must do any messaging tool and then, or system. And then looked at for example, what, what does a MSMQ give you or a rabbit MQ or whatever the, whatever the queuing mechanism is. And then decide on which one takes most boxes and all of these other things. So it's a good example of using spike stories for evaluation purposes. Yeah. Yeah. that particular team usually the business will come to them with a potential new scenario that is not accounted for in our current software. They'll have to constantly be seeking new ways of doing things so that that team's constantly engaging in spike stories, you know you know, which is, which is you know, again, I was on software development teams for many, many years before I was a product manager. So that's the cool thing about being in product management now is I know that I have to keep constantly seeking to disrupt and push past the current technology that we are using. Otherwise, we are we're looking at irrelevance in potentially, what, 18 months? A very short period of time. Yeah, exactly. So I'm constantly adding spikes to say, hey, how can we push past where we are today? You know, but I think, I think just personally, I don't know. Every team's different. But for me, I would rather be on a team that constantly is seeking to reinvent itself. Sure. You know, we're, we're like every couple years the, all the, all of our processes are different. All of our technology's different and you know, we're, we're not doing the same thing every day forever. Like, that's, yeah. I mean, otherwise you, you stagnate and then something blindsides you and whoop, there's lots of businesses that run that way though. Yeah, I know. Sadly, that's true. Oh, that's another podcast. Another major thing to bring up is when we make a decision and we choose not to tackle something. I was just talking about continually evolving our software when we choose to not evolve our software or when we choose to make a technical trade off. A lot of teams do not immediately capture the trade off made in story form to say, Hey, we're capturing this user profile information. It really should be in a user profile table, I'm not going to call out what, where it was or what part of my What part of my career? Cause there was a lot of technical debt at this particular company that I worked at somewhere in my career. but basically their user table had a bunch of columns that should have been other tables if you think about the, the type of user profile information, like the user user profile should have what, you need to use your name, like a password, salt hash, that kind of thing. Maybe some like profiling for me, my name, my phone number, that kind of stuff. Basic stuff. Yeah. But not like operational things I have access to, or things that are saved in what you would think of as different tables, , here are all my objects and here are all my screen configurations. And here, here's my custom setup and save preferences or whatever. Those probably should be in separate tables if we're doing a database configuration. Well, they had it all in the main user table. And it was a real pain to work with like those those Technical debt decisions of like hey, i'm making this decision to take a shortcut. We know we're gonna have to deal with it later Let's just stub out the task now When we take the shortcut to say we took the shortcut we all agree. It's a shortcut Here's the story to deal with it later and we'll just throw that out there. Yeah, just have it out there. So i'm of two minds Number one is, you don't want to create stories and never get to them and leave them in your backlog for years and years and years. That's one mind. On the other mind the development team wants to know that you're not losing track of these things that you said you were taking a shortcut. You know it's not the right way to do it. We know we want to come back and refactor it. They don't want to lose track of that. So they want it recorded. They do feel better when you say, Okay. We're intentionally taking the shortcut. Let's put it over here. So I'm kind of split on this. Well, I think the, I think the guiding principle here would be how long can you live with that compromise? Yeah. Right. So ideally in that example, specifically where this user table had everything in it. I mean, it's not very efficient, et cetera. You take the shortcut for a reason. First of all, let's everybody understand why we're taking it. And then that remediation story, put that in there and then have it come up. You'd have to, you'd have to go with how important is it to fix that technical debt? Can we live with it? Is it tolerable? So instead of a sub two second response, it takes 10, but everybody's okay with that. You probably don't even have to come back to it. But on the other hand, you could say, well, this is okay now. Yeah. When we add more users, it's going to be more problematic. We need to break out into multiple tables and link them with you know, indices or whatever. Okay. So get that story in there and prioritize it in the context of everything else that's going on. It's all of the other stories that you have on your backlog. This one. It's a tech debt story clearly, and you prioritize it based on how quickly that needs to be remediated. So it's, it's not like one size fits all. In my example, if the other work that you're doing is okay to push it a little bit and get this thing fixed up now before it gets much, much worse, because when it gets worse, it's not just the fact that you have to change the database design, you have to now get the data in those other tables. So there's some refactoring, serious refactoring there, right? So yeah, it's contextual, I think. So I I'm not in two minds about it. I think I'm looking at it thinking how important is it? How critical is it to fix this? Is it now next later or never right? And based on that, you would have the story there. So you could tag these stories. And if it's in now it would be in the next print or two. If it's next, it might be a little bit further out later. It could be even further out, but then that's where it stops. Yeah.. The you know, another way to split stories. Is to split the exception handling off into its own story. I'm not a huge fan of this cause I, I like the kind of tenants of test-driven development. And if you're doing that, you're kind of handling the exceptions as you go. You never have exceptions. Yeah. I remember we built a system once where it was a mobile first system. So everyone was using you know, phones basically. And the system was everyone would phone home to our, our, the company our API, but our API had integrations and hooks for certain functions out to the It was a B2B to C application. So our, our company's software had hooks out to companies APIs. So basically you would phone our API. And our API would contact, uh, the company that you work for is API. And if the company you work for is API was slow or unresponsive or whatever, there would be no indication to you that like, Oh, it's, it's your company. Who's at fault. Yeah, not us. It would just be like, well, you're saying, yeah. So like that, that, that particular one, I remember we went through a lot of hassle with watching the component APIs the, the, the dependent APIs for uptime. So w w we were doing a lot of uptime monitoring. So we were doing a lot of uptime monitoring. Of third party APIs, basically that we depended on because we look bad if other companies, APIs that we had no control over went down. So it's exception handling, but if you were building a system for the first time, you would say, the mobile. Users contact our API and get the response back. And then you could look in the, in the previous where we're talking about role based or multiple operations or workflow value, like where we're talking about those stories, you can say, well, we'll just send them fake data back and we'll figure out integrating with company APIs later. Cool. But at a certain point, you're gonna have to say, if we don't get those responses back in a reasonable amount of time, We got to deal with that and like, how do we deal with that? And all that kind of stuff. You can put that off till later. And I guess that's this category is putting all that off till later. You know, here we are. It's later like handling when those systems don't come back in a timely manner, handling when those systems don't come back at all, handling when those systems are just hard down. All those can go in different stories. This is my, yeah, absolutely. Look, this reminds me of systems that I've used where you have to fill out umpteen gazillion fields. And at the end it just says next, you click next and it goes reset to zero. So this is a good example of, of carving out stories by exception, there are lots of other examples like this as well, right? So a timeout stories, for example, right? Stories where. You get failures, like just there's no, there's no success in trying to get to a certain web page four or fours or four tens or whatever, whatever it is, right? Yeah. You could do things there, but in your example, you have complexity because you're not just dealing with your own environment. You're dealing with another set, another environment, the customer's environment or, or the B2B, the B second B in that, in that scenario, how would you do that? Right. You would have to make. Some guesses and say, or assumptions and say, if we don't get a response back within X, six seconds, eight seconds then we would simply say, please wait. Right. And then try again, maybe the same cycle. So 16 seconds now, and then what do you do? So there's a lot of these discussions that need to happen, but all of these different things could lead to scenarios that you can carve out as user stories. Right. And, and sequence those. Earlier on the podcast, we talked about I don't remember if it was complex interface, but we talked about chat GPTs interface . You open up the interface and you submit your question or your prompt or whatever it is. And then, it adds your prompt into the left menu of the different prompts that you submitted. I particularly pick on open AI because I don't like them very much. And also they're, they tend to get overloaded through the workday for the not paid version, which is, somebody told me at a network event, it was like 20 something dollars a month or 20 bucks a month or 1999 a month or something. That seems ridiculous for, Access to the model for a static. That seems crazy because it is a static model you get to the next version I loaded 25 in the Claude and I like that that like it cost me 22 cents for 10 million tokens It seems ridiculous to pay 20 a month for a service fee when I've just paid 25 for I'm pretty sure my entire life so for the interface like what happens when you submit to the model for an answer and it's overly busy and it can't answer you? The cool thing about this category is it, you can probably handle this in a graceful manner that actually ends up on the Kano model of being a delighter. You know, you can say like, Oh, the model is overloaded right now but, but I'm going to take your session and I'm going to put it on the left and I'm going to show a little spinning wheel. And I'm going to keep submitting it until it goes through for you. When you click on it, maybe I'll just say like, Hey, I submitted your question. The model's really busy right now. And we'll, we'll we'll process it whenever it's better. I can give you a timeframe to say like. You know, Oh, building the old windows, I was gonna say, remember windows three one, where it was like 10 seconds left. Yeah. 34 seconds. Exactly. Yeah. I remember those very well from five seconds to 34 seconds. Yeah. Yeah. In this example though it could, it could be very graceful, right? It could say. You know, we'll be, we'll expect a response within eight and 20 seconds. That's a range rather than 14. So it's like, it's better to not have to have separate stories because you've handled this in the test-driven development or whatever. But in the case where you do, because you, maybe you have some hard timeouts, you're integrating with other systems or you have a model basically behind the scenes that may be taxed or not, and you don't know when you're submitting. Yeah. You have some interesting things you can do with a story like this to handle the exceptions that could entertain your users. I mean, I like, I'm trying to think like there's a, there's an interface that it's not a spinning icon. It's like a little game. In the browser while, while you wait on the operation. I can't remember that. I wish I could remember what it was. Oh, come across scenarios like that, where it's more of a distraction. You're looking at something you forget that you're actually waiting. Yeah. You're looking at something doing backflips or something. I wish I could remember what it was. If you can remember what it was in the comments please tell me what it was. I can't, I can't. Yeah. For both of you that are listening. The last category that we have to talk about it, but believe it or not, we're through all the categories. The last, last category we have to talk about is, is non functional requirements. I'm talking, load testing, performance testing, anything with alerting or back of the house type of alerting type of stuff like that any NFRs writing stories for that kind of stuff. So you can break this stuff out. Yeah, I honestly, this is probably the easiest category or everything we talked about, cause a lot of this stuff ends up. Actually being broken out as its own story, the load testing or performance testing, your app usually gets its own. Little segment for you to play around in. Yeah, I agree. This one is an easy one. And it can even be things like, oh, we're just talking about response times and things like that. It's just make it work first and then make it work within some five second response time. So bolt that in. Again, in an ideal world, you would build it so that it works, but that's in an ideal world, you want to try and get to some kind of proof of concept quickly. So, yeah, I agree. That, that was the, the workflow through the system. Like you should get to get the valuable workflow working first. And let's say that you're grouping something for a summarization for an LLM Oh, I want to send all of these documents through for summarization. Okay. Well, the summarization takes. 50 seconds on average. I mean, like how long is the appropriate wait time? I was talking about, like you, you do your chat dbt interface and then it loads the session and it says, Hey, when it's ready, we'll let you know. Right. If you're not doing something like that, like how long. Is appropriate for a user looking at the screen, five seconds, eight seconds, 10 seconds. It's not very long. It's not very long. Yeah, it's probably a number. So if you can say, well, we want to get the time under five seconds and then your whole team kind of groans and grumbles like, Ooh, five seconds. Oh my goodness. It takes 30 seconds. Now five seconds would be, Oh my goodness. What can, what are we going to do? Like, okay, well maybe I'll break that story out as a separate story. Okay. We're okay with the 30 seconds now because reducing 30 seconds becomes a task in and of itself. We'll put that over here. But the main thing is, okay, we know it's going to take 30 seconds. What can we do in the current 30 seconds to make it more. Painless, right? Make it palatable. Yeah. Entertaining. I don't know. You know, yeah. Yeah. Tolerable. Yeah. Tolerable. Yeah. In some cases you may not even know the team may not even know what it takes to get it down to the five seconds, right? So they may have to do things like scaling scale testing, pressure tests and whatever. So yeah, I agree with that. I think this is good. It's an art form though, to try and keep the user. You know, from being frustrated at waiting. So, yeah. So if you can think of ways that you've seen let us know in the comments below, well, we just gave you a plethora. That's right. I use plethora. We just gave you a plethora of different ways to break stories down. Again, we, we started with all, everything we just talked about is a vertical slicing. I'm assuming you're, you're from start to finish, you're going to production with every single one of these stories. We gave you the invest acronym. I'm not super hung up on the invest acronym. So feel free to forget that one. If you want, we're trying to make all these stories, similar size. We're trying to break them all down to a similar size. So, so your team kind of agrees to move them along quickly. We give you a lot of different categories, a lot of ideas. Hopefully you can take these ideas and apply them directly in your day to day with your team. Yeah. And more stories that are of smaller size is a good thing. And if there's any methods that we didn't cover, let us know down below and don't forget to like subscribe. That's right.