9 Techniques for splitting large user stories

Having small user stories is one of the best things a team can do to improve Scrum workflow. Not only are smaller items easier to understand and estimate, but they are also less risky for a team to take up.

However, splitting up big user stories into smaller ones can be challenging and sometimes tricky to do right. This article will cover nine techniques to help split use stories in this article.  But before we do, let's first understand what user stories are.

What are User Stories?

Explanation 1 - General Template

The most common definition is:

"A user story is a unit of functionality valuable to the user."

And it's typically written using the following template:

As a (who wants to accomplish something)
I want to (what they want to accomplish)
So that (why they want to accomplish that thing)

This is also known as the who, what and why.

Explanation 2 - Extreme Programming

User stories aren't prescribed in the Scrum Guide (as often incorrectly assumed), but they are common best practices. User stories originated from "Extreme Programming" to document "use cases" and became a part of the workflow for delivering a finished product increment. Since then, user stories have been found in a couple of agile development frameworks as the primary way to capture high-level requirements.

User stories capture:

• The need of the user
• The priorities of the work
• Requirements
• Acceptance Criteria
• A set of requirements that must be met before we can mark the user story as complete
• It makes the user story testable

Explanation 3 - A Conversation

A user story is a card to trigger and capture conversations about the desired functionality and encourages collaboration between product and Engineers.

"All agile user stories include a written sentence or two and, more importantly, a series of conversations about the desired functionality" - Mike Cohn, a main contributor to the invention of the Scrum software development methodology.

User stories are created incrementally in three stages:

• Have a Card with a short description of the user's needs. A card is chosen as it should be small enough to fit on a card.
• Have a Conversation to refine the needs of the user further. Discussion can include Engineers, product owners, scrum masters, and stakeholders. Anyone who can help create a shared understanding of the user's needs.
• Confirm the requirements by listing them as Acceptance Criteria. Even with a thorough conversation, there's always an element of doubt, so listing the requirements help us test the finished product, so we know it meets all the criteria.

Above is also known as the 3 C's from XP.

Explanation 4 - Engineer's Perspective

A user story captures the requirements of what the engineers need to build.

Examples

• "Customer confirms items in the shopping cart."
• "Customer provides credit card number."
• "Check the expiry date of the credit is valid."

Explanation 5 - User's perspective

A user story is a way to understand "why" a user needs something. What problem are they trying to solve?

As a user, I want to view my statement balance, So that I can pay the balance due.

"A user story is an informal, general explanation of a software feature written from the perspective of the end user. Its purpose is to articulate how a software feature will provide value to the customer." - Atlassian.

A User Story

A User Story is all those five explanations:

1. It follows a particular format on a small card.
2. The card is written from the user's perspective, so everyone knows what value we deliver.
3. It includes criteria that must be met to be marked as done
4. It is clear to the Engineer what needs to be implemented.
5. It allows for a discussion to clarify features.

"User stories are something that is shippable and delivers value."

Why Split User Stories?

Benefits of splitting split stories:

• Smaller user stories are easier to understand.
• Smaller user stories are easier to code review and test.
• It helps in identifying waste. If you split up a large user story, you might find some smaller user stories aren't needed as some scenarios won't happen or are not relevant.
• For large items, there's a higher risk of feature creep as the scope of big.
• Smaller user stories provide a faster feedback loop.
• Have more visibility on work, easier to adapt and change
• Increase the chance of being completed in sprint and release.
• More people can pick up the item. Easier for someone less familiar with the code base to work on it.
• More reliable estimation and forecasting

Benefits of not splitting user stories:

• More convenient and faster for one developer to do all the work? - but is it faster in the long term? It would be harder to do good code reviews and a tendency to reject significant changes as it's not worth the effort to redo since it's already working. It's also more demanding to test correctly, so there is a greater chance of reworks.
• Less admin work?

Bad practices in User Stories

Slicing user stories horizontally instead of vertical isn't recommended as the work won't deliver any value to the user until the team completes all items. A typical example is splitting by architectural layer: one item for the database, one for the backend, another for the frontend, and perhaps one for automation testing.

Remember that "User stories are something that is shippable and delivers value." The "shippable" means meeting quality assurance standards, so the 'automation test' shouldn't be left out. The "delivers value" means it's valuable to the user.

On the same are, if you have a large four-week item, don't just split it into eight smaller half-week items for the sake of splitting. If we aren't delivering value until four weeks later and it's no different from using the waterfall approach.

The story should also be small enough to be completed within a sprint. Of course, you can go as small as you want, but it won't make sense or isn't valuable to the user at some point.

Avoid "Not" and "no", as there can be many different ways to implement the item.

Avoid using conjunctions such as it suggests the item is doing too much. example:  "..and", "...or", "...but" and "...as well as.."

Who can help to split up items?

Engineers and Product Owners can help split up user stories as it can require technical knowledge to get more ideas on how the user story can be implemented. Extra skill sets and perspective also help with story break-up. Finally, Scrum Master and Team Leaders can also help by guiding how to split user stories properly.

9 Techniques to Split User Stories

Workflow

Split by asking how does the user use the service or product?

Simplicity/Complexity

Split by asking what is the simplest thing that can work, then add variations.

Acceptable Criteria

Split by acceptance criteria.

Happy / Unhappy Path

Split user stories by asking possible scenarios that might happen for a particular action or user input.

Zero/One/Many

Split user stories by asking:

• What happens if the user deals with nothing?
• What happens if the user deals with one?
• What happens if the user deals with many

User Roles / Persona

Split by asking:

• Who is the user, and how would they use it?
• Are they power users or casual users?
• Are they an Admin or Customer?

Business Rules

Split by business rules.

Functional/Non-Functional

Split by making it work, then enhance for non-functional requirements.

Spike

Still don't know how to break up the user story? Try to identify parts you don't understand well enough to start and then create a spike item for it. The spike's outcome can be a better understanding of the architectural design, technical knowledge, or user needs.

Spikes are time-bound investigation tasks to understand something more and result in a decision so we can move forward. Examples can be understanding the risk of a technical approach, better understanding a requirement or increasing the reliability of story estimate.

How do we know we've written good user stories?

How do we check if the splits are good user stories? We use the INVEST Principal.

Independent (of all others)
Negotiable (not a specific contract for features)
Valuable (or vertical)
Estimable (to a good approximation)
Small (to fit within an iteration or sprint)
Testable (in principle, even if there isn't a test for it yet)

Don't stress too much.

Even with understanding the benefits of splitting user stories into user stories, techniques to slice it, and a way to test if see it's broken up well. If you are unable to, don't stress about it.

It can be demanding to split it well and not always worth it. From my experience, under half of the items I've seen meet the INVEST principle. The most challenging part is to balance the  Independent versus Small principle.

So that said, do what makes sense. For example, if the team isn't releasing every sprint, splitting large stories into small ones that don't provide value is OK. Now, if it happens regularly, then perhaps it means the team needs to revisit how to break up user stories. If it still happens, is Scrum suitable for the team? or is Kanban or another delivery framework better?

Bonus method: Breath-Depth Split  (aka T-split)

The breath-depth split method is a fast and straightforward way to split stories. Firstly look at the breadth of features, then for each one, the depth of requirements or business rules. From my experience, this quick method should cover the majority of items, and for the remaining ones, you can deep dive and use the nine specific techniques.