Product Backlog and User Stories:
Product Backlog is an essential artefact of Scrum Framework. It comprises of a list of items (referred as PBI) that are planned to be implemented in the future. PBIs are generally in the form User Stories.
A user story is the concise representation of a functional or technical requirement of a system. Writing appropriate user stories forms a strong base for achieving the sprint goals successfully and progressing towards the product vision eventually.
"If you want to know more about a 'user story' you may also watch“
The attributes of a well formed user story goes by the acronym INVEST, which was coined by Bill Wake in his book "Extreme Programming":
Independent - Each story should be atomic and not dependent on any other stories
Negotiable - Should have scope to allow negotiation between the scrum team and business team on the grounds of technical , functional and budget constraints and modify itself accordingly
Valuable - Must deliver some value to the stakeholders. If it is a functional user story, then there should be provide some business value , whereas technical user story should focus on architectural and non functional improvements.
Estimable - Team should be able to arrive at a fair estimation for implementing the user story in terms of story points.
Small - Should be small enough to plan and implement within a sprint
Testable - Should have a clear acceptance criteria , which gives the team all the necessary information to test every possible flow.
Product Backlog Refinement
Product owners have to maintain a healthy backlog by frequently grooming the user stories in it. In the grooming sessions (Product Backlog Refinement), PO discusses with the team and work on improvising the poorly written user stories, breaking down the large user stories into manageable size, adding more clarity to the acceptance criteria , prioritizing the user stories and estimating them.
As a Scrum Master, we should guide the team and PO in this backlog refinement activity by aiding them with the best practices in writing user stories of right size and prioritization.
User Story Splitting
Splitting user stories is a significant task in product backlog grooming. A user story should be neither too small nor too big. It has to be sized appropriately , in such a way that , the implementation of it could be decomposed into one or more tasks. All the tasks planned must be completed within a sprint.
Generally , user stories of size more than 8 or 13 story points are split further. However this number may vary from one scrum team to another based on their capacity and velocity.
Benefits of splitting a story:
Smaller is always better. User stories of relatively less story points are
* Easy to understand and groom
* Leads to accurate estimation
* Results on quicker implementation
* Aids thorough testing
Size of an user story is said to be optimal if it could be implemented within 0.5 day (half a day) to 10 days.
Methods of splitting :
A user story can be split:
Horizontally - through architectural tiers as one layer at a time
Vertically - as functional pieces across all the layers at a time. The horizontal layers split accordingly can be further divided as tasks.
A common metaphor used to differentiate both these methods is cutting a cake layer by layer ( horizontal) and portion by portion of all the layers (vertical). Only by tasting a portion of all the layers, one would be able to feel the essence of the entire cake.
Same is the case with story splitting. Vertical (Functional) splitting is more valuable than the horizontal one.
Advantages of vertical splitting:
- Dependencies and risks could be identified at an earlier stage
- Nice to have features can be segregated and deferred for later sprints
- Considerable progress can been seen on functional part every day, whereas in horizontal slicing no benefits are seen until all related stories are complete
- Leads to quicker testing and faster feedback loop - in horizontal , need to wait until all the dependent stories are done
- Helps to prioritize based on incremental value
Techniques for splitting stories vertically:
User stories can be split vertically based on the following patterns:
If an user story has more generic terms, then there is a possibility to split it vertically.
For eg : As a library member, I want to search the availability of various kinds of books for children and share it with my network.
Here, "various kinds" , "share it" are more generic terms. They provide a way to split the story incrementally as below :
* Develop a UI that displays all the book categories when a registered library member login
* Provide a search functionality to the member, where in results are also categorized such as "fiction for kids under 10", "fiction for kids 11-15" and so on
* Enable to users to share the result via email, whatsapp etc
If the user story is represented using a compound sentence, then it is obvious that it can be split vertically. In such cases, look out for conjunctions in the user story like "and, or, as well as, when, if" and split it based on these connecting words or conjunctions like : and, or, if, when, but, as well as.
Read out the acceptance criteria; if it is too complex and some parts of it can be pulled out and developed as an independent user story, follow the same.
Eg: As a senior associate of the organization, I want to register for the in house training programs so that I can attend the trainings and upskill myself.
Acceptance criteria : All the senior associates must be informed about the training programs through mail. Senior associates should be able to submit their details through a form for registration. Mail confirmation must be sent on successful registration. In the above scenario, each of the criteria can be designated as a separate user story.
Identify the workflows that connect different roles for a specific function, and if they can be completed independently split them as a separate user story.
Eg: For an assignment approval system in a school, the following can be the possible user stories
As a student, I should be able to submit my assignments to the teacher for grading
As a teacher , I should be able to view the assignments submitted by the students
As a teacher, I should have the UI to request for more clarifications
Apart from the above, below are the other patterns based on which user stories can be split vertically:
- Operations - Create, Read, Update, Delete operations required for a functionality
- Business Rules deviations
- Variations in Data given as input to the system
- Variations in User Interface
- Spikes - If there are many unknowns in a user story and it requires research for uncovering the grey areas, then create spikes to get the insights of the user story. Based on the spike's outcome, we can proceed with the implementation of actual user story.
Best practices for story splitting:
* Do not split the stories too early - split just in time, when it's priority for implementation is high.
* Do not compromise quality / non functional requirements - NFRs must be taken into consideration while splitting.
If having a choice between a couple of user story splitting strategies, prefer the one that will result in similarly sized sub-stories.— Wojciech Zawistowski (@velesin) May 29, 2015
* Ensure that there is no feature debt - splitting should not leave out any functionality without implementation.
* Story splitting is not a task to be owned by the PO alone - Along with the Scrum Master, other team members also give their view on best possible ways to split the stories as they are the actual persons who are going to develop the stories into working functionalities.