Differences

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

--- how_do_we_split_user_stories [2020/06/04 07:42] – Readability hans
+++ how_do_we_split_user_stories [2021/04/28 11:35] (current) – Changed terminology to reflect more modern language hans
@@ Line 13: / 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 25: / 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.