User Story Splitting
Breaking down features into smaller stories that the development team can build quickly is essential to keeping an agile release cadence. But what’s the best way to do that? First, we need to understand the best practices for story sizes, and then we need story-splitting techniques to break them down.
Importance of User Story Splitting:
Spending too much time trying to split stories in a meaningful way at the cost of building something.
Story Types:
Complex Stories:
• Fundamentally Large
• Cannot be split
• Rare
Compound Stories:
• Comprises multiple smaller stories
• Can be split
Before get into deep of story splitting. What makes a story into high-quality story ?
A high quality story covered a well defined set of quality criteria/principle that is INVEST.
Independent Can be released without dependencies
Negotiable Ready for discussion and can be adapted based on team input
Valuable Deliver value to the end user
Estimable Dev team can estimate its relative complexity
Small As small as possible while still providing real user value
Testable Stories that are not subjective and provide clear details of how the user story will be tested.
As we continue to split our stories into smaller and smaller stories, we need to ensure that each one still meets the above criteria.
Story-splitting techniques:
There are many techniques for splitting stories. Here are some of the more useful ones.
Split by capabilities offered:
This is the most obvious way to split a large feature. Look at the different capabilities being offered and split each one into its own story. For example, the capabilities “sort and search” may each be its own story. Splitting further, each way of sorting or searching may be its own story.
Split by user roles:
Administrators interact with a system differently from normal users. Teachers interact with instructional software differently from students. By defining the different roles in our system, we can split features and stories to address the unique needs of each role.
Split by user personas:
Even in the same role, different people interact with software in different ways. A power user wants lots of keyboard shortcuts. A casual user may want a lot of intuitive, hold-your-hand forms of help. Handicapped users may need very different ways of interacting with the system, even though they are doing the same tasks as other users.
Split by target devices:
We can’t assume that users are interacting with our system using a standard computer. Various smartphones and IoT devices need to be considered in our stories. Splitting stories by device provides a more natural experience for your users.
Hyper-fine story splitting:
Once we use these techniques, and others, to identify high-quality stories and split them as much as possible, you may find yourself with stories that are still too big. In this situation, I find it helpful for the team to use a “zero/one/many” rule to spur the creative process and continue breaking down stories into vertical slices.
With the zero/one/many approach, we may ask these three questions:
What happens if we are dealing with nothing?
What happens if we are dealing with one thing?
What happens if we are dealing with many things?
A zero/one/many example:
The zero/one/many approach enables hyper-fine story splitting, as illustrated in the following Case Study example:
Case Study using Hyper Fine Story Splitting Technique
We are building an online digital library system
► User Roles : Borrowers, Librarians, Administrators
► Highest Business Value : Borrowers
► Personas : Children, Teenager, Adults, Special Ability members
❖ Target Personas : Teenager
► Feature : Able to borrow many different kinds of e-books
► First story : As a teen-ager , I want to borrow digital books so that I can enjoy book that would otherwise be unavailable to me
► Acceptance Criteria :
❖ Given the digital library is online
❖ When I browse for a book
❖ And I choose to subscribe the book
❖ Then the book opens to read
► How to Apply it:
Books : How should the system behave when there are no books in the library, when there is one book, and when there are many books?
► Borrowers:
► What happens when there are no borrowers , one borrowers and many borrowers
► Total Borrowers and Con-current Borrowers
User Story Approach:
► Empty library
► One borrower total
► No concurrent borrower
► Borrower is online
Revised First Story:
As a teen-ager, I want to know that the library is empty , so that I don’t waste my time trying to borrow books that are not available.
Acceptance Criteria:
Given
The digital library is online
And it has no content
And I am the only registered borrower
When
I view the library offerings
Then
I am allowed access
A message is displayed informing me that there are no offerings
► Next steps: Either increase the number of books or number of users
► Second Story: A single user that views a library with one book available to borrow
► As a teenager, I want to be able to subscribe to a book in the digital library so that I can enjoy it
Acceptance Criteria :
Given
The digital library is online
And it has one book to offer
And I am the only registered borrower
When
I view the single book that the library offers
And I choose to open that book
Then
The book opens
► Third Story : With many books
As a teen-ager, I want to borrow from a collection of digital books so that I can enjoy them that would otherwise be unavailable to me
Acceptance Criteria :
► Given that the digital library is online
► And it has many books to offer
► And I am the only registered borrower
► When I view the alphabetized list of book that the library offers
► And I choose to read one of the books
► Then the selected book opens
