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 –
- 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
- 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
- It was first introduced in Extreme Programming (XP) to capture customer requirements
- The point is to make engineer understand the customer’s or business point of view instead of just feeding them with a solution
- User story once understood is analysed and helps in finding solutions, but it may become too big in size (also called Epic)
- 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
- 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
- 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:
-
- Family visiting to a restaurant to celebrate the birthday of their 8 year old kid
- A bunch of teenage just won football match and want to celebrate it to their favorite pizzeria
- An individual who is hygiene conscious
- An old couple who wants to have a peaceful, hustle-free experience
- 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:
-
- How much of our solution should be built as common for all customers?
- What features in the solution could we keep configurable?
- 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:
- User story slicing or splitting gives us the opportunity to seek faster feedback from customers and understand the end-user experience. Henceforth, reducing the rework cost
- By splitting user story, we could be in a position to showcase incremental values that could start addressing customer pain points gradually
- User story splitting helps us into identifying the complexity of solution and henceforth effective estimation and expectation setting with customer
- It also exposes dependencies, risks and assumptions that we are taking in building a solution
- By slicing user stories and accomplishing them, will add to team’s motivation for continuous delivery and customer satisfaction
What Makes A Good User Story?
A good user story onboards the development team member with all information that they require to understand the problem in customer context. In the context of sprint, it should be abiding to INVEST (Independent, Negotiable, Valuable, Estimable, Small & Testable). Let’s explore this aspect more.
-
User Story Formats
The most widely approach of user story is having 3 key information which is used as a template:
As a …<who is asking>.. I want …<what is the ask?>… So that ..<why do you want it?.
There could many more questions that we may want to get answered but they might be more on ‘knowing the solution’ stage, but before that we need to focus on ‘knowing the problem’ stage and that is where the format help us in knowing the basic information like the persona who is affected, the experience they want to have and the benefit they will get once the solution for this story is provided to them.
-
INVEST In Good User Stories
INVEST is a quick-tip for the Scrum team to maintain the sanity of requirements. It is an acronym and below is the meaning of each alphabet and the reminder it gives us:
- ‘I’ stands for INDEPENDENT & it guides us to draft a story that is not dependent on other items and that way we could avoid the time wasted due to on-hold state
- ‘N’ stands for NEGOTIABLE which could allow us to either swap the story with other important story or remove & deprioritise if its need is not there
- ‘V’ stands for VALUABLE and that helps us in staying focused on the problem instead of assumptions and not-so-important work items.
- ‘E’ stands for ESTIMABLE where it pushes us to ask more questions so that we should be confident to estimate the work items
- ‘S’ reminds us to keep the story SMALL so that it could be delivered sooner rather than later to address customer concerns faster
- ‘T’ stands for TESTABLE to measure if the story will meet the customer’s expectations
- User Stories Are Vertical Slices
‘Vertical slicing’ is inspired from slicing of the cake where we can see all the layers in a cake and have an overall experience of the cake by just having a single slice. It helps us in terms of involving all the components of a system or solution that is required for a feature to be functional. The solution for the story may include UI (frontend), API layer (Backend where the business logic is written), Database (where data is stored and called) and other supporting components. In certain cases, that might not be the case but it is a recommendation to think through vertical slicing to enquire about the possibility of making the story more functional and contextual to solving core problems of the customer.
Perfect Your Estimates! Discover estimating techniques for agile projects & streamline planning for better outcomes.
Why Are You Struggling With User Story Splitting?
There are many struggles with user story splitting and below are the top reasons because of which it becomes difficult:
- Lack of information resulted by unavailability of stakeholders and intent to research on problem source
- The complexity of stories due to multiple levels of information spread across technological limitations, business bottlenecks, compliance, security and so on.
- As a scrum team not collaborating to split the story and it ends up being job of either Product Owner only or possible just the Development team
- Confusing stories with tasks and then instead of splitting big story to actually ‘story’, we end up creating numerous tasks, and that result in delivery the bigger story as a whole
- Specifying The Solution within the story dilutes the point of understanding the problem and narrows down the opportunity to think creative solutions
- Instead of vertical slicing, if we do horizontal slicing then the stories end up being frontend stories, backend stories, database stories and that NOT a story but tasks
- I believe that not allocating sufficient time is also one of the reasons due to a ‘rush’ culture
Understand your team’s Agile Maturity Levels with our simple tool. Start today and work towards improved agility and better project outcomes.
The SPIDR Technique For Splitting Backlog Items
SPIDR is an acronym, Spike, Paths, Interfaces, Data & Rules. SPIDR is one of the popular user story splitting techniques that helps us with exploring various dimensions to split complex stories. Here is the explanation –
- Spike is applied when a story demands research to understand the problem statement better and at times we also do Spike to explore the possibility of solution by doing POC. Here we create spike stories to learn more.
- Paths helps us in wearing that lens by which we could visualise the different flows that a user might night need to go through to complete the overall experience and we can split the story flow-wise
- By Interfaces we focus on various platforms or applications where a story is supposed to function for users like mobile apps, desktop etc.
- Splitting user stories by Data sets where we could start with simple data sets earlier and gradually go ahead with complex data sets also
- Rules actually denotes business rules that we need to follow for certain stories and we could split it based on individual business rules
Conclusion
Splitting user stories should not be looked at as another activity that we should do as a part of the governance process, we see it as a necessity to seek more clarity, deliver value to customers faster and identify confusions or gaps in our understanding.
There are user story splitting techniques but jumping on it directly may add up to more confusion henceforth teams should be trained to see the techniques as tools to be used when we get stuck, before that we should start with identifying the problem, the challenges faced by customers and comparing as-is and to-be approaches. Many times the splitting of requirements happens naturally when we just ask a question that ‘How might we address this challenge faced by customers in a continuous way in a gradual fashion?’.
With this our blog on “Why are you struggling with story splitting” comes to an end and we sincerely hope that the reading is worthwhile. Benzne as an agile software development consulting company would be glad to support you in your agile transformation journey. Please write to us at consult@benzne.com for any suggestions or feedback.
Frequently Asked Questions About User Story Splitting
1. How can poor collaboration affect story splitting?
Poor collaboration will lead to lack of information and hence assumptions which may lead to rush solutions that we provide to customers. Also, it may end up slicing user stories horizontally which may not either address the issue with clarity of requirement and also continuous delivery of solution.
2. What are some common indicators that a team is struggling with splitting user stories?
Some common indicators that the team is struggling with user story splitting are:
- Spilling of stories across sprints
- The stories even when completed adds no value to the customer
- The story can not be demonstrated or tested or negotiated
3. What techniques can help improve user story splitting skills within a team?
Below user story splitting techniques can improve user story splitting skills in a team:
- INVEST & SPIDR could be good start to improve user story splitting skills
- Also, suggest brainstorming using 5 Whys and fish bone analysis
4. How can teams ensure that they are not enforcing all business rules from the start?
The teams need to list down the business rules which they need to comply with while implementing the user story and they should try to distinguish between the must have, should have and could have parameters. Also, they need to be understood in terms of flows that could happen due to business rules which could be the basis for splitting the stories.
5. How can a lack of clarity in requirements impact user story splitting?
Lack of clarity in requirements leads to lack of understanding of the problem that customer or business is facing. It is very similar to someone having stomach pain but without proper diagnosis, should we just remove the appendix from the stomach?. If we do so, if the stomach pain still happens and the proper diagnosis points out some other issue, the doctor can not put the appendix back and say sorry to the patient. Its not acceptable. Likewise, we need to be mindful of not rushing to a solution without understanding the requirements. Seek training and coaching on this aspect from an agile transformation company if possible and required.