Uploaded byJenny Wong
Slicing and dicing your user stories
The document discusses the importance of effectively splitting user stories in software development to enhance project planning and execution. It highlights the common misconceptions around story splitting, provides guidelines for effective slicing and dicing, and emphasizes the need for both vertical and horizontal slicing based on business value, risks, and user interaction. The authors aim to educate product owners and developers on how breaking down larger tasks can lead to more manageable and valuable segments in the development process.
More Related Content
Similar to Slicing and dicing your user stories
Slicing and dicing your user stories
- 1. Slicing and dicingyour user stories Jenny Wong ● Danilo Sato morphblade
- 2. Why are wehere?
- 3. Why are wehere? As Pedro the product owner, I want to build the system, so that I can have the system As David the developer, I want to migrate the db
- 4. Why are wehere?
- 5. Why are wehere? “As product owner, I want to understand how this may help me do planning”
- 6. Why are wehere? “As product owner, I want to understand how this may help me do planning” “As a developer, I want to have the tools to explain what we are doing”
- 7. Why are wehere? “As product owner, I want to understand how this may help me do planning” “As a developer, I want to have the tools to explain what we are doing”“As an analyst, I want to learn how to split big chunks into smaller chunks”
- 8. What is thereal need in slicing and dicing?
- 9. What is thereal need in slicing and dicing?
- 10. Why One BigChunk does not work LAUNCH
- 11. Why One BigChunk does not work LAUNCH
- 12. Why One BigChunk does not work LAUNCH FEEDBACK
- 13. Why One BigChunk does not work
- 14. Why One BigChunk does not work
- 15. Why One BigChunk does not work
- 16. Why One BigChunk does not work
- 17. Why One BigChunk does not work
- 18. Why One BigChunk does not work
- 19. Why One BigChunk does not work
- 20. Why One BigChunk does not work
- 21. Why One BigChunk does not work
- 22. Why One BigChunk does not work
- 23. Why One BigChunk does not work
- 24. Why One BigChunk does not work
- 25. What are theincorrect ways of splitting? STORY Too Big, too small Independent, Negotiable, Value, Estimable, Small, Testable
- 26. What are theincorrect ways of splitting? MIGRATE OLD SPLIT DATABASE DATA Not user driven REWRITE REFACTOR ARCHITECTURE JQUERY Independent, Negotiable, Value, Estimable, Small, Testable
- 27. What are theincorrect ways of splitting? LOG IN USER PROFILE HOMEPAGE Split per page ACCOUNT SETTINGS Independent, Negotiable, Value, Estimable, Small, Testable
- 28.
- 29. Busting Urban Myths ✤ “Splitting stories result in larger estimates on the feature”
- 30. Busting Urban Myths ✤ “Splitting stories result in larger estimates on the feature” ✤ “Takes longer to develop”
- 31. Busting Urban Myths ✤ “Splitting stories result in larger estimates on the feature” ✤ “Takes longer to develop” ✤ “I just see incomplete features”
- 32. Busting Urban Myths ✤ “Splitting stories result in larger estimates on the feature” ✤ “Takes longer to develop” ✤ “I just see incomplete features” ✤ “Customers will never buy”
- 33. See it inAction!
- 39. ✤ a running timeline that scrolls in chronological order ✤ the ability to distinguish types of event ✤ get the data for all genres ✤ user can select a genre ✤ hover to view detail of event ✤ click to view related article on website ✤ look and feel, navigation, labels, colours & artistic direction ✤ legend to show types of event
- 40. Horizontal thinking ... COLOURS LOOK & FEEL PRESENTATION DATA ARCHITECTURE
- 41. Horizontal thinking ... COLOURS LOOK & FEEL PRESENTATION DATA ARCHITECTURE
- 42. Horizontal thinking ... COLOURS LOOK & FEEL PRESENTATION DATA ARCHITECTURE
- 43. Horizontal thinking ... COLOURS LOOK & FEEL PRESENTATION DATA ARCHITECTURE
- 44. Does horizontal slicingdeliver?
- 45. Vertical vs. HorizontalSlicing COLOURS SHOW ALL GENRES SHOW EVENT TYPE SHOW ONE GENRE LINK TO ARTICLE LOOK & FEEL TIMELINE PRESENTATION DATA ARCHITECTURE The application is split in way that each story can deliver value individually
- 46. Does vertical slicingdeliver?
- 47.
- 48. ✤ Business value ✤ Risky items ✤ Data dependency ✤ User interaction and interface ✤ Technical implementation, constraints and complexity ✤ Stakeholders
- 49.
- 50. If timeline interactionwas most important ✤ Play timeline story first, to test interaction from design ✤ Lightweight Prototyping? ✤ How about a lightweight spike with dummy data?
- 51. If timeline interactionwas most important ✤ Play timeline story first, to test interaction from design ✤ Lightweight Prototyping? ✤ How about a lightweight spike with dummy data?
- 52. Different event types ✤ Different event types have equal priority? ✤ Is all data available for all genres?
- 53. Different event types ✤ Different event types have equal priority? ✤ Is all data available for all genres?
- 54. If data fora genre is incomplete ✤ Need to fix data for Jazz genre before it can be added to the data ✤ Showcase one other genre first, then add the rest, then add when it is complete ✤ Other genres remain testable. Could we release without Jazz?
- 55. If data fora genre is incomplete ✤ Need to fix data for Jazz genre before it can be added to the data ✤ Showcase one other genre first, then add the rest, then add when it is complete ✤ Other genres remain testable. Could we release without Jazz?
- 56. Detailed vs. Overview ✤ A little bit of everything? ✤ Or everything in one genre? ✤ A way to release a functional application with incomplete data, whilst allowing enhancements
- 57. Detailed vs. Overview ✤ A little bit of everything? ✤ Or everything in one genre? ✤ A way to release a functional application with incomplete data, whilst allowing enhancements
- 58. If the userinterface was challenged ✤ Lab test interaction ✤ Easy to get lost in timeline ✤ Solve problem by adding a date at the bottom ✤ Proceed development, which may be relatively painless. Think of consequences if we only found out MUCH later...
- 59. If the userinterface was challenged ✤ Lab test interaction ✤ Easy to get lost in timeline ✤ Solve problem by adding a date at the bottom ✤ Proceed development, which may be relatively painless. Think of consequences if we only found out MUCH later...
- 60. Pivoting business direction? ✤ Generate user traffic? ✤ Sell music? ✤ “UGC”?
- 61. Pivoting business direction? ✤ Generate user traffic? ✤ Sell music? BUY ✤ “UGC”?
- 62. Putting iterative developmentin perspective
- 63. Release planning of ers keep track Help p roduct own split stories
- 64. Release planning of ers keep track Help p roduct own split stories
- 65. Release planning of ers keep track Help p roduct own split stories
- 66. Release planning of ers keep track Help p roduct own split stories
- 67. Release planning of ers keep track Help p roduct own split stories
- 68.
- 69.
- 70.
- 71. Feature matrix 75% 60% 85% 50% 55% 80% 100% 100% 75% 75%
- 72. Product management: storymapping time ves over time & How p roduct evol es prior itise featur
- 73. Product management: storymapping Id eas times oal G Sto ries ves over time & How p roduct evol es prior itise featur
- 74. Product management: storymapping time ves over time & How p roduct evol es prior itise featur
- 75. Product management: storymapping ✔ ✗ ✔ ✔ ✔ ✔ ✔ ✗ ✗ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✗ time ✔ ✗ ✔ ✗ ✔ ✔ ✔ ✗ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✗ ves over time & How p roduct evol es prior itise featur
- 76. Our learning journey ✤ Benefits of splitting ✤ Engineer the power and affordability to change - and change again ✤ Keeping track
- 77.
- 78.
- 79. Jenny Wong @jenny_wong DaniloSato @dtsato
Editor's Notes
- #2 Introduction: Danilo, Jenny\n\n
- #3 \n
- #4 Audience: already in development teams that practice Agile methodologies; people who want to learn about the core concepts and the applied methods that are being adapted successfully in projects. Not about the basics of story writing, this is a higher up view of how features should be broken down into playable stories. \n\nThe ideas came from the anti-patterns and the bad practices that we have observed in projects. People who may have read the book but are crashing into said practices, failed and announced that Agile does not work. This session, we hope to provide answers to what you should know to make it work, and how it works.\n
- #5 Audience: already in development teams that practice Agile methodologies; people who want to learn about the core concepts and the applied methods that are being adapted successfully in projects. Not about the basics of story writing, this is a higher up view of how features should be broken down into playable stories. \n\nThe ideas came from the anti-patterns and the bad practices that we have observed in projects. People who may have read the book but are crashing into said practices, failed and announced that Agile does not work. This session, we hope to provide answers to what you should know to make it work, and how it works.\n
- #6 Understanding of this helps many groups of people, your stakeholders in the project or product development team\n
- #7 Understanding of this helps many groups of people, your stakeholders in the project or product development team\n
- #8 Understanding of this helps many groups of people, your stakeholders in the project or product development team\n
- #9 Danilo\n
- #10 \n
- #11 - Gone were the days when you are able to release a big feature behind closed doors, expecting great things to happen as soon as you unveil the curtain\n- Consumers are getting to be PROsumers - can organisations afford to invest capital without the necessary safety nets?\n\n
- #12 - By splitting stories to build your feature-set will help reduce risk and waste in $, time, brand\n- Fail fast, recover sooner\n- If you only wanted to discover feedback when everything is done, it may not be as easy to rip everything out and make these changes\n
- #13 - By splitting stories to build your feature-set will help reduce risk and waste in $, time, brand\n- Fail fast, recover sooner\n- If you only wanted to discover feedback when everything is done, it may not be as easy to rip everything out and make these changes\n
- #14 - By splitting stories to build your feature-set will help reduce risk and waste in $, time, brand\n- Fail fast, recover sooner\n- If you only wanted to discover feedback when everything is done, it may not be as easy to rip everything out and make these changes\n
- #15 - By splitting stories to build your feature-set will help reduce risk and waste in $, time, brand\n- Fail fast, recover sooner\n- If you only wanted to discover feedback when everything is done, it may not be as easy to rip everything out and make these changes\n
- #16 - By splitting stories to build your feature-set will help reduce risk and waste in $, time, brand\n- Fail fast, recover sooner\n- If you only wanted to discover feedback when everything is done, it may not be as easy to rip everything out and make these changes\n
- #17 - By splitting stories to build your feature-set will help reduce risk and waste in $, time, brand\n- Fail fast, recover sooner\n- If you only wanted to discover feedback when everything is done, it may not be as easy to rip everything out and make these changes\n
- #18 - By splitting stories to build your feature-set will help reduce risk and waste in $, time, brand\n- Fail fast, recover sooner\n- If you only wanted to discover feedback when everything is done, it may not be as easy to rip everything out and make these changes\n
- #19 - By splitting stories to build your feature-set will help reduce risk and waste in $, time, brand\n- Fail fast, recover sooner\n- If you only wanted to discover feedback when everything is done, it may not be as easy to rip everything out and make these changes\n
- #20 - By splitting stories to build your feature-set will help reduce risk and waste in $, time, brand\n- Fail fast, recover sooner\n- If you only wanted to discover feedback when everything is done, it may not be as easy to rip everything out and make these changes\n
- #21 - By splitting stories to build your feature-set will help reduce risk and waste in $, time, brand\n- Fail fast, recover sooner\n- If you only wanted to discover feedback when everything is done, it may not be as easy to rip everything out and make these changes\n
- #22 - By splitting stories to build your feature-set will help reduce risk and waste in $, time, brand\n- Fail fast, recover sooner\n- If you only wanted to discover feedback when everything is done, it may not be as easy to rip everything out and make these changes\n
- #23 Jenny\nWrong granularity for purpose \n“Implementing INVEST” -- look to INVEST principles\n
- #24 Danilo\n- Work is split but not visible to showcase to user or product owner\n- Showing on database, showing an architecture diagram or a bunch of requirements do not count as value delivered! “WORKING SOFTWARE” is a principle that one must stick to.\n
- #25 Jenny\nOr, slice per “step”, like online shopping where each click is a separate story\n
- #26 Jenny + Danilo\nLarger estimates = high cost? Is the opportunity cost to change higher or lower than cost of development? Cost to change now equal to cost to change later?\n\n
- #27 Jenny + Danilo\nLarger estimates = high cost? Is the opportunity cost to change higher or lower than cost of development? Cost to change now equal to cost to change later?\n\n
- #28 Jenny + Danilo\nLarger estimates = high cost? Is the opportunity cost to change higher or lower than cost of development? Cost to change now equal to cost to change later?\n\n
- #29 Jenny + Danilo\nLarger estimates = high cost? Is the opportunity cost to change higher or lower than cost of development? Cost to change now equal to cost to change later?\n\n
- #30 Danilo\nhttp://www.guardian.co.uk/music/interactive/2011/jun/11/history-modern-music-timeline\n
- #31 - Introduce data visualisation\n- ALL genre view, then EACH genre view\n
- #32 - Let’s first look at how to compartmentalise this “mini app”\n
- #33 - Let’s first look at how to compartmentalise this “mini app”\n
- #34 - Let’s first look at how to compartmentalise this “mini app”\n
- #35 Show this in an illustration over the original screen shot\n
- #36 Jenny\nHorizontal slicing vs. Vertical slicing\nValue driven development\nFeedback and iterative development is the goal\nShow plates with one ingredient - not showcase-able\n
- #37 Jenny\nHorizontal slicing vs. Vertical slicing\nValue driven development\nFeedback and iterative development is the goal\nShow plates with one ingredient - not showcase-able\n
- #38 Jenny\nHorizontal slicing vs. Vertical slicing\nValue driven development\nFeedback and iterative development is the goal\nShow plates with one ingredient - not showcase-able\n
- #39 Jenny\nHorizontal slicing vs. Vertical slicing\nValue driven development\nFeedback and iterative development is the goal\nShow plates with one ingredient - not showcase-able\n
- #40 \n
- #41 Value driven development; EACH story delivers independent value - independent and distinct\nFeedback from all levels, “For. That. Feature.”\n
- #42 Should this be different pasta dishes?\n
- #43 Ask the user which elements are the most important\n
- #44 Danilo\n
- #45 \n
- #46 Jenny (x3) & Danilo (x3)\nIntroduce a few scenarios WHYY splitting should be tailored to the business priorities\n
- #47 Jenny\n- Test-driven implementation, feedback-driven design\n- During the implementation, keep in mind an attitude of iterative design\n
- #48 Danilo\nAlbum vs. Politics vs. Fashion\n
- #49 Jenny\n- For example, need to manually link all jazz events to the article on the site before launch... or could it be without? (Help facilitate opportunities to ask these questions)\n
- #50 Danilo\n
- #51 Jenny\n- Vision or core purpose of application "Generate user traffic vs. sell music"\n
- #52 Danilo\n\n
- #53 Jenny: “How to manage things now?” --\n
- #54 - Could indicate stories and / or high level features that belong to various stakeholders (editorial, SMEs, Product Owners)\n- E.g. Group by stakeholders, stickers to differentiate on release planning wall\n
- #55 - Could indicate stories and / or high level features that belong to various stakeholders (editorial, SMEs, Product Owners)\n- E.g. Group by stakeholders, stickers to differentiate on release planning wall\n
- #56 - Could indicate stories and / or high level features that belong to various stakeholders (editorial, SMEs, Product Owners)\n- E.g. Group by stakeholders, stickers to differentiate on release planning wall\n
- #57 - Could indicate stories and / or high level features that belong to various stakeholders (editorial, SMEs, Product Owners)\n- E.g. Group by stakeholders, stickers to differentiate on release planning wall\n
- #58 - X-axis = Features or feature-set; Y-axis = Estimates of that feature-set\n- “The bar” grows as new stories are added or taken out\n- When stories are delivered they are adjusted\n
- #59 - X-axis = Features or feature-set; Y-axis = Estimates of that feature-set\n- “The bar” grows as new stories are added or taken out\n- When stories are delivered they are adjusted\n
- #60 - X-axis = Features or feature-set; Y-axis = Estimates of that feature-set\n- “The bar” grows as new stories are added or taken out\n- When stories are delivered they are adjusted\n
- #61 \n
- #62 \n
- #63 \n
- #64 1) Choose vertical over horizontal\n2) Learn from feedback - fail faster, recover sooner\n3) Not losing a forest for a tree\n
- #65 \n
- #66 \n
- #67 \n