 Hi my name is Jeff Watts and welcome to another of my top 10 tips videos. This one is about splitting user stories How do we split user stories is the question I get asked a lot But before we get into that just a quick mention about one really interesting point And that is that you don't have to use user stories. I Know right groundbreaking stuff But a lot of teams actually only use user stories because they think that's what you do if you're an agile team Now I know a lot of teams that get a lot of value from them because they're a really useful technique But don't use them just because you think you have to And even if you do end up using user stories not everything on your backlog needs to be a user story There I've said it But let's just say that you are gonna use user stories for argument's sake One of the biggest challenges that you'll likely face most teams do is how to break them down into small enough chunks That they can deliver within a sprint and get something valuable at the end of it And there are lots of useful techniques out there that you can Google To find out ways of making things smaller and I'm gonna give you my own tips for that But just before we get into that there are two traps that people often fall into we use as stories And I just want to mention those first One is extending the sprint don't just extend the sprint so that you can fit the user story in It's it's an easy way out, but it doesn't actually solve the problem It extends the overall cycle time of actually getting something done Rather than working out how to break this the functionality down into bite-sized chunks And the second thing to try and avoid is splitting a user story by the stages of the life cycle So don't be tempted to just do the design of the user story in this sprint And do the testing in a couple of sprints time That's completely getting away from the point of scrum and ultimately is extending the sprint So assuming you can avoid those traps What are my top 10 tips for splitting stories into small enough increments of valuable delivery? So tip 10 is believe that it's possible to break it down into smaller chunks A lot of the places that I go they assume that actually what they've got is the best that they can possibly achieve that it can't get any smaller But actually someone someone coming in from outside perhaps myself who has no knowledge of their domain No knowledge of their habits their preconceptions And and what's normal for them can actually help them break things down into smaller chunks than they believe was possible Quite often by asking a really silly or naive question So the first tip is just to believe it's possible and once you've done that Then you can start applying some of these next nine techniques with greater effectiveness And it just so happens that the next nine of my tips spell out the word Possibles you see what I did there? Yes So tip nine Obviously begins with the letter p And tip nine is personas So what is a persona? Well a persona is a biography really of one of our potential or maybe even our actual users And it will tell us a little bit about them about their motivations for using the product Perhaps their history with using products like ours or even our product itself Uh, their knowledge of the domain their technical proficiency Their personality traits anything that will help us understand how they're going to use our product and why And there are no products out there where there's only one type of persona and Each feature has the potential of being valuable to more than one persona So if we focus on one of those personas first, we have the opportunity to break down this story Into something smaller and satisfying the needs of one of our personas before another and the rest of them So first stop Spit our stories by personas Tip eight is operations So what do I mean by operations? I'm not talking about surgery here Instead I'm talking about all the different ways that we could actually interact an operational level with our functionality So if I had a huge user story around account management I could break that down into or I can create my account That's one way of operating the account management feature. I could read that Account that I've created I could read data from it I could then update my details on this account and I could also delete the account Those are four different operational ways that I could interact with this this big user story So I could split it along those lines Now create read update delete. That's a very common set of operational functional activities And it's known as crud CRUD But there are many other ways that you can interact Operationally thinking about the different operations that people can perform Within the functional area that our user story is defining Will open ways for us to break our stories down into smaller valuable chunks Tip seven and the first s in my possibles acronym is simplicity Now on the face of it This is one of the most obvious ways of splitting our user stories by focusing on the simplest thing that would possibly work It's even in the agile manifesto But simplicity isn't as easy as it might seem as human beings We tend to be drawn towards the more complicated rather than the more simple It's almost like an insult to our intelligence to deliver the simplest thing that would possibly work But we need to if we've got any chance of getting any value We need to focus on the simplest thing that would possibly work And we need to start asking ourselves the question of what is less than necessary To avoid gold plating our solutions Notice I said less than necessary that doesn't mean unnecessary just means not quite needed yet So thinking about that and simplifying stripping it back and then once we've stripped it back Challenge ourselves and ask other people to challenge us to strip it back even more Make it simple to make them small My second s and tip six is sequence Now just like our assumptions in other aspects can cause us problems Assumptions in the logical order of doing things and completing functionality can get in the way of us delivering value sooner If we have a logical order a rational sense of how we should do things Then we follow that flow without really challenging it or without really questioning it For example, it may make logical sense for me to be able to log in To my account before I can buy something But actually if you think about it Do I really need to be logged in before I can add something to my card and then purchase it? Well, perhaps I don't but if I follow the logical order of things Then I'm going to be getting something not valuable log in functionality or certainly less valuable And then later on I'll get the valuable functionality of being able to buy something Shifting the order in which we do things might seem a little counter-intuitive But it allows us to get at our value and possibly mitigate our risk early So cutting out the logical order of doing something can remove some dependencies Reduce the size of our overall user story and allow us to get some value sooner Tip five is input and this is looking at all the different ways that we can gather input from our users This might start out with, for example, a really simple basic freeform text field with no validation Just get something into our system so that we can then start using that data or they can start using the next piece of functionality That will probably evolve in the future to adding some validation to that text to make sure that it's not junk That it can be filtered, that it can find its appropriate place in the database and that the data is useful But we don't need that right now And that might go even further to then integrating a third party data feed But the complexity of adding that in from the start could delay our ability to get any use and any value straight away So delay that and just think about the easiest way of gathering input from our users Tip four is business rules Once we've got some data, there are many different ways that we can use that data And many different pieces of business functionality that we can satisfy So stripping it back finding out which of those business rules are more important than others Perhaps easier to satisfy and then focusing on them one at a time will allow us to realize value more incrementally So for example, these business rules could start off with a simple version of selecting a date between x and y Then we might iterate on that and add extra functionality by adding some kind of filter Saying select any dates that match these criteria a little bit more complicated But we don't need that to start with so let's put it off until the next iteration And then we could expand on that in the future Tip three is levels Now with levels we're starting to look at our non-functionals So this could include things like security Or performance or speed or perhaps even the number of browsers that we're compatible with Now we don't need to be fully resilient and fully secure and fully speedy straight away So stripping back how non-functional we are Will allow us to slice our user stories into smaller increments of value Tip two and my penultimate tip is effort Now this is quite tightly linked to simplicity from earlier and as a product owner just getting the opinion of other people And most importantly the development team in terms of the options that are available to us in terms of how we could solve the problem Looking at the simplest way the easiest way the least effort way of solving the problem of the options available to us Will allow us to solve problems and get valued delivered sooner So look at how we can get this done in a least effort way possible And my final tip that finished off my acronym of possibles is spike So what is a spike? It's a funny term that not everybody will be familiar with But a spike is an opportunity for the team to actually look at the user story in a different way And start to work out what's gone into creating that user story and what's behind the functionality It's an opportunity to explore To prototype to research to de-risk Some way of reducing the uncertainty around this feature If you bear in mind when teams estimate something on their product backlog such as a user story They're bearing in mind the number of different factors They're bearing in mind the actual complexity of getting the functionality done. They're bearing in mind dependencies They're bearing in mind the full life cycle of the development. It's not just about coding. There's there's design as analysis There's testing there's all sorts of aspects in there. There's also The factor of experience have they done this before if they're familiar with it It'll be a little bit easier and the estimate will be lower There are also some unknowns and the more unknowns there are the bigger the estimate So if there's a spike you can reduce some of those unknowns by learning perhaps prototyping experimenting Then you're reducing the size of your user story Are you getting any value? Well, you're potentially not getting something potentially deployable But you are getting some learning and there is value in that So a quick summary once you've avoided the traps of extending the sprint And splitting user stories by horizontal functional silos rather than small vertical slices of value and functionality Then you can start by thinking that things are possible And once you remind yourself that it's possible You can start thinking about how you could split this user story by persona And the operations with which they're going to interact with our product Focusing on the simplest way of doing something and getting some value Stripping it right back and challenging our assumptions about the sequence in which we must do things So that we can remove any dependencies Then we can start thinking about the inputs and the ways that we gather information and input from our users Then which business rules our functionality can satisfy And focusing on the highest priority or the smallest to do Then we can start looking at the levels of non-functionality that we're applying to our user stories Before looking at effort involved and possibly spiking things out Well, that's my top 10 tips for splitting user stories. I hope they were useful There are plenty more out there. So please add your ideas for how to split stories in the comments field If you're enjoying these videos and getting value from them Then please do like them give them a thumbs up and subscribe to the channel And if you want me to focus on something else Let me know what topic you're interested in in the comments field and I'll do my best to make a video for you Apart from that, that's it. We're done. So I'll see you later