Search

Best Ways To Split User Stories For Efficient Product Backlog Refinement

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“ INVEST  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: Generic Terms: 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 Connectors : 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. Acceptance criteria:  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. Workflow steps:  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.
Best Ways To Split User Stories For Efficient Product Backlog Refinement
Nidhya
Rated 4.0/5 based on 16 customer reviews
Nidhya

Nidhya Palaniappan

Scrum Master | Agile Project Manager

Posts by Nidhya Palaniappan

Best Ways To Split User Stories For Efficient Product Backlog Refinement

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“ INVEST  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: Generic Terms: 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 Connectors : 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. Acceptance criteria:  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. Workflow steps:  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.
Rated 4.0/5 based on 16 customer reviews
Best Ways To Split User Stories For Efficient Prod...

Product Backlog and User Stories: Product Backlog is an essential a... Read More

Empowering Teams with the Art of Positive Assumptions

What are assumptions?               In simple words, assumptions can be termed as “Personal Beliefs” or “Expectations” without any concrete evidence. These assumptions can be about a person, place, thing, the outcome of certain activity etc. Every one of us assumes at various points in our lifetime. Sometimes we even assume about our own capability. These beliefs can be either positive or negative. They may or may not turn into reality. In any case, all our behaviors and actions are closely related to our assumptions. Hence we should be cautious while making assumptions as they can make or break things.  Impact of Positive Assumptions        Building affirmative assumptions keeps us in peace and eases our life a lot. Because “Positivity” is like a boomerang! Let us see how we could use this boomerang to empower our teams: The strength of every scrum team is based on how well its team members collaborate with each other. The primary responsibility of a Scrum Master / Coach is to build a strong bonding among his / her team members. When there is a strong bonding, they trust one another, lend helping hands, collaborate well and deliver high values; above all, they will be more excited to work together. The major challenge in building a close-knit team is overcoming the conflicts that arise among its members. Conflicts are inevitable when people of different personalities work together.  Why do conflicts occur?         One of the basic reasons for workplace disputes is that the intent of the opponent’s action is assumed to be negative. We generally judge that the intention of all the souls close to our heart is good; on the other hand, in every occasion cynical about the act of the persons with whom we don’t get along well. The moment our thoughts are non-affirmative, our behaviors change and we go to any extent to distress them. Assuming Good Intention        What if we think the objective of others is good?  Just close your eyes and think for a few minutes about your childhood. Every one of us would have had fights with our siblings or friends when we were young. Did we carry it on for a long time?  Did we detest them forever? In fact, we had a lot more merry times with them after those fights right? This is because as kids we were not making any judgment of others considering their past actions; we were able to forgive and forget others mistakes. Let us bring back the same into practice now.It gives us a different perspective to look at the actual issues behind the conflicts. Therefore, being non-judgmental and assuming positive intent of every action is the key to improving intimacy among the team members. How do we get the team to assume on positive intention? We should coach the members on the following:-   Avoiding preconceived notions within and outside:                           Encourage the team to have open communications and make them focus on the facts, rather than on their beliefs. Help them use "open ended questions" for generating more insights about a person or a situation.  For instance, if a relatively junior resource joins the team , others may assume that he/she would not be proficient in domain knowledge and do not give him critical tasks. In reality, the new joiner might have strong technical skills and quick learning capability, still hesitating to open up to the seniors thinking that they may not help. Here, as a Scrum Master/ Coach, we can foster an environment, wherein both the parties discuss frankly and come forward into a mentoring relationship. Having direct communication whenever possible:          Enable the team to have more face-to-face communications than mail conversations. This is because in mails the messages are open to interpretation. Elucidating the right tone of a mail or text message would be difficult when we can’t hear the sender's voice inflection or view their body language. The accurate interpretation of any message depends on the mood of the person who crafted it as well as the one who reads it. Thus it is always better to have direct communications.    Analyzing the situational context for any actions:         For any workplace conflicts, there might be certain triggering points. Assist the team to identify those points by assessing the background and situation of the contentions. Once the origin is understood, help them discern the solution in an amicable way.           I would like to share an incident here. In one of my teams, a team member started coming late to office frequently and because of this his deliverables were getting delayed. Others in the team began to blame him, thinking that he was negligent towards his tasks. I got into this issue, had a discussion with that particular team member and understood that he had an ailing dependent at home whom he ought to take care for few months. When others were aware of this, they came forward and charted out a plan, to work in such a way that the deliverables were not impacted, at the same time his personal need was also fulfilled.     Restricting generalization:     Generalization is usually a form of exaggeration. For example, a statement like "Onshore team members always don’t understand the challenges of the offshore team" is a generalized one. It is obvious that every onshore team in an organization does not go by this statement. Hence make the team clearly comprehend all the factors before proceeding with any generalization. This will make sure that they have a clear state of mind which in turn leads to good rapport with their colleagues. Separating the persons from the problems:       Nobody wants to be a problem creator mindfully. As a Scrum Master/coach we should articulate the issues clearly, separating them from the people who appear to be the core of those issues. This helps the team to distinguish the problems from the persons, stop hating those persons for their actions and allowing them to course correct their behaviors. Improvising the Emotional Quotient:         Emotional Intelligence is the capability to recognize, manage and utilize the emotions of ourselves and others in a positive way. It gives us the ability to control and override our impulses. Moreover, it promotes empathizing, reduces stress levels and anxiety, defuses conflicts, aids better communication and improves relationships. Recognizing the opportunities and growth factors in every feedback:            Giving and receiving feedback is an effective way to raise the awareness of a person's strengths and improvement areas. In a workplace, feedback may come from any co-worker, either in a formal or informal manner, constructive or destructive in nature. In general , constructive feedbacks motivate an employee a lot, whereas the destructive feedback works in a negative way. But it is always wise to analyze every feedback, appreciate the underlying values and utilize them as an opportunity for personal and professional betterment. Changing the perceptions:            Persuade the team to change their viewpoints into the positive directions.        Once I received an opportunity to harmonize a Scrum team, which was dysfunctional due to various reasons. I observed them for few weeks. Got to understand each of the members personally. Spotted that the false opinions and lack of trust are the base for the team's dysfunction. I wanted to get rid of their false opinions at first place. Having all the team members in a room, conducted an activity as below: Team members were made to be seated around a table (ensured that friends are not seated nearby ) Had set the stage that it is an opportunity to know more about their team mates. Provided a white sheet and a pen to everyone. In 3 minutes, they have to list down the positive traits whichever they had observed from their neighbors over the period. If there were no direct observations, whatever they felt or believed as their neighbor’s strengths, good characters can be written.  When everyone completed their writing, asked them to share what they wrote to the entire team. Facilitated to elaborate the situations in which they observed those positivity of their teammates; on the other hand if someone had assumed about others good characteristics, encouraged them to share what made them to think so.   The above activity was not an instant solution to the problem which the team was facing; however, it gave a good start to know each other better and come closer. People started looking others in a different perspective, through the lens of positivity, which removed the mental blocks at first which eventually resolved other issues.       Following the above practices will ensure that the team members always assume for positive intentions and remain tightly knit. Hope you also would be trying these with your teams and sharing the valuable experiences.  Happy Coaching :-) !  
Rated 4.0/5 based on 20 customer reviews
Empowering Teams with the Art of Positive Assumpti...

What are assumptions?               In simple words, assumpti... Read More