This blog will not focus on the "how" of splitting stories but rather on the "why". When people understand the "why" behind what they're asked to do, they're more likely to continue doing it.
Easier to estimate:
It's really frustrating when we're forced to estimate something and we have no clue. Sometimes we're backed into a corner and our only way out is to blurt something out which somebody holds us to later on. Breaking down the user story can help alleviate this pain. If you're still struggling to estimate even after having split, you may need to split even further.
Better position to succeed:
We all want to succeed. We all want to end each sprint having completed what we committed to during sprint planning. If our stories are sized appropriately, we can do that. Watch out for teams that take 2 sprints to complete a user story and still award themselves with velocity points after the first sprint. First of all, they shouldn't receive any points until the story is completed and secondly this may indicate they've gotten lazy when it comes to splitting stories.
Easier to accomodate change:
While Agile does accommodate for changing requirements, we need to take on sizeable chunks at a time. It's not uncommon for a Product Owner to ask the team to replace one user story with another. At first glance they may see comparable so the team agrees to do a swap. And then at some point during the Sprint the team realizes that this single user story is actually quite a few stories and maybe even an epic. Had they split the story when it was first brought to their attention they could have avoided the situation altogether.
Splitting stories correctly is a practice that takes time. Beware of these 5 common pitfalls.