1. It may be possible to split a story so some of the work on the original story doesn’t have to be done. Ding, ding! Huge productivity improvement! Lean principle alert ? eliminate waste! This reason is good in some many ways you can’t even begin to count them. Any time work can be eliminated without affecting the overall value of the product it is a good thing. Oh, and if after splitting the story we see we don’t need to do any of it, well that’s just AWESOME! 2. Stories can be split to expose more personas. Sometimes teams see a story as large because there are many different types of personas which must be taken into account. The story becomes easier to deal with, and we gain clarity, when we see the personas split out separately. 3. Stories can be split to help expose risk. We may have user stories which have elements of risk in them. If we can split the user story to isolate the risk we may be able to avoid the risk altogether. 4. It may be possible to split a story to ease a transition. When we upgrade existing functionality we often give users a bit of a shock. Sometimes we can split stories to give a smaller shock up front and postpone other work until a later release. 5. A split story may be able to have more people work on it at once (swarming). If a story is large and requires primarily one type of expertise we tend to let a single person do all of that type of work. However, a split story may enable others to chip in because some portions of the large chunk of work can be handled by people with less expertise. 6. Splitting a story may give us more visibility into its true size. I have seen many teams split a size 13 story into 3 pieces and end up with 3 stories each of size 8! In fact it isn’t even that uncommon. When we have an upper bound on our story size we tend to use that size for anything “big.” This leads to large under-estimating for truly large stories. 7. A story split may allow us to use a different quality standard for the new stories. A simple example in a reporting system may be two of the same type of report, but one is run hourly and one is run yearly. The hourly report may need higher quality than the one run yearly. This may be a bad example, but I think it gets the concept across. 8. When a story is split correctly it can help with testing. Some portions of the story may require full end-to-end testing, while other portions may be able to be tested in a mock environment. 9. A split story may isolate performance factors. One portion of the original story may affect performance while another does not. This may affect prioritization as well as performance testing time. 10. Of course, splitting stories may just make the original story be in more digestible chunks so they fit better into iterations.