December 10, 2023

What Is User Stories In Agile? And Techniques To Split Them

Sujith G

User stories are single line requirements in the form of a story of what an end user wants and why. An ideal user story format followed by the industry is “As a , i want , so that . The reason why agile requirements are in the form of user stories is fairly simple – we need to get feedback from the users and we need to get the feedback as early as possible. However, when it comes to a practical scenario, teams tend to pick user stories which are too big to deliver or even showcase in a sprint.

There are a lot of practical antipatterns when it comes to writing stories and implementing them.

Are your teams doing any of the below mentioned points in your sprints?

Stories getting spilled to the next sprint because it is too big?
Taking tasks from big stories to fill the capacity of the current sprint but committing to deliver the story in a future sprint?
Dividing a story and creating a story based on skill set? (Development story, backend story, frontend story, testing story etc)

If yes, you have landed on the right page, because this blog aims at explaining

What is a User story and what are its characteristics?
INVEST story writing
Vertical and Horizontal slicing of a user story
Why do we have to split a user story into smaller pieces?
Some sample techniques to split the story with examples

What is a User Story?

A User Story is a simple/brief one line requirement written in a simple language from a customer / user’s point of view. It has 3 parts to it

Persona
Demand
Purpose

An Ideal user story is in the form of “As a , i want , so that < What is the purpose?>

Examples

As a , i want to , so that
As a , i want , so that i can

Characteristics of a User Story

A user story is a requirement which

Always has a business value associated with it. There are always reasons why a requirement is born, it can be based on consumers feedback, competitive advantage or to generate more revenue.
Will Help teams get feedback. A user story , when converted to a software should always present itself as a point which can get feedback as quickly as possible. Feedback can be of different levels, is it what my consumer wants? Is it how my consumer wants? Does this add value to the product?
Triggers a conversation. A user story with enough information should trigger a conversation between a PO and the development team. There has to be common understanding between the teams and the POs in terms of what the PO wants or what the teams need to develop. And user story is the starting point which should trigger a conversation
When Delivered, it is usable by someone. Delivering an API or a UI screen or writing a login will not help teams to get valuable feedback from a business standpoint. So a user story has to be written in a manner that there is something usable by the end user when delivered
Is an Increment to your product. Since agile is a incremental and iterative model, a user story when delivered adds up to the product list of capabilities when delivered

INVEST Story Writing

Writing a good user story comes with a lot of practice and experience. However, INVEST is one of the most recommended techniques for writing a user story. A PO has to keep in mind the below mentioned points while writing a good user story

A User story is INDEPENDENT of other stories. A story can be worked upon in any priority in the sprint. We should not rely on finishing a less valuable story to start more Valuable story
A user story strikes a conversation between the teams and the stakeholders. Scope can be NEGOTIATED by the dev teams and product owner
A user story is VALUABLE to the end user or the business. When the user story is delivered, user can give feedback or the company can see some business improvements
A user story has enough details so that the development team can ESTIMATE
A user story is SMALL enough to be tested and completed in one sprint.We will not wait for 2-3 sprints to get feedback
A user story is TESTABLE to check with completeness of the sprint

Breaking / Slicing a User Story

Checking if we are in the right direction and changing based on the needs is one of the main idea behind agile ways of working. And one way to do that is to get constant feedback from the customer, consumers or the product team.

We understand that the requirements come in various sizes. Some requirements are small and some are big. Smaller requirements take less time to deliver and get feedback. But the Million dollar question is “how to get feedback for a big requirement which will take a lot of time to deliver?” and the answer is to break the requirements (User stories) into smaller requirements (User Stories) and deliver it continuously.Why do we have to split user stories into smaller pieces?Simply because it is too BIG!!! But also,

The story is so big that we cannot deliver it in one sprint

It is too complex and complicated. It might have too many steps and may be difficult to test

Smaller stories when completed gives the teams sense of accomplishment

We might not have all the information about a story. We might as well finish the part of the story which we know and get it done

