6 Ways to Split User Stories

Hello and welcome back to my YouTube channel. I'm super glad to see you here, and in today's video I am going to share with you 6 techniques that you can use to split user stories. And this is really important if you're managing any sort of Agile projects. And if you like anything project management, Agile, or Scrum, please make sure you like and subscribe to my channel here. So first, let's start off by talking about what is a user story. So a user story is simply a description of a change in system behavior from the perspective of a user. It describes something that the user wants to do with the system or wants the system to do for them, and this functionality doesn't exist today, so the user wants you to create this for them. In other words, it's a description of a person wanting to accomplish something within your system. So basically, these user stories are requirements your product. And the format that you will write these user stories in is as follows: As a blank, I want to do blank so that I can achieve blank. And when you look deeper into this format, you can see that it answers 3 questions. Who are we building this functionality for? What are we building? So what is the intention? And And why are we building it? What is the value that the customer is going to get from this? And by writing all of our requirements in this format, one, everything will be standardized, and two, we always keep our product user-centric. We always keep the user at the top of mind. And as we go through today's training, you're going to see some examples of these user stories. So for now, I want you to just know this format. And be familiar with it. Also, when you're writing user stories, those of you who have written them before, you may have heard of the INVEST concept before. And if for those of you who haven't, I'm going to explain it now. So INVEST, the I in INVEST stands for independent. And what this means is that each user story is potentially releasable unit of work by itself. It doesn't depend on another user story. User story in order for this user story to work. The N stands for negotiable. The Product Owner is open to negotiating the scope and content of the user story with the development team. The Product Owner is not creating all these user stories as a silo and then just telling the team, this is exactly what you need to do. The team is collaborating and listening to each other and coming up these user stories as a team. The V stands for valuable. Each user story needs to add value to the user. Estimable— each user story is concrete enough for the delivery team to give an approximate estimation, whether that's relative or absolute. So whether it's in days, months, or story points, but no matter what kind of estimation you use, you need to be able to tell how big this user story is. The S in INVEST stands for small, so each user story has to be completed within a short amount of time. Generally, each sprint is about 2 weeks, so a user story should be no longer than that. And if it is larger than that, then you need to split this up, and that's what we're going to talk about in today's lecture here. And finally, the T stands for testable, so the story can be tested. In the Agile world, tested means that a set of automated tests including unit, integration and acceptance test is delivered with the production code. So you want all of your user stories to be independent, negotiable, valuable, estimable, small, and testable. So when you're writing these user stories, keep the INVEST concept in mind. Now remember that the first letter of INVEST is independent, and here's kind of what I mean by that. This is a visual representation here. User stories are vertical slices. Vertical slice is a shorthand for a work item that delivers a valuable change in a system behavior such that you'll probably have to touch multiple architectural layers to implement the change. If it's a horizontal layer, then it's no longer independent because it's dependent on all of the other layers to work in order for the original functionality that you see on the UI layer to work. And hence, this is why user stories are written as vertical slices instead of horizontal slices. When you call a slice done, quote unquote, the system is observably more valuable to a user. So when a team work in vertical slices, they have more value explicit in their backlog, they have more conversations about value, they tend to get to value sooner, they get earlier higher quality feedback, and they become more predictable in delivering value. All right, now that we know what a user story is, let's talk about the 6 ways to split up a user story. So here's a summary here, and we're going to go into more detail about all of these techniques here. So as I mentioned earlier, I'm going to give you an example of a user story, right? So remember the format we saw earlier? Here is how you can apply the format, right? So let's suppose that our project is we wanted to create something like the next Spotify where a user can log in and then they'll be able to see our musical catalog and they'll be able to choose a song that they want to play. Our user story here is, as a teenager, I want to borrow digital music so that I can enjoy music that would otherwise not be available to me. We can see after the user story is that I have given, when, then. The given, when, then is our acceptance criteria. What the acceptance criteria does is that it outlines to the development team what this particular user story needs to look like, right? And then, but as we're looking at this specific user story here, the development team is like, whoa, whoa, whoa, hold on, hold on. This is actually going to be a couple months of work, probably more, because we have to create the digital library server to get into production. We've never done that before. We probably need to register and authenticate users. We've never done that before. We need a mechanism to select select a song, we need mechanism to store all of the catalog, and we need mechanisms for the user to be able to browse and search for music. Essentially, this user story is our whole project. It's not really a user story anymore. That's why we need to split this up. Then just before we move on here, I just want to read you the acceptance criteria here. Given the digital library is online, when I browse for a song and I choose a song, and I choose to play that song, then the song plays. Basically, what you see not in bold below the user story is the acceptance criteria, and it explains how that user story is supposed to work. Because this particular user story is just way too big, we have to split it up. The benefit of splitting up user stories is that it allows the team to focus on a small valuable portion of work, and it allows them to work from a prioritized backlog of small user stories so that the team can get value and high-quality feedback to the stakeholders much faster on regular intervals. All right, let's take a look at the first method that we can use to start splitting up these user stories. So the first method is called the zero-one-many rule. Basically, you isolate one component of your system and ask yourself what would happen if there's zero of these components, one of these components, or many of these components. So for example, assuming that we are trying to build this online digital library of songs, we would ask ourselves, how should the system behave if there are no songs in our catalog, if there are just one song, and if there are many songs? And then once you isolate this one variable, then first you want to get it working with no songs, Then you want to get it working with one song, and then you want to get it working with many songs. And then you will repeat this process for another variable. So you could do what would happen if there are no borrowers from the system, one borrower, or many borrowers. Let's take a look at how to apply the zero, one, many rule in practice. So let's suppose that our user story is that we have one single user and they view an empty library, and they want to see a meaningful message. So our user story could go something like this: As a teenager, I want to know that the library is empty so that I don't waste my time trying to browse songs that are not available, right? So we're breaking down the components of that big user story that we just saw to what will happen if there are no songs in the catalog, and then next user story, we'll see what will happen if there are one song in the catalog, and then there are many songs in the catalog, right? And then the acceptance criteria here could be, given the digital library is online and it has no content, and I am the only registered borrower, when I view the library offerings, then a message is displayed informing me that there are no offerings. Great. So because this user story is much smaller, the development team can first focus on, okay, great. What will happen if there are no songs in the catalog? Okay, let's get that working. Let's get that error message up when there are no songs. This is manageable for them. Once they get that done, it's like, how should the system behave if there is just one song in the system? So the user story here is that you have a single user. When they view the library, there's only one song that they can stream. So the user story can go something like this. As a teenager, I want to be able to play the song in the digital library so that I can enjoy it. So having covered the case with no songs, now we have the case when there's just one song. And then in the next case, we can see with multiple songs. So by breaking it up into zero, one, many, I hope you can see that it helps the development team to focus on different portions of the user story, and it breaks it up, it splits it up, right? And just to continue here before we move on, the acceptance criteria for this user story is, given the digital library is online and it has one song to offer, and I am the only registered borrower, when I view the single song that the library offers and I choose to play that song, Then the song plays. Great. So again, you can see the acceptance criteria just adds more depth and explains how that user story is supposed to work. Now that we have the catalog working for just one song, our next user story is how do we get the library working with many songs? So the user story here could be, as a teenager, I want to borrow from the bounty of digital music so that I can enjoy music that otherwise not be available to me. So the development team can now implement this much faster because they already have the system working for 0 songs and 1 song. So the acceptance criteria here is, given that the digital library is online, it has many songs to offer, and I am the only registered borrower, when I view the alphabeticalized list of songs that the library offers, I And I choose to play one of the songs and the song plays. Great. So then the development team would get the system working with multiple songs. And then after they do this, it's like, okay, how should the system behave with zero borrowers, one borrower, or multiple borrowers? So then they add another user story on top of these. for having multiple users. So as you can see, it's basically breaking it down so that they can add more and more to the system so that the development team isn't overwhelmed to begin with. So you isolate— again, you isolate the most important variable and then ask yourself what would happen if there's zero of these variables, one, and then many of these variables, and then Once you got it working for the first set of variables, then you go into the second set of variables. In this case, it's 0 songs, 1 song, and then many songs. And then once you get that working, then you say, okay, great, we have the songs working. What will happen if there's 0 borrowers, 1 borrower, or multiple borrowers? And then you repeat again for another variable. It could be like, what if there's 0 librarians, 1 librarian, multiple librarians? And then, you know, you just find the next most important variable to implement, the zero, one, many rule. The second method that you can use to split up user stories is by the workflow steps. In other words, you look at how do you accomplish the goal, what's step 1, 2, 3, 4, and perhaps you can break down your user story based on the workflow. So let me give you an example here. As a content manager, I want to publish a news story to the corporate website. At first, this may not sound like a really big user story, but as we dug deeper into the workflow, it turned out that it was quite a lengthy process because before any news story can hit the corporate website, it needs to go through extensive editorial and legal approval before it can get into the final stages. And because of this, we can break down this user story by its workflow. So first, it's as a content manager, I want to publish the news story with editor review. Then I want to publish the news story with legal review. And finally, as a content manager, I can publish a news story directly to the corporate website. So this is an example of how We have broken down the bigger user story by its workflow. The 3rd method that we can use to split up our user stories is operations. So when we look at a user story, we can ask ourselves, are there specific smaller operations that make up this bigger user story? Let me give you an example here. Let's suppose our user story is, as a user, I can manage my account. Managing your account can mean many different things, and we can break down what managing your account means into its specific operations. For example, here we can say, as a user, I can sign up for an account. As a user, I can edit my account settings. As a user, I can cancel my account. Signing up, being able to edit your account, and canceling your account all comprise and it's all under managing your account. So we can break down a bigger user story to its components if there are multiple operations that comprise of the bigger user story. So that's method number 3, operations. The 4th method that we can use to split up our user stories is by taking a look at the various user roles, the various different types of users that's going to be interacting with our product and see if there's differences in what these different users want and looking at ways to split up the user story based on these user roles. Let me give you an example here. So let's suppose that our user story is, as an admin, I want to manage customer requests. Well, when we're taking a closer look at this user story, we actually find that there are different types of admin, and these different types of admin want to interact with the system differently. So for example, the customer support analyst, they just want to be able to read the custom request and pull different reports and seeing how well we have been doing, what's the response time, how many requests have we received, are there any commonalities in these customer service requests, etc., right? So they just want to be able to read and get data from the different requests. And the customer support admin, they want to be able to reply and actually take care of these requests. And we also have the customer service manager. They only want to view and take care of the high priority tickets. So by taking a look more specifically at the different types of admin roles in this case, we are able to break down this user story based on the user roles, based on the differences these different types of admins are interacting with the system. So that's method number 4 for splitting a user story. Take a look at the different roles and see if there are differences between the different user roles and how they want to interact and accomplish the same goal. So if we just, we just in this case bucketed all of admin you know, one user story here, so as an admin, I want to manage customer requests, that is not specific enough because there are different types of admin who want to do different things in the system. Okay, hope that makes sense now. All right, now let's move on to method number 5, which is platforms. So we can divide our user stories based on platforms. Let me give you an example here. As a social media influencer, I want to upload images to my profile. Now this could be pretty daunting because we have different devices, different platforms these days, and so we can break down this user story based on platforms here. So we can say that as a social media influencer, I want to upload photos from my phone. As a social media influencer, I want to upload photos from my desktop, and as a social media influencer, I want to upload photos from my tablet. So here we see an example of how we're breaking down this bigger user story based on platform. So it's just getting it smaller and getting the user story into manageable chunks for the development team to then work on. Finally, we have method number 6, which is CRUD. And CRUD stands— the C stands for create, The R stands for read, the U stands for update, and the D stands for delete. They represent the standard operations the user can do. And then, so when you're looking at a bigger user story, you can apply CRUD to break down that user story. Let me give you an example now. So let's suppose our user story is, as a cook, I want to upload my recipes To my blog, so using crude, the first you know applying the C which is create. So as a cook, I want to create be able to create this recipe on my blog, right? And then and then we move on to R. So as a cook, I want to be able to read the recipe that I just created. So R stands for read, right? And then we move on to the U. As a cook. I want to be able to update my recipes whenever I want. And then lastly, we move on to D, which is delete, right? So as a cook, I want to be able to delete my recipes if I want to. Okay, so that is method number 6, CRUD. So create, read, update, and delete. And there you have it. These are the 6 methods that you can use to break down or split the bigger user story that you may have on your Agile projects. Thank you so much for joining me for today's video. Make sure you like and subscribe for more.