Splitting Userstories

You can find the article als PDF-download in the Scrum-section.

When and why should a userstory be splitted?

Common scrum-sense recommends 6-10 stories per iteration or 4 – 6 stories a week. Both combine to an average of 10 stories per 2-week-iteration. Once a story doesn‘t fit in this scope because it has to many storypoints, it should be split.

What are horizontal and vertical splitting?

Generally speaking, there are two approaches for splitting userstories. Horizontal splitting involves breaking up userstories by the kind of work that needs to be done or the application layers that are involved, e.g. the UI, database, front-end, back-end and testing are possible split levels.

Vertical splitting on the other hand happens so that the smaller items still generate some business value. The functionality will not be split across technical layers or tasks, but across functional layers.

Why avoid horizontal splitting in Scrum?

Consider  – of course – a webshop application, in detail it’s order process. Splitting this up horizontally, the team would end up working on the UI, database, front- and back-end. Although these stories would be smaller, they would not deliver any businessvalue separately. Neither UI nor database can go live by themselfs. Same goes for testing. So, only in combination, they deliver value and so does the sprint.

Horizontal splitting increases bottlenecks. How so? Having tasks separated by functionality usualy promotes ‘silo thinking’. Simply put, the developer will do the coding, the tester the testing and so on. People start – or continue – to specialize in their respective fields. In the end, teammembers will not be able to help each other out. Absence of every single member will interrupt the sprint and cause a chain of delays. Rest assured: This will happen.

Furthermore, horizontal splits can not be prioritized. As none of the slices delivers any businessvalue in itself, there are no criteria for the PO to prioritize.

And finally, horizontal slices have a strong tendency of beeing technical stories, which make communication between the PO and the team harder.

So, the vertical split should allways be choosen over the horizontal, if possible in any way.

What are possible vertical splitstrategies?

1: Split by workflow steps

If userstories involve a workflow of some kind, the item can usually be broken up into individual steps.

2: Split by business rules

Many userstories involve a number of explicit or implicit business rules, which can be used to formulate smaller stories.

3: Split by happy / unhappy flow

Functionality often involves a happy flow and one or more unhappy flows. The happy flow describes how functionality behaves when everything goes well. If there a deviations, exceptions or other problems, unhappy flows are invoked.

4: Split by input options / platform

Many web applications have to support various input options and/or platforms, like desktops, tablets, mobile phones or touchscreens. It may be beneficial to break up large items by their input options.

5: Split by datatypes or parameters

Some userstories can be split based on the datatypes they return or the parameters they are supposed to handle.

6: Split by operations

Userstories often involve a number of default operations (CRUDs). CRUD operations are very prevalent when functionality involves the management of entities, such as products, users or orders.

7: Split by test scenarios / test case

This strategy is useful when it is hard to break down large userstories based on functionality alone. In that case, it helps to ask how a piece of functionality is going to be tested. Which scenarios have to be checked in order to know if the functionality works?

8: Split by roles

User stories often involve a number of roles (or groups) that performs parts of that functionality.

9: Major Effort

User stories often have one integral part that is surrounded by variations or add on functionality. The part that causes the major effort can usually be done separately, followed by several even smaller stories.

10: Simple/Complex

Try to identify the simple variation for the story at hand. Add more complex behaviour in subsequent stories.

11: Defer Performance

If the story contains optimization features, do the simple variant first and add improvements in later stories.

12: Conjunctions

Look for connector words and, or, if, when, but, then, as-well-as, & comma’s.

13: Generic Words

Look for generic words that could be replaced with more specific terms (nouns, verbs, adjectives, adverbs can all be generic.)

14: Timeline Analysis

Pretend the userstory is done. What happens when the functionality is used? This sequence of events can lead to a series of smaller stories.

15: Split items based on external dependencies. 

Sometimes functionality is depending on external factors e.g. connecting to Twitter. This may be difficult, but may not have the highest priority. Or the dependencies can be mocked for the time being;

16: Split items based on usability requirements.

This includes functionality for paging through a list of records, making a website readable for blind people or people with colorblindness or implementing breadcrumbs;

17: Split items based on SEO requirements,

Such as setting up dedicated landing pages for specific keywords, setting up goals for Google Analytics or setting up XML sitemaps;

18: Split items based on browser compatibility.

Getting a website to work in Internet Explorer 6 is time-consuming, but is sometimes a requirement. It may be beneficial to at least consider if support for older browsers can be postponed in favor of newer browsers.

What happens, if these splits are not sufficient and technical userstories emerge?

User ories ought to describe user requirements. Technical details therefore should allways be part of a surrounding story and be implemented in that context. But there will allways be technical aspects, that cannot be directly meassured in business value, such as updating a database system resulting in less maintenance work. Technical tasks, that are to complex to be handled in one story are another common case.

For a high quality product to be created, these tasks are absolutely neccessary and therefore have to be included in the backlog. Which, in turn, is administrated by the product owner. So, the real challenge is to to write the technical userstories in a way, that the PO can understand and thus prioritize them.

To create a userstory from a technical task, two simple questions have to be answered:

1: Why should the task be done?

2: Wo benefits from the result

The answer to the first question ends up as second part of the user story: so that I can… If the simple answer isn’t sufficient, try to dig a little deeper. The answer to the second question is the user storie’s first part: As a developer… In this form, meaning and importance of a user story can be made clear to the PO. If this seems to be impossible, it might be considered that the story acutally might have no real value.

If none of these works?

If none of the beforementioned splits can be applied and no technical task can be extracted into a separate user story, there might actually be no way to divide it. But this should allmost never happen and therefore, the assumption, that the appropriate splitting just has not been identified should allways be made and the story revisited.

Sources & contact





Contact me at marcus.toepper@aoe.com