Differences

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

--- how_do_we_split_user_stories [2015/12/06 10:17] – 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.'"
 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.
+====== Approach ======
 The recommendation is that, where possible, you split large user stories into smaller ones but focus on still providing end user value even when you do the split. In other words as you divide stories up ensure there is some valuable functionality with each story. This contrasts with the approach a typical development organization would take when given a large amount of work to do where the instinct is to split the effort along architectural boundaries (data access layer, middle tier, client tier). The problem with the architectural approach is that:
@@ Line 12: / 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 24: / 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.
-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]]
+====== 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.
+  * [[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}}