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.
- 10 Powerful Strategies To Break Down Product Backlog Items in Scrum (with cheatsheet)
- 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?
Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.
*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.« Back to Glossary Index