User story splitting

Story splitting – refinement to an optimal granularity

An apparently small story may turn out to be much bigger than expected. Only by refinement or story splitting can you discover this. Story splitting can be done early or just before the preceding sprint. We recommend doing it as early as possible to avoid late surprises.

We consider “story splitting” and “story refinement” as very similar activities. It’s about optimising the granularity of the written user story.

What are user stories

For those teams that are able to colocate, the user story can be just a reminder of a conversation. In most circumstances, we rely on the user story as the written functional requirement. To be effective in providing clear communication user stories must be carefully written to minimise misunderstandings. But first we must understand how user stories fit within the wider context (hierarchy) of communication of what needs to be done to provide the users with value:

The Context of User Stories

Software Requirements Hierarchy

  • Business Outcomes

    All requirements start with at least one quantified business outcome, which can be achieved by capabilities (or epics).

  • Capabilities

    Capabilities are generic groups of functionality needed to achieve the business objectives.

  • User Stories

    User stories are functional user requirements that specify the persona and the groups of data that they need to handle in order to achieve a specific task or specific need.

  • Technical Tasks

    These are the specific activities that team members (analysts, architects, developers and testers) need to perform in order to deliver a user story.

A complete user story

Having established this context, we can now see where user stories fit.  The context within the hierarchy helps to understand what is needed in a user story, for it to be well formed and of good quality.  A complete user story must:

  1. specify a user or persona must be specified.
  2. describe the high level functionality to be performed as part of a single discrete functional action by the user.
  3. include all the functional steps needed to meet the user requirement.

When to do Story Splitting

Ideally as early as possible in the software lifecycle.  It is not as onerous as many would contend and is rarely a wasteful activity.  Check out our blog article on recommended user story quality attributes

Techniques for Story Splitting

Think first Who is the user and what data types are they needing to handle to achieve a specific requirement that leaves the system in a stable state at the end.

User – Oriented

Is this story describing the functionality for a persona or groups of personas?

Measurable (clear functional steps)

In order to be measurable or sizeable, we need to know the functionality in terms of data groups being handled. e.g.

as registered user I can update my profile.

For measurable we recommend the COSMIC functional sizing standard, which requires that objects of interest are identified.

Complete

Have we mentioned all the data groups needed for this story? If we have to lookup some data from elsewhere, that needs to be included too. Many user stories do require various data lookups before an object type is created or updated.

Business Rules

Business rules are usually constraints based on context or referenced data. Be sure to include all referenced data types in your functional user story. Occasionally, business rules force a story to be split into two similar stories. Sometimes, context can be presented by combining the user name with a particular status, e.g. loggedin_user_with_cart_items

Concise

Sometimes we over-specify a user story with all the acceptance criteria before we have the basics right. Avoid doing this too early.