User Story Splitting is the art of splitting User Stories or Product Backlog Items (PBI) into smaller parts when an item is too big. My recommendation is that Stories be no larger than 1/5 to 1/10 of the team’s capacity for the entire Sprint. There are many reasons to split including: better flow of work; easier to understand items; easier to estimate; etc. Whenever we split a PBI, we should ensure that the resulting item still has demonstrable value, so splits that look like team member tasks don’t count. Most of the time we only split stories that are candidates for work in the next few Sprints. We don’t split all items in the product backlog months ahead.
- 21 Story Splitting Patterns (slideshare)
- The Humanizing Work Guide to Splitting User Stories and the massive PDF: How to Split a User Story
- Splitting User Stories with Acceptance Criteria
- Splitting User Stories with Generic Words
- Splitting User Stories with Timeline Analysis
- Story Slicing: A Real Life Example
- The True Purpose Of Story Splitting
- Twenty Ways to Split Stories
- Using Vertical Slicing and Estimation to Make Business Decisions at Adobe
- What if I tell you requirements are like bubbles?
- What if the User Story is too Big for the Team?
*Thank you for visiting the World's Largest Opinionated Agile Reference Library. This content is created and the links are curated through the lens of Agile Pain Relief Consulting's view of what is effective in the practice of Scrum and Agile. We don't accept submissions and emails to that effect are marked as spam. Book listings may use affiliate links that could result in a small commission received by us if you purchase, but they do not affect the price at all. From experience, this won't amount to anything more than a cup of coffee in a year.