Stop Feeling Overwhelmed: Split User Stories in 2 Steps

In this video, we will discuss what user stories are. What is the difference between epic, user stories and task? What are the benefits of splitting user stories?

And finally, how to split a user story? We will discuss 6 different patterns to splitting a user story and an easy to use pattern that I devised myself, which if you would like can help you bypass all other patterns. Hey Friends!

Welcome back to the channel. If you're new here, my name is . I am an Executive, Agile & Leadership Coach based in Toronto, Canada, and this is the seventh video in an ongoing series where I'm trying to simplify the process of planning an Agile product, starting with product vision for a better roadmap, release plan, finally learning how to create product backlogs full of effective bite-sized user stories.

So if you're a scrum master or an agile coach consider subscribing to learn some actionable and super effective ways to be Agile. There are timestamps available, so feel free to skip around the video. If you feel like it.

But for now let's get started. So what are user stories? Now, I will not go into too much detail as I will be covering it in absolute granularity, in a separate series, dedicated to user stories.

But for the sake of this video, here's the definition. A user story is a chunk of functionality that is of value to the customer. Commonly written in the form of this template, use story, as an idea was borrowed from extreme programming, which introduced these a small packets of information pointers to document and communicate requirements, priorities, acceptance criteria, and needs of the user.

The reason why I use the term pointers is because, and it will make more sense if you have a programming background is because just as pointers, user stories, hold the address to a series of conversations about the desired functionality. For those who do not have a programming background a user story acts as a trigger to chat about and surface details and everything else required for the development work. Okay.

If you are still not able to grasp the concept, let me try again. A user story is nothing but the story behind WHY, a user, needs something. We record all these WHYs in a backlog, just like our initial product backlog.

When the right time comes these WHYs reminde us about the user's needs and provide us an opportunity to discuss what is required to fulfill those needs. Okay. Now I am officially out of all the definitions of a user story, as someone who's curious about user stories, if you still don't understand what a user story is, then feel free to ping me so that your thirst for user story definition is quenched forever.

Wait. . .

Now that we know what user stories are, let's look at the difference between an epic a user story and a task. Keeping simplicity in mind and epic is nothing but a collection of multiple user stories. It's a large user story that can be divided into numerous small user stories.

Here's an example of an epic. As an online seller, I can manage my product online so that I can keep my product up to date for customers. Now, this may seem like a regular user story, but if you look at it carefully, the word manage could mean different things.

From an online shop perspective, it could mean adding new products or updating, deleting, or hiding existing products. So this is a story or epic can be divided into smaller user stories. Like, As an online seller, I can add new products so that customers have purchase options.

As an online seller, I can update existing products so I can adjust for changes in pricing. As an online seller, I can delete products so I can remove products that I don't sell anymore. As an online seller, I can hide products so they could not be sold when out of stock.

Let's have a look at the difference between a task and a user story. Now you won't believe if I tell you the number of people I've worked with in the past, didn't know the difference. I user story provides business value.

A task, on the other hand, does not provide business value on its own. A user story is something that an end user understands. A task, on the other hand is a technical or non-technical activity required to complete a particular user story and usually does not make sense to the end user.

For example, As a house seller, I want my home painted in a neutral color, so it can appeal to a wide variety of buyers. Now, if this is a user story that delivers value to the house seller, then mixing colors is a task that a painter will perform as one of the steps to deliver that value. However, mixing color in itself is of no value to the house seller.

Okay. Let's talk about splitting user stories, but first let's understand why do we need to split user stories? Here are some key benefits.

Number one, small user stories are easier to understand. Smaller the user story, the less complicated it is. So there are less chances of any misunderstanding about what is, or what is not included as part of the story.

Number two helps in identifying waste. If your team splits a large user story appropriately, you may find that some of those smaller user stories are not essential to delivering the expected outcome. For example, if a large user story is split along different scenarios, some scenarios may not be relevant or they may not happen.

