Learning how to story split is a skill that takes some time and practice to master, so don’t beat yourself up if you still find it to be more of a challenge than you thought.
Once you get it though, you’ll see team metrics increase exponentially. The concept is simple – the more a team can accomplish the better they feel about themselves, the project, and the product they’re producing. Confidence is an indicator of morale. When morale is high, motivation comes naturally. Stories are ready for acceptance at an impressive pace.
If you were to ask most agile teams, they would agree that splitting a story in order to bring it down to its smallest, most valuable self is quite logical – but not always easy. Teams new to agile in particular who have not yet learned the concept or value of smaller stories can find the break down process so daunting, that they avoid the task entirely. Eventually, velocity declines and unfortunately, takes the level of team confidence with it.
By working closely with their development team, an agile analyst such as a Product Owner or Sr. BA can improve on their ability to recognize how or when to split a story.
Notice I said, ‘when’. Occasionally, stories will come along that involve complexities not conducive to any kind of break down – i.e., it would make no sense or gain any value by a split. A team should have the ability to recognize this and then have the necessary conversations in order to proceed with the story.
Understanding how to go about breaking down a story is key to getting it done.
By taking the following five analysis approaches, story splitting becomes less intimidating.
Use Case Analysis
A BA doesn’t have to possess a background as an agile product owner but a product owner should typically have a solid foundation in business analysis. Hence, an agile analyst can be both. Knowing how to convert a user story into a use case is probably one of the single most important skills to have when pulling user stories from an Epic or Feature. We gain clarity on how to split a story by identifying the normal, alternate, and exception paths a user may take to reach their goal.
For example, let’s say you are selling a product in a TV commercial and one your user stories deals with order placement. In your ad, you’ve provided both a phone number, and website URL. Because the customer can take either of these paths to place an order, you will need at least two different user stories based on the workflow necessary to achieve the result – order placement.
Keep in mind, not all paths will always justify a valuable story; the idea here is to use this analysis technique to help identify a reasonable story break. In this example, it’s evident that two stories are necessary to cover two unique process flows a user may take to reach their goal. We wouldn’t go on to create additional stories based on color or quantities of the item ordered or even method of payments. This original story was about placing an order only.
Using the same example from our use case analysis, we can address the user interface involved with the order placement process. If the customer orders by phone, there’s probably no need for another story (unless maybe, if the user is expected to use a prompt tree, etc.)
If the customer chooses to place their order through the website, then what? We’ll need to account for the ways in which our customer will access and use our site. Are the stories the same across all devices, including desktop? Will the functionality stay the same across different browsers? Maybe. This is an analysis exercise where a product owner or analyst would engage with their dev team in order to arrive at the necessary set and content of user stories.
Large stories, especially when dealing with software, tend to include data and probably a lot of it. Data that either provides support or is in need of support may not always be required up front to deliver stories of value over the course of an iteration.
For example: a complicated user story might have a traveler researching flights on an airline site who wants to see all available flights and associated costs within a specific date range.
Based on the requirements for this feature, both logged in existing customers with a billing profile and non-registered users should have the ability to browse a flight range and see all associated costs – including tax.
Right away, we can see there is plenty of data that will need to push, pull, and move back and forth. By completing this type of analysis, stories can be identified that at first will provide only minimum data, such as search results for flights within date ranges. Over the course of the iteration, stories can progress to include increased data capability, such as first providing base ticket costs, then eventually resolving the inclusion of taxes and surcharges based on user locale, etc.
Business Rules/System Analysis
Because business rules can span both Functional and Non-functional requirements. They may involve many IF- THEN statements, and at times, it’s possible to work around one or a few rules in order to break down one or more stories.
For example: Working with an ATM withdrawal story, IF the amount requested by the user is greater than the user’s checking account balance, THEN the user is unable to withdraw. Seems straightforward, right?
However, if we also employ our Use Case Analysis, we’ll find that there’s an assumption for the system to see all of the user’s account balances. So that IF a user attempts to withdraw amount an amount greater than available funds in checking, BUT has available funds to transfer from savings, THEN the system shall offer the user an option of transfer.
We’ve just pulled another story out from the original. One that may be able to wait. More stories abound here. Some will have higher priority than others will. Similar to using the Data Analysis technique, by identifying the higher priority stories, we can probably work around some of the business rules not yet needed for immediate release. By completing these stories in their smallest, yet still valuable forms, we shorten the feedback loop, allowing plenty of time for the team to circle back when necessary in order to implement the postponed business rule. As a result, those higher priority stories played first.
It goes without saying that strong requirements are critical to any project. Another advantage of Business Rule Analysis is that it will alert a team to one or more missed requirements.
When there is just not enough information (usually technical) to devise a clear build strategy, scheduling a SPIKE as soon as possible will help. A SPIKE, when done properly is a fact-finding mission completed by one or several team members. A successful SPIKE yields a great deal of vital information to help answer immediate questions, but also any additional questions, we may have as we move through the rest of our iteration.
Working far enough ahead in the backlog helps tremendously by allowing the team enough time to complete a SPIKE related to the entirety of the feature, an existing subset of stories or even the one story under consideration for a split.
What may have seemed completely overwhelming at first, now feels more comfortable because we’ve attained knowledge – which breeds confidence. Now, maybe that story doesn’t seem so complex after all.
As you hone your story splitting skills, stay focused on delivering continuous value for the customer. Effective stories are key. Ineffective stories cause problems from all perspectives of an agile team:
- Developers need clear, concise, and achievable instructions
- QA depends on unambiguous Acceptance Criteria
- Product Owners cannot and will not accept stories that do not meet the needs of their customer
- Poor performance metrics weight down Scrum Masters
- Customers lose
Would you like to write better user stories and learn how to slice and dice them more easily?
Then join us for a fun, intensive two-part, 12-week course (with 24 PDUs/CDUs) dedicated to Requirements Engineering & Execution
PART ONE will focus on Requirements:
- How to distinguish strong from weak requirements
- How to write better requirements
- How to avoid missed requirements by using advanced analysis techniques for elicitation
- How to organize and recognize attributes and artifacts of functional and non-functional requirements
PART TWO will focus on Execution (User Stories):
- Writing a viable User Story
- How and when to break down a User Story
- Vertical vs Horizontal slicing
- Story Mapping
- Writing effective Acceptance Criteria
- Applying Use Cases to help with it all
Sign up for the Requirements Engineering & Execution course by May 5th and get a Bonus Class valued at $497 and receive an additional 4 PDU/CDUs!
The bonus class is a hands-on, collaborative User Story Workshop where you’ll get an opportunity to apply everything you’ve learned in the course – from identifying, extracting and creating requirement types using a scope document, to writing effective User Stories with the necessary Acceptance Criteria that will meet the Definition of Done.