26 story slicing techniques for any scrum team
- 1. www.agilebin.com 26 Story Slicing Techniques for Any Scrum Team Version 0.3 May 2020 Vijay Kulkarni www.agilebin.com 1
- 2. Agenda • Why a story needs to be sliced? • Incremental Delivery • Identify valuable shippable units (VSUs) • Story slicing techniques • Story Naming Convention • Story slicing mistakes www.agilebin.com 2
- 3. Credits References • http://agileforall.com/patterns-for-splitting-user-stories/ • https://blog.agilistic.nl/8-useful-strategies-for-splitting-large-user-stories-and- a-cheatsheet/ • https://blogs.itemis.com/en/spidr-five-simple-techniques-for-a-perfectly- split-user-story • https://xp123.com/articles/twenty-ways-to-split-stories/ • https://www.mountaingoatsoftware.com/blog/five-story-splitting-mistakes- and-how-to-stop-making-them www.agilebin.com 3
- 4. Why a story needs to be sliced? In enterprise environment, where software's grows from simple multi layer to complex multi tier systems, carving out valuable product increment to be delivered in a sprint become more and more critical. Getting scrum teams to a common understanding on how to slice valuable stories becomes essential. www.agilebin.com 4
- 5. INVEST • I - Independent • N - Negotiable • V - Valuable • E - Estimable • S - Small to fit • T - Testable www.agilebin.com 5
- 8. How will you build a space shuttle using scrum framework? Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. Scrum is a process framework that has been used to manage work on complex products since the early 1990s. Everyone will agree that a space shuttle is complex product. Then the question: How will you build a space shuttle using scrum framework? In this build space shuttle example, for client, the entire value boils down to that one switch, which he would press to fire up the space shuttle. www.agilebin.com 8
- 9. Client – PO conversation Client: Can you guys build a space shuttle for me. It will be first of its kind that nobody has build before. PO: Sure. We can build this product using scrum and deliver it incrementally sprint by sprint. Client: I want the complete product, individual parts are of no use to me. Space shuttle will be launched only when it is fully ready. PO: We will be building the product component by component. Each component will add value to the product. We want your feedback as we build these components, to make sure that we are on right track. We want you to participate in the whole process. Client: Sounds great. In this way, I can allocate budget for each iteration and see the value being delivered at the end of iteration. PO: That's right. I will create the product backlog. The most critical component guess-o-meter will be at the top priority. After first sprint... PO: Team has built the guess-o-meter and tested it successfully. Lets see the demo. Client: I am impressed. Looks like we need to add more power to this guess-o-meter as I am expecting heavy payload on this space shuttle. PO: Sure. Let me add that requirement to the product backlog and prioritize it. After few more sprint.... Client: The space shuttle is really coming along very good. At the beginning, I was not very clear on what I wanted you to build. But with incremental value delivery the product is took shape piece by piece. www.agilebin.com 9
- 10. Story Value • Two level of values • Value to business or end user • Value to product itself • Every increment may not add value to the business or end user but it may add value to the product itself. • Every product increment may not be released to customer at the end of the sprint, but it should add value to the product. • The battery or oil filters inside the car is not directly used by the car driver but they are necessary units for the functioning of the car. www.agilebin.com 10
- 11. Identify valuable shippable units (VSU) • VSUs are the minimum shippable unit which also valuable to the product • For consumers, the end product feature is the entire API service but from release point of potential VSU can be a service method. • Multiple VSU may required to complete the end product feature. • Each VSU can be considered unit of delivery of value and can form a Story. • VSUs may not always cut across technical boundaries. In larger system technical boundaries may define components. www.agilebin.com 11
- 12. ETL : VSUs • Minimum deployable units with business value are • New workflow • Updates to existing workflow • Update existing workflow related steps (like Unix script etc.) • One time data load activities www.agilebin.com 12
- 13. DAL : VSUs • Minimum deployable units with business value are • New DAL service development • Update to existing DAL service • New lookup code additions • Database extract services • Initial or delta batch Load Services • Change notification to third party www.agilebin.com 13
- 14. Micro services : VSUs • Minimum deployable units with business value are • Service methods • PUT • GET • DELETE • POST www.agilebin.com 14
- 15. Database : VSUs • Minimum deployable units with business value are • Create new database object • E.g. Create table etc. • Update existing database object • E.g. Update script etc. www.agilebin.com 15
- 17. Aggregation Vs Composition • Composition is “Made up of” relationship • Engine is made up of various parts. • Strong relationship • Aggregation is “Is Part of” relationship • Battery is part of the car • Weak relationship • In aggregation, sometime, each part is a product in itself • E.g. Battery of car is a product in itself www.agilebin.com 17
- 18. Horizontal Vs Vertical • Horizontal or vertical discussion has third dimension “Context” • Determine the value that is being increment to the product • Try not to slice that value in horizontal Horizontal Vertical Context www.agilebin.com 18
- 20. Recipe Vs. Ingredient In these story slicing technique do not look for recipe for slicing the stories but look for ingredients that will help you to cook multiple story dishes. Recipe Ingredient 1 : Patterns Ingredient 2 : Ideas Ingredient 3: etc. etc. www.agilebin.com 20
- 21. First look at Epic : Best Practice • Product owner to discuss the epic with development team before even try to take first stab at creating any stories. • During the discussion possible stories will be identified. • This will become input to product owner to create further stories. Epic Story Story Story www.agilebin.com 21
- 22. Business Rules Identify business rules. Identify areas where change in constant. Split stories across business rules. Go for the default implementation first and then add business rules incrementally. Default Implementation Business rule 1 : Discount Business Rule 2: Age limit Business Rule 3: xyz Business Rule 3: pqr Default Implementation Business rule 1 : Discount Business Rule 2: Age limit Business Rule 3: xyz Business Rule 4: pqr www.agilebin.com 22
- 23. Workflows Identify workflows in the process. If there are multiple workflows, the split the stories at workflow level and try to further split the complex workflow into simpler workflow and add incremental steps. Path. Step 1 Step 2 Step 3a Step 3b Step 4a Step 4b www.agilebin.com 23
- 24. Interface Methods Split across interface methods. Useful at API layer. Interface GET PUT DELETE GET PUT DELETE www.agilebin.com 24
- 25. Repeat Effort / 1 Vs. Many / Base case Vs. General case First implementation takes time but then it can be reused repeatedly for rest of the implementation. Separating stories for the core logic with add-ons. It's usually easiest to get one right and then move to a collection. Credit Card Process for Visa MasterCard Diners Club American Express Discover Credit Card Process for Visa MasterCard Diners Club American Express Discover www.agilebin.com 25
- 26. Split simple from complex Extract the core simple and minimum implementation from the complex (all at once) scenario. Go for simple implementation first and then build the complex implementation around that. Complex process performing 20 things at once. Add complexity Simple implementation Minimum required version www.agilebin.com 26
- 27. Split condition Vs. Full condition Treat "and," "or," and "then" and other connector words as opportunities to split. Simplify a condition, or do only one part of a multi-step sequence. Do this and that Do this Do that www.agilebin.com 27
- 28. Split across Data Sets If multiple complex data sets are involved in process then split across data sets by category. If implementation is similar for multiple categories then use repeat efforts technique. Process for all members Process for residents Process for migrants www.agilebin.com 28
- 29. Split and then combine Split the process or (user interface) into multiple parts and then combine at the end. Sometimes the individual parts may not provide business values but they can be valid product increments. Data entry form with data viewing grid Data entry form Data viewing grid Data entry form with data viewing grid www.agilebin.com 29
- 30. Non functional requirements Less "ilities," Vs. More "ilities" Non functional and usability requirements can be separated in to stories from the functional implementation. It's easier to defer non-functional requirements. (A common strategy is to set up spikes as side projects to prove out architectural strategies.) Cross cutting aspects can be separated at architecture design level. Login page which load in 2 seconds and even works without mouse Login page Optimization of login page load time Make it work without mouse www.agilebin.com 30
- 31. Small scale Vs. Large scale A system that works for a few people for moderate data sets is a given. After that, each step is a new story. Don't forget the load tests! Large scale Small scale Large scale www.agilebin.com 31
- 32. Operations Multiple operations can be hidden under the ‘manage’ word. As a user, I can manage my account I can sign up for an account. I can edit my account settings. I can cancel my account. Update profile picture Update personal information www.agilebin.com 32
- 33. Happy Path Vs. Unhappy Path Main flow Vs. Alternate flows Separating the happy path implementation from the unhappy path or negative conditions can help. slicing the positive test conditions and negative test conditions can help. (If you can't complete the most trivial transaction, who cares that you have great recovery if step 3 goes bad?) Make this happen Make sure this do not happen Make this happen Make sure this do not happen www.agilebin.com 33
- 34. Split by platform and devices (UI) Split by platform like Apple, android, windows, web and devices like desktops, tablets, mobile phones or touchscreens can help. slicing by browser categories also helpful sometimes. Desktop Tablets Mobile Internet Explorer Google Chrome www.agilebin.com 34
- 35. User Roles Split by user roles. User logs in Admin logs in Member logs in www.agilebin.com 35
- 36. External Dependencies External dependencies can be divided and served one at a time. These dependencies can be downstream or upstream dependencies. This change must support all five external teams in one go Support Team A Support Team B Support Team C Support Team D Support Team E www.agilebin.com 36
- 37. Research Vs. Development Sometimes the ‘How’ part is not so clear to the scrum team to start the development. Research needs to be done before the development can be started. In this situation, it is worthwhile to separate the development from the research. Be aware of who should do the research – product team or development team. Research and Development Research Development www.agilebin.com 37
- 38. Manual first then Automate Sometime developing fully automated solution is relatively big work as compared to developing manual version of it. In some situation it make sense to develop manual version first then automate it. Fully automated solution Develop manual solution Automate the manual solution www.agilebin.com 38
- 39. Batch Vs. Online A batch system doesn't have to interact directly with the user. Front end solution + Backend processing Front end solution Backend processing www.agilebin.com 39
- 40. API only Vs. User Interface Start with API only version and add user interface later. Complete system with User Interface API User Interface www.agilebin.com 40
- 41. Single-User Vs. Multi-User While developing for multiple users you may run into issues like "what happens when two users try to do the same thing at the same time." Focus on single user version first and create separate stories for multiuser scenarios. Support multiple users simultaneously Single user version Make it multiuser www.agilebin.com 41
- 42. Character UI or Script UI Vs. GUI Start with basic command line interface first and build fancy graphical user interface separately. > Input a >5 > Input b >5 > 10 Calculate A B www.agilebin.com 42
- 43. Parts Vs. Assembly Sometimes the shippable valuable unit is large enough to not to fit in a sprint and can not be sliced further keeping the value intact. In such situation, parts of the unit can developed separately and then assembled. Integration testing to be done after the assembly. www.agilebin.com 43
- 44. Spike Vs. Implementation Is it good idea to create spike task in following situations. Spike can be technical work not related to specific story. • Need for proof of concept (POC) before the development can be started • Prepare development environment • Develop technical framework, base libraries etc. POC Prepare Environment Develop base framework Implementation POC : Spike Prepare Environment : Spike Develop base framework: Spike Implementation : Story www.agilebin.com 44
- 45. Enabler Vs. Implementation Sometime there is not enough understanding for the work to be done. Or there are some pre requisites to start the work. In such care creating enabler task can help. Enabler task should enable make the specific story small enough to fit. As a user, I can pay by credit card Implement credit card processing Prepare project repository: Enabler Get architectural guidance: Enabler Get the UI design ready from artiest: Enaber www.agilebin.com 45
- 46. Story Naming Convention • If the stories are going to be sliced left & right then story naming convention become utterly important. • Recommend Story Naming Conventions • A common challenge for teams is how to manage work in the backlog that doesn't fit the “As a <type of user>, I want <some goal> so that <some reason>” template. Feature-Driven Development (FDD and not directly related to TDD or BDD) is a minor player in the Agile methodology space. It does have a nice format for expressing Microservices. • In FDD (not directly related to TDD or BDD), a feature is written in this format: <action> the <result> <by|for|of|to> <object> • As examples, consider these: • Pay a Claim • Register a Customer • Generate a unique identifier for a transaction • Change the text displayed on a kiosk • Merge the data for duplicate transactions • In each case, the feature description starts with the action (a verb) and ends with what would be an object within the system. Author Mike Cohen has written an article expanding the discussion on development other than stories that live in the backlog. www.agilebin.com 46
- 47. Story slicing mistakes • Treating Story slicing as Just the Job of the Product Owner • slicing Stories along Technical Boundaries • Specifying the Solution as Part of the Story • Using a Spike/Enabler on Every Story • Thinking All Business Rules Need to Be Enforced from the Start www.agilebin.com 47
- 48. You Have Done It! • You are now powered with tools and technique to better story slicing • Congratulations • Please share your feedback at www.agilebin.com • And yes, don’t forget to try the free story pointing tool – agilebin poker – at www.agilebin.com/poker • Thank you. www.agilebin.com 48