In such cases, your team can save time by not addressing those scenarios in the development work. Number three provides faster feedback loop. Smaller user stories could be delivered sooner, which means your team can get the feedback sooner as well.

And if your team took a wrong path, then they were wrong, for less time. Now that we know why we need to split larger user stories into smaller ones, let's get into the realm of HOW. How do we actually split a user story?

Can we just physically divide a user story into smaller pieces? For example, if a large user story or an epic is estimated to take four months to complete,why not just divide it into eight equal shunks, each taking two weeks sprint to complete. Now that's a valid point, but here's the thing.

As discussed earlier, a user story is shippable and valuable to the customer. I repeat a user story is shippable and valuable to the customer. If those eight chunks independently provide value to the end-user, then fair enough.

We should definitely do that. But if that's not the case, then we will be delivering value to the customer at the end of the eighth sprint. Which is not very efficient and somewhat same as delivering value using the waterfall approach.

So ideally we should strive to split epics into smaller user stories that are shippable and valuable to the customer. Keeping shippable and valuable as the north star for spitting user stories. Let's see how granular we can go with a user story.

When it comes to splitting, the rule of thumb is to split a user story, so it can be completed within a single sprint. You can go as small as you want, but only to a certain point after which splitting further would result in the user story, losing its fundamental property of. .

. . well.

. . .

being valuable. So split an epic to a user story, but not to a point where it becomes a task that is not valuable to the end user. With that out of the way, let's look at the most common misconceptions about splitting user stories.

Number one, letting one person split the user stories. Now there is a common misunderstanding that only the product owner is responsible for maintaining user stories. While it is true for backlog prioritization, product owners usually do not have the technical knowledge required to split user stories.

To ensure that we explore all options. We need our entire team to bring different perspectives or skillsets to the splitting exercise. Number two, trying to break all the features in one go.

Now, even with our initial product backlog that we prioritized in the last video, which by the way, if you have not voyaged, a link of the video is in this corner or in the description, if you're watching this on YouTube, even our initial backlog with ten items may result in hundreds of small user stories spanning across multiple releases. This may result in a lot of complexity which the team may not be ready to handle. So instead of breaking down, everything consider starting with roughly one release version of user stories.

Your team must be able to look at the prioritized initial part of backlog, draw a line in the sand and say, Hmm, this seems to be doable. So consider starting with these doable features. Adding remaining over time as more information is available.

Number three, splitting user stories horizontally. Now let's think of a user story as a slice of cake. For example, the bottom layer may be our database layer.

The middle layer can be the logic clear while the top layer is our user interface layer. While each layer contributes to the overall story, they don't add much value on their own. With these layers in mind, one obvious option is to split stories horizontally.

This is an easy place for many teams to start, especially those from a silo development background. To understand it with an example, let's imagine that you are an online seller. For each product that you sell, you have a product description page on your website.

The product description page has a place for basic information about the product and the ability to embed product review videos from YouTube. The website stores, all this data in a backend server. Now creating a product description page is a large user story.

While splitting the story, the team's first instinct may be to divide the story into three smaller stories along architectural layers of database, logic and UI. For example, we may have one story to represent the UI portion, a second story for the server side, which may include connecting to YouTube or other social networking sites. And a third story for saving data into the database.

Now, while this may seem obvious at first, there are actually a lot of disadvantages with this method. It again comes down to stories, being valuable and shippable. Stories that are split horizontally often don't provide any tangible value to the end user by themselves.

As a cake eater I won't be interested in eating a single layer of the cake. In a typical scenario! I would however, eat the entire slice.

Similarly, we can't just ship a product with just user interface with no backend server changes and expect the user to find value in it. Okay. So vertical slicing is what we need.

But it's not that easy. Vertical splitting requires that developer work vertically across the stack from UI to logic to database. So a team which is new to this kind of development may take some getting used to and some learning.

