Top 13 Patterns to Split a User Story

Top 13 Patterns to Split a User Story

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, re-write it from a business perspective.

2. Does the user story include a value statement? If not, re-write 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 and the development team needs to 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 less than 2 days?If not, then the user story is too large and the team needs to split the user story.

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

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

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

9. Does the user story require integrating with multiple apis? If so, split the user story by unique interfaces creating a user story for each api.

10. Does the user story require error and exception handling? If so, split 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, split it by unique workflows by creating separate user stories for each workflow.

12. Does the user story include multiple business rules? If so, split it by separating out business rules 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.