In this project, you’re the product owner and analyst, which means you’re the person in the lead of this grooming. Hence, you’re owning the requirements and also translating them to user stories for the team to deliver. Seven sprints have passed, and you only have three sprints left.
The meeting has been going on for two hours now and everybody has the feeling there still is much to discuss. That so important user story that everybody hoped to finally agree upon is still under heavy discussion. “As a student, I would like to see related courses so that I can easily find related content”.
Sophia, a member of your development team, just asked a very intriguing question on what should happen when a related course is not yet published. It’s an exception flow that remained undiscovered up until this meeting. Unfortunately, it’s the fifth exception flow that was found and everybody exhaled a big sigh when Sophia revealed the flow.
Normally the team really loves to solve complex problems and deliver high-quality functionality. It’s not their motivation that is lacking. The reason for the big sighs is that this particular user story has been dragging on for 3 product backlog grooming sessions. This compromises the chances of success of The Master Channel since the users have been requesting this feature quite often. The team also knows that this fifth exception flow will most definitely prolong the needed development time and thus also the associated estimates. With the current four exception flows the agreed-upon estimate is one and a half sprint capacity of one team member.
Well … does any of this sound familiar to you? Are you often confronted with big, untamable user stories? User story splitting is a technique that allows you to remedy these problems. User story splitting can be done with a set of techniques that we grouped under the acronym ONWARDS:
Each of these techniques will help you split stories that are too big or too complex so that your team can work with them.
In this specific case, it could be an idea to split this story based on the rules technique. “As a student, I would like to see related courses in a published state …” and “As a reviewer, I would like to see related courses in an unpublished state…” might be two resulting user stories.
User story splitting may not allow you to suddenly clarify the needed implementation details of the 5th exception. Nevertheless, it will give you the possibility to:
Fasten the development cycle of your user stories;
Expedite the testing and feedback of your user stories;
Lower the estimation complexity of your sprint planning;
Lower the unexpected problems encountered during development;
Cut waste from your user stories;
Prioritize your product backlog on a smaller level;
How do you split based on the “Operations” technique? What about “Workflow”? Should I split each and every user story? Are there risks when splitting user stories?”
We worked hard on training to answer all the above questions and many more. The training is supported by a ton of examples and guidelines and takes you only 1 hour to complete. One hour to improve your user stories. Interested? Be sure to check out the User Story Splitting course.