The most efficient way to work vertically is to have full stack developers. That way a story can be typically executed by one person. So if your team is not used to working on vertical stories, then they're very likely to be doing the horizontal ones.

This is because each person typically only knows about a single layer or tier of the application. In such cases, when you introduce vertical stories, you can expect the team to split those stories into tasks, corresponding to those layers, and then distributing the task to different people. This can be very inefficient.

The best way to resolve this is to tolerate it initially while making it clear that the long-term goal is to work on vertical shippable stories. You can slowly achieve this by having team members across layers, pair program. So to build cross layer expertise, eventually enabling people to be completely independent.

All right, with that out of the way, let's look at different patterns that we can use to split user stories. How do we start? We start with our initial product backlog that we prioritized in the last video.

We then go through each item in the backlog, one by one from the very top and ask ourselves two questions. First, does it even need splitting? As discussed earlier, a user story is a good candidate to be split, if it is longer than the length of a single sprint.

Or if it takes longer to deliver, then your team is comfortable, waiting for feedback. After we have decided and selected a story to split, the next question to ask is which pattern we want to use to guide our split. Now, there are a slew of different approaches that people have identified for splitting backlog items.

In my opinion, however, all the gazillion of them are, but variations of the six basic patterns , W. A. H.

Z. U. R which stands for workflow steps, acceptance criteria, happy/ unhappy path, zero/one/many, user roles, and finally rules typically business rules.

Let's start with the workflow steps. Suppose that after a rough analysis of the initial backlog item, you find out that the item in question involves a workflow of some kind. In that case, we can split the item into individual workloads steps, where each step can be a separate user story.

Let's take a look at one of our initial backlog item or feature or epic or whatever you want to call it, as an example. As a customer, I can pay for the goods in my shopping cart so that I get the product delivered at home. The middle section of this Epic, when seen through the lens of the workflow steps pattern can be divided into four different parts.

And these four different parts will give us our four different user stories. As a customer, I can log into my account. So I don't have to enter my shipping information every time.

As a customer. I can confirm my order so I can correct mistakes before I make the payment. As a customer, I can pay for my order with credit card, so the order can be confirmed.

And As a customer, I receive a confirmation email with my order so I have proof of my order. Pretty straightforward. Let's move on.

Next is acceptance criteria. But what is Acceptance Criteria in the first place? In simple words, acceptance criteria is a list of conditions that the user story must satisfy to be accepted by the product owner as done.

We will understand acceptance criteria in detail in the upcoming series of tutorials on effective user stories. For now, let's take a look at an example, initial backlog item. As an online buyer, I can use my reward points so I can redeem those points while shopping.

Again, the middle section of this epic, when seen through the lens of the acceptance criteria pattern can be divided into three different criterion. One. I can see my reward points in my account.

Two I can select the number of points to use. And three, I can check the balance left. Each criterion will create three separate user stories.

As an online buyer. I want to see my reward points in my account. So I know whether I have points that I can redeem.

As an online buyer, I want to select the number of points to use so I can redeem only the points I need. As an online buyer, I want to check the balance points left, so I have an up-to-date view of the points available to spend. Okay, let's move on to the next splitting pattern, happy / unhappy path.

While working with the initial backlog items, you may find an Epic that involves a happy or multiple unhappy paths or workflows. For example, an initial backlog item like: As an online buyer, I can log into my account so I can access my secure billing information, can be expanded into one happy path user story. like, As an online buyer, I can log into my account so I can access my secure billing information, which is if you notice is the original story itself.

And two unhappy path stories. Like, As an online buyer, I can reset my password than my login fails, so I can log back in again. As an online seller, I can block users after three failed attempts so I can protect the side against hackers.

Next zero one many. Now there might be a case when even after splitting a user story, you find that it is still too big. In these cases, we can use zero, one, many technique to split a user story further.

