Slicing and dicing your user stories
•
24 likes•7,890 views
This was a talk given by Jenny Wong and Danilo Sato at Agile Brazil 2011: Agile teams learned that splitting teams into silos and functional areas is not a productive way to develop software. Having cross-functional teams improve collaboration and enables delivery of value faster. The same arguments can be applied to user stories. The way in which business requirements and features are translated into user stories play an important role on the software delivery process. This session will discuss the benefits of working with small user stories, and present different ways to split requirements into user stories.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Slicing and dicing your user stories
Similar to Slicing and dicing your user stories (20)
Recently uploaded
Recently uploaded (20)
Slicing and dicing your user stories
- 1. Slicing and dicing your user stories Jenny Wong ● Danilo Sato morphblade
- 2. Why are we here?
- 3. Why are we here? 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 we here?
- 5. Why are we here? “As product owner, I want to understand how this may help me do planning”
- 6. Why are we here? “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 we here? “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 the real need in slicing and dicing?
- 9. What is the real need in slicing and dicing?
- 10. Why One Big Chunk does not work LAUNCH
- 11. Why One Big Chunk does not work LAUNCH
- 12. Why One Big Chunk does not work LAUNCH FEEDBACK
- 13. Why One Big Chunk does not work
- 14. Why One Big Chunk does not work
- 15. Why One Big Chunk does not work
- 16. Why One Big Chunk does not work
- 17. Why One Big Chunk does not work
- 18. Why One Big Chunk does not work
- 19. Why One Big Chunk does not work
- 20. Why One Big Chunk does not work
- 21. Why One Big Chunk does not work
- 22. Why One Big Chunk does not work
- 23. Why One Big Chunk does not work
- 24. Why One Big Chunk does not work
- 25. What are the incorrect ways of splitting? STORY Too Big, too small Independent, Negotiable, Value, Estimable, Small, Testable
- 26. What are the incorrect ways of splitting? MIGRATE OLD SPLIT DATABASE DATA Not user driven REWRITE REFACTOR ARCHITECTURE JQUERY Independent, Negotiable, Value, Estimable, Small, Testable
- 27. What are the incorrect ways of splitting? LOG IN USER PROFILE HOMEPAGE Split per page ACCOUNT SETTINGS Independent, Negotiable, Value, Estimable, Small, Testable
- 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 in Action!
- 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 slicing deliver?
- 45. Vertical vs. Horizontal Slicing 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 slicing deliver?
- 48. ✤ Business value ✤ Risky items ✤ Data dependency ✤ User interaction and interface ✤ Technical implementation, constraints and complexity ✤ Stakeholders
- 50. If timeline interaction was most important ✤ Play timeline story first, to test interaction from design ✤ Lightweight Prototyping? ✤ How about a lightweight spike with dummy data?
- 51. If timeline interaction was 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 for a 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 for a 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 user interface 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 user interface 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 development in 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. Feature matrix
- 69. Feature matrix
- 70. Feature matrix
- 71. Feature matrix 75% 60% 85% 50% 55% 80% 100% 100% 75% 75%
- 72. Product management: story mapping time ves over time & How p roduct evol es prior itise featur
- 73. Product management: story mapping Id eas times oal G Sto ries ves over time & How p roduct evol es prior itise featur
- 74. Product management: story mapping time ves over time & How p roduct evol es prior itise featur
- 75. Product management: story mapping ✔ ✗ ✔ ✔ ✔ ✔ ✔ ✗ ✗ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✗ 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
- 78. Obrigada!
- 79. Jenny Wong @jenny_wong Danilo Sato @dtsato
Editor's Notes
- Introduction: Danilo, Jenny\n\n
- \n
- 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
- 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
- Understanding of this helps many groups of people, your stakeholders in the project or product development team\n
- Understanding of this helps many groups of people, your stakeholders in the project or product development team\n
- Understanding of this helps many groups of people, your stakeholders in the project or product development team\n
- Danilo\n
- \n
- - 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
- - 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
- - 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
- - 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
- - 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
- - 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
- - 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
- - 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
- - 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
- - 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
- - 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
- - 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
- Jenny\nWrong granularity for purpose \n“Implementing INVEST” -- look to INVEST principles\n
- 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
- Jenny\nOr, slice per “step”, like online shopping where each click is a separate story\n
- 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
- 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
- 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
- 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
- Danilo\nhttp://www.guardian.co.uk/music/interactive/2011/jun/11/history-modern-music-timeline\n
- - Introduce data visualisation\n- ALL genre view, then EACH genre view\n
- - Let’s first look at how to compartmentalise this “mini app”\n
- - Let’s first look at how to compartmentalise this “mini app”\n
- - Let’s first look at how to compartmentalise this “mini app”\n
- Show this in an illustration over the original screen shot\n
- 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
- 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
- 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
- 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
- \n
- Value driven development; EACH story delivers independent value - independent and distinct\nFeedback from all levels, “For. That. Feature.”\n
- Should this be different pasta dishes?\n
- Ask the user which elements are the most important\n
- Danilo\n
- \n
- Jenny (x3) & Danilo (x3)\nIntroduce a few scenarios WHYY splitting should be tailored to the business priorities\n
- Jenny\n- Test-driven implementation, feedback-driven design\n- During the implementation, keep in mind an attitude of iterative design\n
- Danilo\nAlbum vs. Politics vs. Fashion\n
- 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
- Danilo\n
- Jenny\n- Vision or core purpose of application "Generate user traffic vs. sell music"\n
- Danilo\n\n
- Jenny: “How to manage things now?” --\n
- - 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
- - 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
- - 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
- - 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
- - 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
- - 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
- - 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
- \n
- \n
- \n
- 1) Choose vertical over horizontal\n2) Learn from feedback - fail faster, recover sooner\n3) Not losing a forest for a tree\n
- \n
- \n
- \n