Get certified - Transform your world of work today



Story-splitting patterns revisited

21 May 2014

Phalguna Ramaraju
Lean Agile Consultants

Splitting an epic or a large user story is a challenging task for many of us using Scrum or other Agile methods.

To easily remember the story-splitting patterns, I cooked up an acronym, SPLIT STORIES, thus adding my two cents to various articles that have been described by respective authors.

Splitting user stories is all about reducing complexity by looking into various possible small and independent valuable pieces within them. While writing new stories, as well as when splitting an existing story, keep in mind using the INVEST criteria to write good stories. Did you notice that the "Independent" and "Valuable" attributes are often difficult to reconcile with the "Small" attribute of INVEST criteria? Sometimes we eventually need a trade-off here, and it might lead to creating some technical stories that are not considered "Valuable" to the customer, but they will help avoid technical debt by contributing to the overall integrity of the product.

Always consider applying the XP concept of DTSTTCPW (Do The Simplest Thing That Could Possibly Work).

A strong suggestion on the "Testable" part of the INVEST criteria is that the development team members should work closely with PO, business people, and other stakeholders to collaboratively define the requirements and related acceptance criteria, preferably through specification by example. Developers need to understand the effort needed in creation of automated acceptance tests. This helps with better estimation and also provides ideas for splitting the stories.

In general, it is important to understand the success criteria for each epic/user story by collaborating with the PO and business people. This helps not only to deal with details but also to get hints on how to prioritize, based on the incremental value and risk.

Watch out for compounds and conjunctions in the stories, such as: and, or, if, when, but, then, also, as well as, plus commas and so on.

Let's see the epic: The subscribers should be able to practice mock tests, and when the subscription expires they should be able to renew so they can continue their practice.

This can probably be split into:
  1. As a (registered) subscriber, I should be able to practice mock tests.
  2. As a (returning) subscriber, I should be able to renew my expired subscription so that I can practice mock tests.
Please consider these patterns as indicative:


S = Spike
Build a technical or functional spike (explore a solution through research) when we have a large or overly complex story, or when the story's implementation is poorly understood. Then split that story based on the result of spike.

P = Processes in a work flow
When an epic or large user story involves a work flow (essentially a process or collection of processes, usually described in the context of the application domain), identify the specific activities/process steps that the user undertakes to accomplish the work flow, so that we can implement it through multiple stories, each adding value.

Usually in a work flow, the biggest value comes from implementing the steps that are at the beginning and end. The middle steps add incremental value to the overall flow but usually don't stand alone. So it is possible to build the simple end-to-end case first and then add the middle steps and special cases, if any.

Another approach is to first implement a thin slice throughout the work flow, and later we can enhance the same with more stories.

Epic story: As a shopper, I want to pay online for the items on my cart.

This can probably be split into:
  1. As a shopper, I want to choose my method of payment. (Want to complicate it more? As a shopper, I want to pay through multiple payment modes.)
  2. As a shopper, I want to receive an email notification acknowledging the receipt of my payment.
  3. As a shopper, I want to receive email notification with my order details.

L = Languages and variations in the data
Break the scope and complexity of languages, data variations, and data sources with simplicity. Start with a simple version first, then keep adding new stories.

Example: When we know the data variations, we can implement them -- a page of label elements and related data fields in French, German, Hindi, etc.

Let's look at another story: As a world traveler, I should have option to see local language translation for the elements on the GPS map, so that I can get help from a local guide.

In this case, we can have another story that dynamically translates the host language elements, say English, to a local language of the user's choice.

Large story: As a subscriber, I want to see my mock tests performance dashboard.

This can probably be split into:
  1. As a subscriber, I want to see my performance in mock tests as a line graph, so I can see the progress over previous tests.
  2. As a subscriber, I want to see my performance in mock tests as a bar chart, so I can see the progress over previous tests.
  3. As a subscriber, I want to see my performance line in mock tests compared to the average performance of others on a bar chart.

I = Input methods for data
Break the complexity in the user interface by splitting a story to implement it with the various possible data entry methods, such as simple typing (versus speech recognition), simple text entry of a product code (versus a barcode reader for PLU code reading), uploading an existing image (versus capturing a picture via camera), etc.

So we can simplify with a simple UI to start with, and then build the richer UI later.

T = Temporarily defer system quality, conformance, and other factors
In some cases, the end-to-end tests for conformance or performance might not be currently possible due various reasons. Examples include some performance tests, some documentation, an overall flow that can only be tested at a later time after some other stories are developed. So, various factors/nonfunctional stories can be deferred to a later time (the last responsible moment).

Those factor tests can include usability, scalability, security, interoperability, compatibility, reliability, installability, maintainability, configurability, penetration, and so on.

