1. Situation Based (WHEN)
1.1. Problem to solve
1.1.1. Technical User Stories
1.1.2. Features/Epics
1.1.3. Complex Stories
1.1.4. Verticle Slicing
1.1.5. How do we know the work/US needs to be sliced?
1.1.6. How Small should the US be sliced?
1.1.7. Thin slicing no longer remains a MVP or of customer value
1.1.8. Constant spillovers or Large User Stories
1.1.9. Too many things stuffed into one User Story
2. Who would use this tool?
2.1. TO DOs
2.1.1. Interview People
2.1.2. List down the people you want to meet
2.1.2.1. Geo-diversity
2.1.2.1.1. R1 - India
2.1.2.1.2. R4 - US & Mexico
2.1.2.1.3. R2 - Germany
2.1.2.1.4. R3 - Brazil
2.1.2.2. How many people should we interview?
2.1.2.2.1. 10 SMs
2.1.2.2.2. 5 Coaches
2.1.2.2.3. 10 PMs
2.1.2.2.4. Developers (experienced)
2.1.2.3. Experince Diversity
2.1.2.3.1. Experienced 3+ years
2.1.2.3.2. Medium 1-3 years
2.1.2.3.3. Novie 0-1 years
2.1.2.4. Build the LIST of People
2.1.3. Understand their challenges
2.1.3.1. Build a list of Questionnaire
2.1.3.1.1. How familiar are you with user story slicing
2.1.3.1.2. Do you regularly practice user story slicing
2.1.3.1.3. What are the challenges you face: 1.Ensuring sliced user stores provide value. 2.Managing stakeholder expecation during slicing. 3.Lack of clear acceptance criteria for slicing 4.Technical constarints 5.Ensuring each slice is independantly delivered 6.Manging dependencies between sliced user stories 7.Resistance to breakning down user stories
2.1.3.1.4. Tools used for user story slicing
2.1.3.1.5. What resources help you with user story slicing
3. Story Slicing Techniques (HOW)
3.1. Richard Laurence
3.1.1. Richard Laurence
3.1.1.1. 1. Prepare The Input User Story
3.1.1.1.1. Does the Story satisy INVEST Criteria?
3.1.1.2. 2. Apply The Splitting Patterns
3.1.1.2.1. 1. Workflow Steps
3.1.1.2.2. 2. Operations
3.1.1.2.3. 3. Business Rule Variations
3.1.1.2.4. 4. Variation in Data
3.1.1.2.5. 5. Interface Variation
3.1.1.2.6. 6. Major/Minor Effort
3.1.1.2.7. 7. Simple/Complex
3.1.1.2.8. 8. Defer Performance
3.1.1.2.9. 9. Spike (last resort)
3.1.1.3. 3. Evaluate The Split
3.1.1.3.1. Choose the split that lets you deprioritize or throw away a story
3.1.1.3.2. Choose the split that gets you more equally sized small stories
3.2. Chris Sims
3.2.1. Chris Sims
3.2.1.1. Start with Classic User Story Format
3.2.1.2. Conjunctions
3.2.1.2.1. Look for connector words
3.2.1.2.2. Example
3.2.1.3. Generic Words
3.2.1.3.1. Look for generic words that **could be replaced with more specic terms **
3.2.1.3.2. Any noun that isn't a proper noun is generic, same goes for adverbs, adjectives, and verbs
3.2.1.3.3. Example
3.2.1.4. Acceptance Criteria
3.2.1.4.1. Acceptance criteria for the laerger story can become a new, smaller user stories whith their own accpetance criteria
3.2.1.4.2. **Example:**
3.2.1.5. Timeline Analysis
3.2.1.5.1. Find User Stories that cannot split using Conjunctions, Generic words, or accpetance criteria.
3.2.1.5.2. Pretend the User Story is done.
3.2.1.5.3. Ask stakeholders, what happens when the functionality is used?
3.2.1.5.4. Stakeholders start describing the sequence of events
3.2.1.5.5. The sequence of events can lead to a series of smaller stories
3.2.1.5.6. **Example:**
3.3. Mike Cohen
3.3.1. Mike Cohn
3.3.1.1. **S** -pikes
3.3.1.1.1. Reseach activity that can give you knowledge you need to split a complex story
3.3.1.2. **P** -aths
3.3.1.2.1. If a user can do something in multiple ways
3.3.1.3. **I** -nterfaces
3.3.1.3.1. Depending on browser or devices
3.3.1.4. **D** -ata
3.3.1.4.1. Simplifying or restricting data
3.3.1.5. **R** -ules
3.3.1.5.1. Relaxing support for the rules can manage large stories
3.3.1.6. Would have presonally preferred if it was called PIDRS - spike should be the last resort
3.4. Peter Stevens
3.4.1. Peter Stevens
3.4.1.1. Personae
3.4.1.1.1. Who was going to use it?
3.4.1.1.2. Why do they want to use it?
3.4.1.1.3. What are the intrinsic motivations of using this feature/story?
3.4.1.1.4. Split on Personae
3.4.1.1.5. Then split on their goals
3.4.1.2. How-to-demo
3.4.1.2.1. Explain the workflow to demonstrate the product
3.4.1.2.2. With the demonstration, it will confirm your understading
3.4.1.3. Acceptance Criteria
3.4.1.3.1. How do you know that it works correctly?
3.4.1.3.2. For integration projects, that may be all you have.
3.4.1.4. And, Or, etc
3.4.1.4.1. Search and Display becomes "Search" and "Display" as separate items
3.4.1.4.2. Convert "et criteria" into explicit list
3.4.1.5. Outcome
3.4.1.5.1. Start with outcome in mind.
3.4.1.5.2. Which user and which feature will enable that outcome?
3.4.1.5.3. Identify the essentials and focus on those aspects first
3.4.1.6. SCURD
3.4.1.6.1. Seach
3.4.1.6.2. Create
3.4.1.6.3. Update
3.4.1.6.4. Read
3.4.1.6.5. Delete
3.4.1.7. Error Handling, unhappy cases
3.4.1.7.1. these are frequent blind spots
3.4.1.8. Non-functionals
3.4.1.8.1. things like performance, UI, and SEO are hard to get right the first time.
3.4.1.8.2. They may require several attempts
3.4.1.8.3. Improve, test, and repeat.
3.4.1.9. Spikes
3.4.1.9.1. If you have alot of questions
3.4.1.9.2. Take a fixed time (say 2 days at minimum)
3.4.1.9.3. Create a basic prototype to confirm your
3.4.1.9.4. Demonstrate the version and then write the stories
3.5. Discover To Deliver
3.5.1. Discover to Deliver
3.5.1.1. User
3.5.1.1.1. Users interact with the product.
3.5.1.1.2. Think about Who wants to buy a product?
3.5.1.2. Interface
3.5.1.2.1. Mechanism users or system employ to exchange data with product
3.5.1.2.2. Think about what interfaces could be used by an individual anonymous buyer
3.5.1.3. Action
3.5.1.3.1. The product provides capabilities for users
3.5.1.3.2. Think about what happens when an individual anonymous buyer wants to buy a product
3.5.1.4. Data
3.5.1.4.1. The product includes a repository of data and useful options
3.5.1.4.2. Think about what data options are available for an individual anonymous buyer
3.5.1.5. Control
3.5.1.5.1. Constraints enforced in a product
3.5.1.5.2. Think about controls that should be enforced when an individual anonymous buyer buys a book with cash payment
3.5.1.6. Environment
3.5.1.6.1. Product conforms to physical properties and technology platform constraints
3.5.1.6.2. Think about where the buyer would be when buying a book,paying with cash
3.5.1.7. Quality Attribute
3.5.1.7.1. Product has certain properties that qualify its operations and development
3.5.1.7.2. Think on what is acceptable performance for any action user does?
3.5.2. Video
3.6. User Story Mapping
3.6.1. Jeff Patton