Here are the top 13 patterns to split a user story. When clarifying user stories with the team during product backlog refinement, run through the following questions:
1. Can a business person understand the user story? If not, consider re-writing it from a business perspective.
2. Does the user story include a value statement? If not, consider re-writing it so that its value is clearly stated.
3. Does the development team understand the user story? If not, clarify it further based on the development team’s questions and add acceptance criteria.
4. 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. 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. Can each acceptance criteria be a user story on its own? If so, consider splitting the user story by acceptance criteria.
7. Does the user story combine different kinds of data (example local vs. national vs. international)? If so, consider splitting the user story by data boundaries by creating a user story for each category of data.
8. Does the user story combine different operations (example create, retrieve, update, delete)? If so, consider splitting it by operational boundaries by creating a user story for each operation.
9. Does the user story require integrating with multiple apis? If so, consider splitting the user story by unique interfaces by creating a user story for each api.
10. 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. 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. 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. 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 that represent value. Remember #1.