Not to get stuck!! Smaller stories help teams get feedback and helps in consistent delivery

Horizontal and Vertical Slicing of User StoriesThis section talks about one of the important aspects of breaking a big user story into smaller stories. Imagine a big story which needs to be broken down into smaller stories, and this story needs Backend logic, API development, Frontend development and testing as depicted in the picture below. Also, let’s take a sample user story as mentioned below,Sample Story : As a consumer, I want to login, so that I can place an order from the system. Now this story will need backend logic to be written, API to be developed, UI to be developed, Integration of API with the UI and then testingAcceptance Criteria:

Error must be thrown for invalid credentials

Password must be case sensitive

Password must be 8 letters long and must contain 1 number, 1 special characters

Horizontal Slicing is breaking the story with respect to the layers / skillset. We have observed many teams practicing this method where the story is broken down into smaller stories but technology wise. In this case the above mentioned user story will be broken like

Story to write backend login

Story to prepare API

Story for UI development

Story for testing

This is a bad practice and not recommended because none of the 4 stories (Mentioned above) is testable and releasable. UI alone or API alone when developed cannot be released to the end user / PO to get feedback

Vertical Slicing is breaking the story with respect to the capabilities/functionalities/operations rather than any skillset. In this case, the above example story can be broken down into

As a user, i must be able to login with valid credentials

As a user, i must be able to see error when i try to login with invalid credentials

As a system, i must validate for password length

As a system, i must validate the password condition

In this case, all 4 stories can be individually developed, tested and delivered to get feedback and we have broken 1 big story into 4 smaller stories which can be quickly developed and helps the team to get feedback.Techniques to Split User Stories into Smaller StoriesThere are several techniques followed by different teams to split a big user story into smaller user stories. Below are a few mostly used techniques which we recommend strongly to use for splitting stories.

Based on User Roles/Personas: If your story is too big and multiple roles are involved in completing a transaction, it is better to split the stories as different roles / personas contribute differently

Based on workflows: If a story has multiple actions / steps , one way to break the stories is to create stories for each action.

Based on Platforms: If the product is catered to users with different environments, you can also break the stories with respect to platforms, web browsers, operating systems

Based on CRUD Operations: If a story involves Creating, Replacing, Deleting, Updating of a data set, best way to divide it is with respect to the operations involved

Based on Acceptance Criteria: One of the first options and the simplest ways to break a story is with respect to the acceptance criteria. A classic example shown in the image above and also in the Sample Story ( Vertical Slicing )

Based on Data Types: A story involving different data types can be broken down into smaller stories for each data type. Multimedia upload can be broken down into photo upload, video upload, audio upload( Just a sample )

Business Rules: If you are developing a feature which behaves differently in different regions, or the behavior is rule driven, then you can also break the user story rule wise

Build a winning Agile Transformation Roadmap with Leadership Consulting. Achieve your goals with tailored strategies and expert guidance.

ConclusionThere are several ways / techniques to split a user story into smaller pieces. You can use one of the above mentioned techniques or even mix and match the techniques. The intention is to break the stories logically which can be developed, tested and delivered so that we can get quick feedback.This brings our blog on “User Stories & Techniques to split it” to a conclusion.
Please reach out to “consult@nextagile.ai” for any suggestions or feedback.

Sujith G

Sujith G. is an agile practitioner with expertise in setting up the agile environment by coaching and training teams, individuals and stakeholders in the area of lean agile software principles. He has overall 12+ years of exp out of which 9+ years have been in Agile and Scrum implementation and adoption. Sujith has coached 70+ teams on agile practices & implementation techniques and has extensive experience in setting up metrics, JIRA & Azure DevOps. Experienced in identifying gaps in the system, creating scrum awareness, piloting and scaling scrum.

See author's posts

Talk to Our Experts

Get expert guidance within 1 business day.

No spam. Your information stays private

Generative AI in Healthcare: Use Cases, Implementation Guide and What Comes Next (2026)