User story splitting techniques

User story splitting techniques

• 1.
  Click to editMaster title style User story splitting techniques Ashutosh Rai Assumption: Audience already aware of user stories How to write a good user story.
• 2.
  Click to editMaster title style 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…  Who all need to be involved?  Scrum Master for sure  Technical Lead if required  Some time teams decide this during refinement (grooming) session.
• 3.
  Click to editMaster title style Agile manifesto principle  Do the simplest thing you could possibly do first and get it working end to end.  You have always got something to demonstrate, and a potentially shippable product.  To get there try some of these story splitting approaches…….. Simplicity --the art of maximising the amount of work not done is essential
• 4.
  Click to editMaster title style Split by workflow  If user stories involve a workflow of some kind, the item can usually be broken up into individual steps  What steps does a user perform?  Are all steps necessary (in current sprint only)?  Can steps be simplified (for next sprint)?  Improved understanding of the functionality Does the story describe a workflow?
• 5.
  Click to editMaster title style Split by operations  If a user story involves a number of default operations, such as Create, Read, Update, Deleted (commonly abbreviated as CRUD), Configure, Maintain etc..  What all operation does the story required?  Are all operations necessary ( in next one sprint)?  Can operation be simplified (for next one sprint)? Does the Story have multiple operations?
• 6.
  Click to editMaster title style Split by user roles  User stories often involves a number of roles (or groups) that performs parts of that functionality.  What all roles are involved in this story?  Do we need all these roles(in next one sprint)?  Can some roles be simplified (for next one sprint)? Does the story associates multiple user types.
• 7.
  Click to editMaster title style Split by business rules  In case a story involve a number of explicit or implicit business rules  What rules apply to the story?  Are all rules necessary (in next one sprint only)?  Can simpler rules suffice (in next upcoming one sprint)?  Helps in testing with all expected Scenarios Does the story have multiple business rules?
• 8.
  Click to editMaster title style Split by Acceptance criteria  This strategy is useful when it is hard to break down large user stories based on functionality alone. In that case, it helps to ask how a piece of functionality is going to be tested. Which scenarios have to be checked in order to know if the functionality works?  What all tests are used to verify the story?  What acceptance criteria applies?  Are all test scenarios necessary(for next one sprint only)? Is it difficult to split the functionality alone?
• 9.
  Click to editMaster title style Split by input options / platform  If story have to support various input options and/or platforms, like desktops, tablets, mobile phones or touch screens.  Which all platforms are supported?  Are all platforms necessary (in next one sprint)?  Are some platform harder then other (for next one sprint only)?
• 10.
  Click to editMaster title style Split by happy / unhappy flow  Functionality often involves a happy flow and one or more unhappy flows. The happy flow describes how functionality behaves when everything goes well. If there a deviations, exceptions or other problems, unhappy flows are invoked.  Unhappy flows describe exceptions. By identifying the various flows  What does the happy /unhappy flow look like?  Are all unhappy flows necessary (in one next sprint)?  Can unhappy flow be simplified(for next one sprint)? Split by workflow
• 11.
  Click to editMaster title style Questions? Thank youAshutosh Rai