Why should I split my stories ?
– Rachana Dalmia
This article is about WHY you should split your user stories while working in agile projects and also how to split the user stories.
The obvious reason to split a user story is when a story is too large to fit in a sprint. But this is not the only time you should think about splitting your stories. Breaking a large story based on all its variations and complexities will allow your Product Owner to prioritize the most valuable variation either based on usage or other business criteria. Some of the variations may never bubble up in priority over other features.
Example: I worked on a portal where documents could be shared with different groups of people. One of the requirements was notifications to the users when a document was shared with them.
• I broke the user story for different notification channels:
• Text message
• Notification center on the portal that shows all the messages sent to the user.
-PO was able to prioritize the notification channels separately
-Allowed for faster time to market
-Based on the usage and feedback, we were able to eliminate the notification center completely, saving budget for more important enhancements
-Smaller stories allow the team to provide more accurate estimates
-Ensure that there is an Epic that ties all your split user stories together. This will allow your development team to think about the architecture/design.
Teams that are new to splitting stories tend to split the workflow Epic by each workflow step and implement it from left to right until the flow is complete. Splitting this way is dangerous because
this does not give the user time to provide feedback on the workflow until it is too late and the entire workflow is implemented. This defers learning and creates additional project risk or in the least does not allow you to retire the risks.
A better way to split a workflow is to do a thin slice through the workflow focusing on one variation or to focus on the stories that actually deliver value rather than every story in the workflow.
Example: I had a client who wanted a portal that allowed patients to schedule healthcare appointments with the doctors. They had inventory of thousands of providers and their availability.
1. Patient would login to the system
2. Lookup the doctors by speciality, insurance, proximity to them and other criteria
3. Once they found the doctor, they had to look up their schedule
4. If they found a time slot that would work for them, select the appointment, provide all the required information
5. Book the appointment
6. Show confirmation for the appointment
In this workflow, the value is only derived once the appointment is booked. So, we discussed the fastest way to get the patient to the appointment.
– Once we started breaking this story
– We found that 80% of the appointments were patients with their PCP (Primary Care Physician)
– The other 20% were either new patients looking for a PCP or other specialists
– The complexity in this workflow was looking up the doctors based on the various criteria.
– So we implemented the thin slice of the workflow where the logged in user’s PCP availability shows right away and they can book an appointment.
– We were able to release this feature and add the complexity later on.
– Earned quick ROI.
– The client can go to production with just this variation implemented and the other flows can still be a manual workflow saving time on at least one flow.
– The team learns from implementing this one small variation without adding complexity to the system.
– The team can now estimate the other variation(s) more accurately.
We split user stories to get to value/feedback faster and to only build what is valuable.