• Post author:
  • Reading time:4 mins read
You are currently viewing Top 13 Patterns to Split a User Story

Many teams struggle with breaking up or splitting a user story into smaller ones. Here are the top 13 patterns to split a user story that you can use when clarifying user stories with the team during product backlog refinement. Start by asking:

1. By Business or User Perspective

Can a business stakeholder understand the user story? If not, consider re-writing it from a business perspective.

2. By Value

Does the user story include a value statement? If not, consider re-writing it so that its value is clearly stated.

3. By Clarity

Does the development team understand the user story? If not, clarify it further based on the development team’s questions and add acceptance criteria (see #6 below).

4. By Size

Can the team estimate the user story? If not, then the user story is too complex. Consider having the team run a spike to get a better handle on the user story and their approach to developing it.

5. By Time

Can the team complete the user story in less than half the duration of the Sprint? If so, then can the team complete the user story in half that time? If not, then the user story is too large, and consider splitting it.

6. By Acceptance Criteria

Can each acceptance criteria be a user story on its own? If so, consider splitting the user story by acceptance criteria.

7. By Data

Does the user story combine different kinds of data (for example local vs. national vs. international)? If so, consider splitting the user story by data boundaries by creating a user story for each data category.

8. By Operation

Does the user story combine different operations (for example create, retrieve, update, delete)? If so, consider splitting it by operational boundaries by creating a user story for each operation.

9. By API

Does the user story require integration with multiple APIs? If so, consider splitting the user story by unique interfaces by creating a user story for each API.

10. By Exception

Does the user story require error and exception handling? If so, consider splitting it by creating a user story for the happy path and a user story for the exceptions.

11. By Workflow

Does the user story include multiple ways of accomplishing the same thing? If so, consider splitting it by unique workflows by creating separate user stories for each workflow.

12. By Business Rule

Does the user story include multiple business rules? If so, consider splitting it by separating out business rules by creating a user story for each logical grouping of business rules.

13. By Value

Is the user story still written from a business perspective? If not, then you’ve likely broken it down into tasks instead of vertical business slices representing value. Remember #2.

Learn more about splitting patterns and how to write good user stories in the Writing Effective User Stories Workshop.