Splitting User Stories in Scrum
Writing User Stories is an art. It needs to be clear to the team what is required and at the same time let the team decide the implantation details by innovating.
The key to writing good User Stories are as follows
- The User Stories should be small, typically, No more than 40 man hours of effort
- Keeping Stories small allows the team to build incrementally and get validations done along the way.
- It requires considerable effort from product owner to split a story into more granular user stories
- It requires considerable effort from product owner to split a story into more granular user stories.
- Let us study a few ways in which user stories can be split into smaller stories
- Splitting Stories Based on “Big Picture”
- Research vs Action: Define a User Story based on research. Before moving to details, assign a certain amount of time to conduct research.
- Spike vs Implementation : Even if approach is clear, sometimes, the feasibility needs to be established and team needs to develop familiarity with the approach to reliably estimate and carry out the work. In such cases, the familiarity is enhanced by working on a spike story which involves writing some sample to prove a concept and get better understanding.
- Main Flow vs Alternate Flow : Implement the main flow first and then the alternate flows. This has been followed in construction industry from a long long time. First build the skeleton (the pillars, the slabs) and then put in the other things like Walls, Rooms, plaster, the ceiling etc.
- Make vs Buy : Spend some time to see if what you want is already built by someone else. See if you can buy things instead of building them.
- Splitting User Stories Based on User Experience
- Batch vs Online : First implement logic to implement in batch mode and then make it online.
- Single User vs Multi-User : First only cater to single user system and later on add the complications of handling multiple users.
- API Only vs User Interface : First expose the programmatic interface or API and then add User Interface later to make it user friendly.
- Generic User Interface vs Custom User Interface : First use available components to build something quickly, then add the logic to add or customize the User Interface as per Project requirements.
- Static vs Dynamic : Initially use static or cashed information and then worry about dynamic or runtime changes.
- Ignore Errors vs Handle Errors : The basic implementation can choose to ignore some errors and add the sophisticated error handling as part of later user stories.
- Transient vs Persistent : Initially, let the data be transient and then think about data to be persistent.
- Low Fidelity vs High Fidelity : Initially start with a low fidelity or low quality deliverable and then add quality as you go on.
- Small scale vs Large Scale : Start with a small pilot implementation and then expand to real life or larger implementation.
Unreliable vs Reliable : Perfect uptime is expensive. Do not try to build it in one go. Initially some amount of unreliability is ok. Then try to make it perfect later.