User Story Splitting: How to Break Down Work in Agile

Introduction to User Story Splitting

I believe it will be amazing to know that how many engineers who are applying Scrum are not aware of user stories? I believe the probability is 0.001% out of millions of engineers across the world. And the mindboggling aspect is that the user story is not even part of scrum guide. The authors of scrum simply use the term ‘Product Backlog Items’ to represent the unit of work in a list called Product Backlog which contributes in building and improving the product!

So before we dig deeper into the concept of splitting user stories, let’s briefly understand the ‘user story’ as a concept to bring alignment for better understanding of user stories. A few things to note –

1. User stories are not requirements, it is a 1-line statement to trigger the conversation that helps us in understanding the problem source, the ‘demand’ and the expected benefit and then identifying relevant solution
2. A user story has a list of acceptance criteria but that shouldn’t mean that we end up making the code more complex. The quality and other aspects like stability, performance are intrinsic
3. It was first introduced in Extreme Programming (XP) to capture customer requirements
4. The point is to make engineer understand the customer’s or business point of view instead of just feeding them with a solution
5. User story once understood is analysed and helps in finding solutions, but it may become too big in size (also called Epic)
6. User story is not a task, as in many teams we have observed that it ended up getting used in a very loose manner and lost its essence
7. Splitting a user story into smaller stories should lead to better understanding of the problem, as it might be too vague to imagine a solution with a large work item
8. Splitting a user story should not end up being tiring and should not be an overkill

There are many more aspects to understand the user story but the above context should help in better understanding of the context explained in this blog.

Overview Of Splitting User Stories

User story splitting is a collective activity which involves members of business, product and technology. It starts with asking an important question to ourselves, what do we need to achieve after splitting user stories?

The answer resides in context of different roles who are involved in building the product:

1.  As a user or customer, they communicate in terms of symptoms to the problem and many times they also have great ideas to propose solutions. A user or a customer is a subjective term as there might be hidden context if we start identifying individual personas that we group casually in a term called user. For example, in a restaurant we call the customers as guests and if we are building a solution for better experience we might need to identify different personas and conduct empathy mapping to elaborate their experiences. In this context, let’s identify the personas:

1. 1. Family visiting to a restaurant to celebrate the birthday of their 8 year old kid
   2. A bunch of teenage just won football match and want to celebrate it to their favorite pizzeria
   3. An individual who is hygiene conscious
   4. An old couple who wants to have a peaceful, hustle-free experience
   5. Take-away orders

2. As business, while they want to delight the customers or user of the company products and solutions, they need to be mindful of their own interest which could be linked to revenue generation for them and the shareholders, reducing operational costs, adding a customer base of a new market and more

3. As a product owner, you want to keep up the interest of both customers and business on priority but you also need to identify the ways to balance the stability and efficiency of the product by pondering on questions like:

1. 1. How much of our solution should be built as common for all customers?
   2. What features in the solution could we keep configurable?
   3. On what aspects should we restrict the customization to individual customers to avoid operational hustle?

4. As a development team, we want to help our customers, business and product by delivering requested features but at the same time we need to be mindful of architectural change, impact to code complexity, quality aspects, technology revamp and other.

Likewise, when we keep on exploring the external and internal stakeholders, we get so many perspectives that could help us in seeking clarity which leads to breaking down a bigger work into smaller work items that is simpler, doable, brings confidence, reduces vulnerability and enables us to deliver value continuously to our customers.

Why Story Splitting Matters?

In short, we split the story because of one primary reason i.e. the story is too vague to understand the context of the persona (whose problem it is), the demand (the problem to solve) and the purpose (the benefit that the persona will get). The second important reason is to enable the team to deliver continuous value to customers instead of making them wait for a huge Epic to finish completely.

The splitting of stories helps us in seeking clarity which helps us in identifying the most appropriate solution to satisfy the user role who is struggling and has a bad experience.

There are techniques like INVEST & SPIDR which are popular to split user stories. Also, some teams follow the thumb rule of splitting user stories till it is small enough to be finished within a sprint. What is important is to ask ourselves if our splitting helps us in delivering the value to customers continuously?

The splitting of user stories unravels clarity that further rolls up to impact customers and businesses. I have experienced following situations where user story slicing has greater significance than just working on EPIC: