Differences

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

--- how_do_we_split_user_stories [2016/04/29 12:33] – [Additional Information] hpsamios
+++ how_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? ======
-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.
@@ 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.
-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):
@@ 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.
-====== Need To Know More? ======
+====== Want to Know More? ======
   * [[http://www.agileforall.com/wp-content/uploads/2012/01/Story-Splitting-Flowchart.pdf|Splitting Story Flowchart]] - An excellent reference for patterns for splitting stories.
@@ Line 36: / Line 33: @@
-~~LINKBACK~~
-~~DISCUSSION~~