Remember that undone work (the work that the team[s] doesn't do as part of the story but that still needs to be done before the release) is possible when we talk about "item-specific product-wide" DOD!

S = Simple and complex
When we come across a simple or complex story, ask questions around it for better understanding of the scope. We might get many new details. Look out for the simple core that adds most of the value and learning, and implement that first. Then we can add more.

Example: As an exam controller, I want to search subscribers.

This can probably be split into:
  1. As an exam controller, I want to search subscribers who passed the exam between a range of dates.
  2. . . . by examination name.
  3. . . . by the subscriber's country.
  4. . . . by the range of marks scored.

T = Time-bound work items
Sometimes we come across time-bound commitments that can't wait until our sprint ends. These requests would usually be from external teams or stakeholders.

Depending on the way Agile teams are structured in an organization, sometimes we might come across a need to elevate some specific work item(s) by a certain date for another team, or finish some work items soon due to a legal/regulatory/SLA need. In such dependent cases, we can look out for the smallest independent work item (this can be a component) that, if delivered, would serve the purpose of requested team.

Also sometimes, a show-stopper defect found by another team (one that they can't fix) that needs to be fixed soon; this can be a technical task or a technical story, for example.

While this approach might sound as though it goes against the Scrum recommendation of no changes to sprint goals during a sprint, it is practical when working across the project with many teams with continuous integration and continuous delivery in place (where XP goes beyond to address such situations).

When we have an existing product, we will have some inherent technical debt and other technical enhancements to the product that will not directly add value to the customer but that are of important to the business and product to balance conceptual integrity and perceived integrity. Seek a way to separate such technical items of work as separate stories, and prioritize them with the PO so as to address them in time.

O = Operational boundaries
Operations such as Create Read Update Delete (CRUD).

Example: As an application administrator, I want to manage user accounts.

This can be split into:
  1. As an application administrator, I want to create a new user account.
  2. As an application administrator, I want to reset a user password.
  3. As an application administrator, I want to deactivate a user account.

R = Rules and roles of the business
Try breaking the story into several stories to handle business rule complexity.

Sometimes a large story may be split into smaller (sub)stories based on intended roles/personas due to their normal or extreme characteristics, or preferences, or permissions/profiles.

For example:
Epic: Subscribers should be able to practice their mock tests.

This can probably be split into:
  1. As a subscriber, I should be able to practice mock tests.
  2. As a subscriber, I want to choose the difficulty level of the mock test.
  3. As a subscriber, I want to see the results of my mock test in a text report.
  4. As a subscriber (age 50-plus), I should be able to practice mock tests with default large font size.

I = Inter- and intra-project reusable work items
There will be work items that are usually done for one project and are reusable across projects in a program or portfolio. When splitting stories, look out to identify and separate such reusable work items into new stories, if this makes sense for your organization. To identify such items, we need to collaborate up to the portfolio/program level. This helps eliminate waste across the organization and helps us deliver projects early.

Examples include the log-in mechanism, security features, credit card processing code, some APIs, special frameworks, some wrapper programs, and so on that can be reused across projects, depending the technologies and programming languages; compliance-related items and those things related to other standards.

Within a project, as part of a user story we might come across integral but common work items that are reusable across the product.

Also, reusable components such as audit log generation, error logging, generic data validation methods, security-related reusable code, dynamic language translation methods, APIs, test framework set-up, and so on can be candidates for such items.
E = Effort (major/minor)
Sometimes a large story can be split into several small stories, where most of the effort will likely go toward implementing the first part. Implementing the rest of the parts will take relatively less effort.

Say we have a processing program that processes in certain order. Later, a new story that asks for processing in different order can be implemented with relatively less effort.

For example: As a shopper, I can pay for my purchases with MasterCard, VISA, Diners Club, or American Express.

The above can be split into four stories:
  1. As a shopper, I want to pay for my purchases with a MasterCard.
  2. As a shopper, I want to pay for my purchases with a VISA card.
  3. As a shopper, I want to pay for my purchases with a Diners Club card.
  4. As a shopper, I want to pay for my purchases with an American Express card.
In this case, let's say we first implement a MasterCard payment, which is the first story. Then the credit card processing functions are in place, and accommodating more card types will be relatively trivial. The first story (in this case MasterCard) will naturally be estimated as larger than the other three stories.

S = Scenarios (in use cases)
If we have any existing use-case scenarios for the system, we can write and split stories according to the individual scenarios of those use cases.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4.3 (11 ratings)


Carlos Monroy Nieblas, CSM, 5/22/2014 9:16:55 PM
Thanks for the contribution.

It will be quite challenging to remember the mnemonic...
Sanni Babu Yegi, CSM, 5/23/2014 8:29:52 AM
Very nice article Phalguna... I really love it..There is so much info...

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up