Splitting User Stories

November 15, 2017

User Stories are short and simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. It´s called User Story because you put the user into focus. Therefore a User Story should lead to a product increment that can be seen valuable from the user- or business perspective.

The advantage of splitting

A User Story can cover vast amounts of functionality with a single sentence, which requires a team many weeks or even months of work to get it done (often called epic). Splitting such stories into pieces which are valuable for users and still deliverable within a Sprint is challenging for many teams. However, there are good reasons why you should do it:

JIRA is time-consuming for splitting

Trying to break down a User Story within JIRA is very time-consuming and sometimes counter-intuitive. Not to mention that interaction and conversations among people are to be avoided when following this approach, which is the opposite of what you should thrive for. Use a whiteboard or a wall and sticky notes to do the split work, be prepared to change quickly, sketch, refactor and enhance. Only after you have understood what the story is about and how to split in a good way, bring the parts into JIRA.

Layers

For engineers who are new to the splitting approach, breaking down stories and still delivering end-to-end functionality within a Sprint is among the most challenging things. That´s because engineers are mostly concerned about finding a way for how to solve the given problem. Their thinking tools have to do with architectural layers, technical components, frameworks and programming languages. Naturally, engineers start splitting by layers, like UI, Business Logic, DB Access, DB, Operating System. Following this approach, they end up with stories for the different architectural layers which will be implemented separately and eventually have to be integrated, which will allow only very late feedback. None of these architecture-layer stories alone will bring value for the user, and in most cases, it´s impossible to come up with a solution during a single Sprint.

Also, organizational structures are often formed by their corresponding architecture layers, for example, UI/UX people form an organizational unit, Java developers form a unit, technical writers form a unit, QA engineers form a unit and so on. These units sometimes are called teams. In many cases, none of these “teams” alone can deliver a valuable feature to the user. Which means, costs in terms of understanding, splitting, designing, building, testing and putting into operation are pretty high because the different “teams” need to be coordinated and are interdependent up to the level that they are blocking each other because everyone is waiting for someone else to get work done.

Therefore, when talking about splitting User Stories, it´s meant to cut across all layers to come up with end-to-end solutions in each Sprint. The organizational structures have to follow to achieve a delivery-oriented organization. Which leads to small, cross-functional teams, having every skill on-board that is needed to split, design, build, describe, test and deliver an end-to-end feature. This will speed up the feedback loop drastically and thus allows to speed up learning accordingly. The organizational change, of course, is difficult and requires experience and insight. The goal is to have teams being able to operate quick, with minimal interdependencies and end-to-end.

Patterns

Try the following patterns to split your User Stories:

Concerns

Of course, there are teams considering the splitting process to be wasteful and instead finding the implementation of an unsplit functionality to its completeness to be more straightforward and efficient. Recalling one of the advantages from the beginning: Smaller pieces allow faster feedback. Correction at an early point is more direct, much cheaper and will improve your results.

Everything in agile software development is about feedback and results. This is because learning is an outcome of feedback and learning on all levels (individual and team) is considered to be the essential ingredient of good software development. Therefore you should give splitting a try!