User stories that can't be split
Splitting stories
In iterative development, it’s always recommended to split work into small chunks. That way, it’s easier to understand and implement them. What should be done, however, when a User Story can’t be split, no matter how hard you try?
This situation can happen, but you should know that it doesn’t happen very often. Maybe once or twice per year. If you’re struggling with splitting a User Story, you can try using an approach like the SPIDR methods: a set of five techniques with which almost every large User Story can be split by its
- Spikes
- Paths
- Interface
- Data
- Rules
In the rare occasion that these approaches didn’t help you, try using the following approach:
Progress Points
For a User Story that needs several Sprints to be finished, Progress Points can be used to track how far that Story already is. Progress Points can be identified by considering what a developer would show another colleague with the words “Look at this! How awesome is that?”
Example
Complex code that communicates with a remote system
- First Point: Communication with the remote system can be established successfully
- Second Point: Error-handling is working
Progress Points can be seen as milestones for a Story. In the Sprint Planning meeting, the developers estimate how many Progress Points will be reached during the next Sprint. That way, the progress of the Story can be tracked.
Conclusion
Always try to split your work into small chunks. If it can’t be split even after you tried approaches like the ones above, use Progress Points to track the progression of a User Story.
What are your experiences with this subject? Do you have many large user stories that can’t be split? How do you deal with them? Maybe this isn’t a problem for your team?
