User Tools

Site Tools


how_do_we_split_user_stories

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
how_do_we_split_user_stories [2015/12/07 03:45] hpsamioshow_do_we_split_user_stories [2021/04/28 11:35] (current) – Changed terminology to reflect more modern language hans
Line 1: Line 1:
 ====== How Do We Split a User Story? ====== ====== How Do We Split a User Story? ======
  
-Basic answer is "By end user value - ask yourself 'What kind of feedback do you expect from the customer at the Sprint Review.'" +Basic answer is "By end user value - ask yourself 'What kind of feedback do you expect from the customer at the Sprint Review.'"
- +
-====== Premise ====== +
 User stories have a life-cycle. When we start into a release planning process, we might only have a "top 10" list of features required for this release. These are typically called Epics. Scrum Teams are told that they have to complete an entire user story before moving on to the next one in a Sprint and further that they should have between say 5-10 user stories per sprint. How do we get from the Epic to User Stories of this size? The answer is that we increasingly detail the requirements by splitting the Epic and subsequent User Stories into smaller and smaller User Stories. User stories have a life-cycle. When we start into a release planning process, we might only have a "top 10" list of features required for this release. These are typically called Epics. Scrum Teams are told that they have to complete an entire user story before moving on to the next one in a Sprint and further that they should have between say 5-10 user stories per sprint. How do we get from the Epic to User Stories of this size? The answer is that we increasingly detail the requirements by splitting the Epic and subsequent User Stories into smaller and smaller User Stories.
  
Line 16: Line 13:
 In other words, resist dividing the story up along "technical" boundaries as this will result in iterations of development with nothing complete (and valuable) to the end user. In other words, resist dividing the story up along "technical" boundaries as this will result in iterations of development with nothing complete (and valuable) to the end user.
  
-The question is then "how to I split a story if I don't use architectural boundaries?" One basic approach is to take the "Conditions of Satisfaction" for a User Story and use that to split the story up. So for example if the user story was "As a customer I want to pay with a credit card so I can get the item on sale", the "Conditions of Satisfaction" might be "Accept Visa; Accept MasterCard; Accept American Express" and so on. If it was determined that the Story is too big to fit in a Sprint, then you could split the Story as "As a customer I want to pay with a Visa card so I can get the item on sale" with its own Conditions of Satisfaction, and so on. Keep going until you have high priority items in the Product Backlog that are right-sized for a Sprint.+The question is then "how to I split a story if I don't use architectural boundaries?" One basic approach is to take the "Acceptance Criteria (or Conditions of Satisfaction)" for a User Story and use that to split the story up. So for example if the user story was "As a customer I want to pay with a credit card so I can get the item on sale", the "Acceptance Criteria (or Conditions of Satisfaction)" might be "Accept Visa; Accept MasterCard; Accept American Express" and so on. If it was determined that the Story is too big to fit in a Sprint, then you could split the Story as "As a customer I want to pay with a Visa card so I can get the item on sale" with its own Acceptance Criteria (or Conditions of Satisfaction), and so on. Keep going until you have high priority items in the Product Backlog that are right-sized for a Sprint.
  
 This type of thinking leads to the following general possibilities (using a different example): This type of thinking leads to the following general possibilities (using a different example):
Line 28: Line 25:
 To make sure you have something valuable ask yourself "Will the Customer be able to provide feedback on this functionality at the Sprint Review?" If you cannot figure out what kind of feedback the customer will provide, you probably have a user story that is more technical than from the business value that is being provided. To make sure you have something valuable ask yourself "Will the Customer be able to provide feedback on this functionality at the Sprint Review?" If you cannot figure out what kind of feedback the customer will provide, you probably have a user story that is more technical than from the business value that is being provided.
  
-====== Additional Information ======+====== Want to Know More? ======
  
-An excellent reference for patterns for splitting stories is at [[http://www.agileforall.com/wp-content/uploads/2012/01/Story-Splitting-Flowchart.pdf|Splitting Story Flowchart]]+  * [[http://www.agileforall.com/wp-content/uploads/2012/01/Story-Splitting-Flowchart.pdf|Splitting Story Flowchart]] - An excellent reference for patterns for splitting stories. 
 +  * [[how_do_we_build_and_maintain_context_when_all_we_have_is_a_backlog_list|How Do We Build and Maintain Context When All We Have Is a Backlog List?]]
  
 {{tag>Consultant Tools UserStory Stories Splitting FAQ}} {{tag>Consultant Tools UserStory Stories Splitting FAQ}}
 +
 +
/home/hpsamios/hanssamios.com/dokuwiki/data/attic/how_do_we_split_user_stories.1449488748.txt.gz · Last modified: 2020/06/02 14:27 (external edit)