User story splitting breaks down a large user story into smaller multiple user stories that can be delivered earlier given their reduced complexity and size. Smaller sized user stories are easier to accommodate into the overall sprint plan.
This technique is best employed on user stories that have a large effort estimate.
The approach to splitting the user story should ensure value can be delivered to the user in each smaller story, so still adheres to the INVEST principle
👥Who
A collaborative activity with the product manager and developers involved with the original user story
🛠 Running the technique
Find the best pattern to split the story. The functionality associated to the story typically leans towards one option more than others.
Tried and tested patterns are : Workflow Steps, Operations to perform, Business rules that need to be applied, Variations in data, User interface options, simple functionality/complex functionality, defer performance
After applying a split test each candidate against the INVEST principle. If one of the smaller stories fail, find another user story that it can be merged with.
The number of split stories created will depend on the scope and complexity of the original user story. Use a guideline that each split user story should take no more than 15% of your sprint capacity to achieve
Reprioritise the split user stories - you may find that some of the smaller user stories are not as valuable as others.
Please refer to the additional material source for the full flowchart of splitting patterns
No Comments