User Story Splitting

6,032 views

Published on

This is a slide deck I created for workshops I am giving on splitting user stories; it covers several approaches so that people can select the ones that work best for them. If you download it, the throwing stars on first 4 exercises link to the Splitting Kata slide (most people liked having it as a reference while working through the exercises). The Japanese words (per freetranslation.com this is Japanese for 'return') links back to the last slide viewed. This allows easy navigation back to the exercise you jumped from. Of course, if you navigate to a specific pattern, then this won't work any more...

Published in: Technology, Business
2 Comments
24 Likes
Statistics
Notes
No Downloads
Views
Total views
6,032
On SlideShare
0
From Embeds
0
Number of Embeds
25
Actions
Shares
0
Downloads
291
Comments
2
Likes
24
Embeds 0
No embeds

No notes for slide

User Story Splitting

  1. 1. User Story Splitting Or how to be the Ninja on splitting Stories, rather than fruit… Your Sensei: Paul Boos
  2. 2. Master Shifu Reminds Us… A story is a…. • Who | What | Why • As a ____ I would like to ____ so that I can ____ • Role or Persona, ‘Function’, Biz Value
  3. 3. The Power of a Story in San 参 Story Requirement
  4. 4. Dragon Stories (aka ‘Epics’) • Stories that are horrendously large & scare us • The amount of tasks feel like slaying a beast • Larger than our iteration • But even ‘Smaller than Dragon’ Stories may need to be split…
  5. 5. INVEST I ndependent – minimize dependencies (to zero preferably) N egotiable – ability for Product Owner and Delivery Team to make trade-offs V aluable – fulfill end user needs/functionality E stimable – understood well enough to be estimated S mall – fit within a Sprint easily T estable – have an ability to be verified that they work
  6. 6. Should I Split This Story? • Does it meet the INVEST Criteria (with exception of Small)? No – refactor story first* • Can it be completed in this Sprint? No – time to split! • Will this story consume most of the Team’s capacity? Yes – better to split than to be sorry… * If a story isn’t small it may also be hard to be negotiable, so a story being both small and negotiable could be exceptions.
  7. 7. Don’t split a story on Waterfall -like Phases Unless you like riding very, very large waves of failure…
  8. 8. Useful Considerations • Story to– one role/persona (generally) • Story to– one function/task of value • Vertically slices most of the stack
  9. 9. Splitting Kata • Workflow Steps Pattern • Operations Pattern • Business Rule Variations Pattern • Simple  Complex Pattern • Variations in Data Pattern • Mock UI Pattern • Data Entry Methods Pattern • Hamburger Method • Defer Performance Pattern • Break Out a Spike Pattern 戻る
  10. 10. Workflow Steps Pattern Look for steps in the workflow that chain different roles/personas together or very distinctly different functions that can be independently done. Example: Content Authoring & Approval • As an author, I want to be able to submit my article. • As an editor, I would like to get notified when an article has been submitted so that I can review it. • As an editor, I need to approve an article. • As an editor, I would like to be able to request more information
  11. 11. Operations Pattern Focus along Operations (think high level methods or CRUD type operations). Example: As a shop keeper I want to manage the products being sold in my online store so that I can sell what people want to buy. This could be become: • As a shop keeper I want to add and remove products from my online store so that I can sell what people want to buy. • As a shop keeper I want to edit product details in my online store so that I can avoid recreating a product to fix a typo … (and so on) Look for generic verbs such as “manage” or “adminster” which hints at multiple more detailed operations. (Sort of use-case like…)
  12. 12. Business Rules Variation Pattern Find ways to split stories based on business rules deviations. Example: • Payment currency must be specific to purchase location • Cash payment denomination amount must not be greater than . . . • Payment change amount is calculated as . . . • Receipt bar code is designed using . . . Warning: these variations could be articulating various acceptance criteria.
  13. 13. Simple  Complex Pattern Look for general stories that hide complexity, when the definition of the acceptance criteria uncovers varied ways to approach this, then you can split along this variance... Example: • As a loan applicant, I want to calculate my mortgage payments Might be made more specific in ways such as … • … calculate payments manually • … using an online spreadsheet template • … using an online calculator
  14. 14. Variations in Data Pattern Choose data objects that may have variations based on roles and actions. Example: Suppose that there are data objects called Product, Payment, and Receipt. In this instance, the idea would be to focus on specific data types for each object type. So for Product, there might be data types such as Book, DVD, and Gift Card. You can then work with the Product Owner to identify the data type or types with the highest business value and split the story accordingly.
  15. 15. Mock UI Pattern Create a pretotype/whiteboard of the UI when it is known to be complex; ID areas where related functionality is present and story out each area. Throw away the UI. Example: Enter a Valid Address: Street: City: State: Zipcode: Find House Value Comparisons: Select search radius: 5km 10km 25km GoReset As a potential lendee, I want to have a correct address, So that my comparisons are correct. As a potential lendee, I want to set the region, So I can see potential impacts to my comparisons. As a potential lendee, I want to easily reset the data, So I can easily change comparisons.
  16. 16. Data Entry Methods Pattern Examining various options for data entry at the UI can be done. Each option is essentially the same story and thus is a refactoring of a prior story. Great for identifying MVF options… Example: As a user, I can search for flights between two destinations. …using simple date input. …with a fancy calendar UI.
  17. 17. Hamburger Method This method is similar to the prior Data Entry Methods Pattern. It’s useful when a team thinks more along technical tasks than user stories. Example: Simple Data Widget No Data Persistence No Data Validation Calendar Widget Persist Data in File JavaScript Validation Pull Date from user’s iCall Persist Data in RDBMS Persist Data in NoSQL DB Enter Date Store data Validate Collected data Gojko Adzic
  18. 18. Defer Performance Pattern Look for Opportunities to Defer Work for later (and thus refactor of the code). “Simplicity--the art of maximizing the amount of work not done--is essential.” – Agile Manifesto Principle #10 Example: Focus on user functionality 1st then various –’ilities’: Scalability Performance Caution: “Continuous attention to technical excellence and good design enhances agility.” – Agile Manifesto Principle #9
  19. 19. Break out a Spike Pattern Often Stories are not necessarily complex, but just have many unknowns. Turn possible acceptance criteria into questions and investigate these. Example: Suppose you didn’t understand how Paypal worked… Turn As a seller I want to collect payment with Paypal as it is universally accepted and this will increase how I get paid. into… Spike: How does Paypal work? How do I know I have a successful payment? How do I know when a payment is unsuccessful and what options can I present to the buyer? Once I answer these I can create a valid story (or set of stories).
  20. 20. Helpful Tips for Splitting Stories Think in terms of what a user (role/persona) wants as inputs & outputs. • What does the user put in? What should or should not come out? • What processing should give the output? • How can we test this? Think in terms of vertical slices. • What is the minimal version of this functionality? • Can you touch all the needed tiers of the system. Don’t worry about being 100% right… IKIWISI!
  21. 21. Acceptance Criteria Given context When event Then result Be the… Define boundaries of what is acceptable Should be specific to story Results = expectations Identify specific non- functional requirements results
  22. 22. Acceptance Criteria Example • A user cannot submit a form without completing all the mandatory fields • Information from the form is stored in the registrations database • Spam protection is working • Payment can be accepted as a credit card • An acknowledgment email is sent to the user after submitting the form. As a conference attendee, I want to be able to register online, so I can register quickly and cut down on paperwork (Bulet format)
  23. 23. Show Respect Work with your product owner! Who else will you negotiate with..? Card Conversation Confirmation
  24. 24. EXERCISES
  25. 25. Establish Your Dojo for exercises 1 - 4 • Gather in groups of 2-4 • Establish who will be the product owner • Brainstorm stories based on the core epics or features presented • Ensure you have acceptance criteria • Be ready to discuss how you split your stories • Feel free to go to a second level
  26. 26. Exercise 1 You are building an ecommerce site to sell your products. Your Epic: Browse, Select, and Purchase Products from the site. 10 Minutes to create stories based on this Epic. Remember to ID some Acceptance Criteria! We’ll discuss for 10 minutes
  27. 27. Exercise 2 You are building a system to manage content onto your website. Your Epic: Manage Webpages, Images, and Video. 10 Minutes to create stories based on this Epic. Remember to ID some Acceptance Criteria! We’ll discuss for 10 minutes
  28. 28. Exercise 3 You are building an exercise and diet iPhone application. Your Epic: Generate Anyone’s Exercise Routine and Diet. 10 Minutes to create stories based on this Epic. Remember to ID some Acceptance Criteria! We’ll discuss for 10 minutes
  29. 29. Exercise 4 Select your largest story for the next Sprint. Your REAL product owner and SMEs are available to answer questions. Take 15 minutes to do the following: Meet INVEST? Except for small, No = refactor Can we complete in this Sprint? No = split Will it consume most of the Sprint in effort? Yes = split Take 5 minutes to decide on an approach. Take another 15 minutes to brainstorm stories based on that approach. Can you establish some acceptance criteria? 20 minutes to discuss
  30. 30. Gather the Buke for exercises 4 - 5 • Review the stories everyone just created in the last exercise • Select 2 stories you think are well constructed; be able to defend this in terms of INVEST • We’ll use these for our next 2 exercises as one group to learn a bit about vertical slicing
  31. 31. Exercise 4: Walk the Code Dog Take 15 minutes to… Walk through the components of the system one by one that will change. Draw these out (on a flip chart or white board). Did you touch all or most of the layers?
  32. 32. Exercise 5: Walk the Dog in the Component Park Take 15 minutes to… Draw the architecture of your system components on a flip chart or white board. Now redraw your architecture without the connections between them. Using a story you have selected, connect the components as you need to touch them when you implement the story.
  33. 33. For Further Study Great post on how most teams evolve through their story understanding http://www.jbrains.ca/permalink/how-youll-probably-learn-to-split-features The Hamburger Method by Gojko Adzic http://gojko.net/2012/01/23/splitting-user-stories-the-hamburger-method/ Walk the Dog Techniques for Vertical Storieshttp://www.dhavalpanchal.com/walk-the-dog/ 15 ways to split an an Epic (3rd exercise from here)http://blogs.collab.net/agile/15-ways-to-split-an-epic-a-team-exercise Beginner’s Guide to Acceptance Criteria (example) http://www.boost.co.nz/blog/agile/acceptance-criteria/ Derived from Phil Rogers slide deck on Patterns for Splitting User Stories.
  34. 34. You’re a Team No need to be a solo ninja
  35. 35. Let’s go slay some dragons! Or better put, slice some stories!

×