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.