For example, the epic, As an online buyer, I can view my shopping cart so I can review the items selected before I check out, can be divided into, As an online buyer, I can view my shopping cart with zero items selected. As an online buyer, I can view my shopping cart with one item selected so I can review the items, before I check out. As an online buyer, I can view my shopping cart with multiple items selected so I can review the items selected before I check out.

Next pattern is user roles or personas. If a user story involves or interacts with different roles or personas, we can split a user story for each such user role or persona interaction. For example, the epic As a restaurant owner, I can make reservations so I can provide timely service to the customer can be divided into two user role stories, like, As a restaurant owner, I can make reservations for members.

And as a restaurant owner, I can make reservations for guests. With user roles being members and guests. And two persona user stories.

Like as a restaurant owner, I can make reservations for members with no credit. And as a restaurant owner, I can make reservations for members with credit. Personas being members with credit and without credit.

Finally, let's have a look at our last pattern to spread user stories, rules. We use this pattern for stories that involve a number of explicit or implicit business rules. Let's take a look at an example, initial backlog item.

As an online seller, I want to process orders of the customer so they can get the delivery of the product at home. Again, if you carefully look at the middle section or the what part of the story through the lens of the rules pattern, we can think of various business rules that we want to apply. Each of these rules will create a separate user story.

Like As an online seller, I can decline orders below $10 because there is no profit in such orders. As an online seller. I can decline orders from outside my city, because the shipping expenses make these orders unprofitable.

As an online seller, I can reserve ordered products from the stock for 48 hours, so future customers see accurate availability of products in stock. As an online seller, I've want orders for which have not received payment within 48 hours to be automatically canceled, so the product becomes available for other customers. Okay.

So this was WAHZUR. When I started as a scrum master, I used these six patterns to help teams split large backlog items into smaller user stories. I later devised a few techniques of my own.

The easiest of them all is T-SPLIT technique. This is how it works. In the T-SPLIT technique, we look at the user story's what section, and then analyze it in two ways, breadth wise and depth wise.

For example, if our initial backlog item is As a traveler, I want to pay for my stay at the hotel so I can check out. Bredth wise analysis will give us, one, I can be using credit card. Two, I can be using debit card and three, I can pay using American Express.

Depth wise analysis on the other hand will give us, one, to pay I need to enter my address. Two, to pay I need to enter my car details. And so on.

T-Split is the only pattern that I have been using lately. And I have found that this is more than enough to split most user stories. In cases where I can't use T-SPLIT I use WAHZUR.

Okay. Now that we know how to split a user story and how to use T-SPLIT technique. Another question that comes to mind is.

How do we check if the splitted user story is in fact a good user story? That's actually a very good question. And here's how we do it.

All we need to do is check the final splitted user story against the handy INVEST criteria. We check if the final user story is independent, negotiable with the stakeholders, estimable, small, which we can safely ignore because that's the purpose of splitting in the first place, and finally, is it testable. One advice that I would give is that don't stress too much on it.

In my experience, I have found that only 35% of the user stories actually pass the full invest criteria. Okay, before I end this video, let's talk about what we can do if he cannot split a user story. The first thing that we can do is to do what makes sense.

If you're not releasing every sprint, then it's perfectly fine to split larger stories into smaller items that do not provide business value independently. Second, if the situation is an exception, then do not hesitate to stretch a user story to multiple sprints. But at the same time, make sure that your team knows that it's an exception and that it should not happen on a regular basis.

And third, if a situation is common and you routinely find such items in your backlog that cannot be split or are too big, then it's time for your team to discuss how to adjust the process, in a way that actually allows such user stories. For example, trying to use Kanban where you give up iterations completely. To summarize it all, just be Agile.

In the next video, we will learn about story maps and how we can use them to identify dependencies. So there you have it. This is how you split user stories.

But again, do not stress about it. Just split what you can. If you like this video, then give it a thumbs up, subscribe, and don't forget to provide your valuable feedback in the comments.

I'll see you in the next video.