Slicing and dicing your user stories

6,095 views
6,059 views

Published on

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.

Published in: Technology, Art & Photos
2 Comments
18 Likes
Statistics
Notes
No Downloads
Views
Total views
6,095
On SlideShare
0
From Embeds
0
Number of Embeds
1,670
Actions
Shares
0
Downloads
4
Comments
2
Likes
18
Embeds 0
No embeds

No notes for slide
  • 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
  • Slicing and dicing your user stories

    1. 1. Slicing and dicing your user storiesJenny Wong ● Danilo Sato morphblade
    2. 2. Why are we here?
    3. 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. 4. Why are we here?
    5. 5. Why are we here? “As product owner, I want to understand how this may help me do planning”
    6. 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. 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. 8. What is the real need in slicing and dicing?
    9. 9. What is the real need in slicing and dicing?
    10. 10. Why One Big Chunk does not work LAUNCH
    11. 11. Why One Big Chunk does not work LAUNCH
    12. 12. Why One Big Chunk does not work LAUNCHFEEDBACK
    13. 13. Why One Big Chunk does not work
    14. 14. Why One Big Chunk does not work
    15. 15. Why One Big Chunk does not work
    16. 16. Why One Big Chunk does not work
    17. 17. Why One Big Chunk does not work
    18. 18. Why One Big Chunk does not work
    19. 19. Why One Big Chunk does not work
    20. 20. Why One Big Chunk does not work
    21. 21. Why One Big Chunk does not work
    22. 22. Why One Big Chunk does not work
    23. 23. Why One Big Chunk does not work
    24. 24. Why One Big Chunk does not work
    25. 25. What are the incorrect ways of splitting?STORY Too Big, too small Independent, Negotiable, Value, Estimable, Small, Testable
    26. 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. 27. What are the incorrect ways of splitting? LOG IN USER PROFILE HOMEPAGE Split per page ACCOUNT SETTINGS Independent, Negotiable, Value, Estimable, Small, Testable
    28. 28. Busting Urban Myths
    29. 29. Busting Urban Myths✤ “Splitting stories result in larger estimates on the feature”
    30. 30. Busting Urban Myths✤ “Splitting stories result in larger estimates on the feature”✤ “Takes longer to develop”
    31. 31. Busting Urban Myths✤ “Splitting stories result in larger estimates on the feature”✤ “Takes longer to develop”✤ “I just see incomplete features”
    32. 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. 33. See it in Action!
    34. 34. ✤ 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
    35. 35. Horizontal thinking ... COLOURS LOOK & FEEL PRESENTATION DATA ARCHITECTURE
    36. 36. Horizontal thinking ... COLOURS LOOK & FEEL PRESENTATION DATA ARCHITECTURE
    37. 37. Horizontal thinking ... COLOURS LOOK & FEEL PRESENTATION DATA ARCHITECTURE
    38. 38. Horizontal thinking ... COLOURS LOOK & FEEL PRESENTATION DATA ARCHITECTURE
    39. 39. Does horizontal slicing deliver?
    40. 40. Vertical vs. Horizontal Slicing COLOURS SHOW ALL GENRES SHOW EVENT TYPE SHOW ONE GENRE LINK TO ARTICLE LOOK & FEEL TIMELINE PRESENTATION DATA ARCHITECTUREThe application is split in way that each story can deliver value individually
    41. 41. Does vertical slicing deliver?
    42. 42. Dimensions of splitting
    43. 43. ✤ Business value✤ Risky items✤ Data dependency✤ User interaction and interface✤ Technical implementation, constraints and complexity✤ Stakeholders
    44. 44. Slicing and Dicing
    45. 45. 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?
    46. 46. 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?
    47. 47. Different event types ✤ Different event types have equal priority? ✤ Is all data available for all genres?
    48. 48. Different event types ✤ Different event types have equal priority? ✤ Is all data available for all genres?
    49. 49. 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?
    50. 50. 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?
    51. 51. 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
    52. 52. 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
    53. 53. 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...
    54. 54. 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...
    55. 55. Pivoting business direction? ✤ Generate user traffic? ✤ Sell music? ✤ “UGC”?
    56. 56. Pivoting business direction? ✤ Generate user traffic? ✤ Sell music? BUY ✤ “UGC”?
    57. 57. Putting iterative development in perspective
    58. 58. Release planning of ers keep track Help p roduct own split stories
    59. 59. Release planning of ers keep track Help p roduct own split stories
    60. 60. Release planning of ers keep track Help p roduct own split stories
    61. 61. Release planning of ers keep track Help p roduct own split stories
    62. 62. Release planning of ers keep track Help p roduct own split stories
    63. 63. Feature matrix
    64. 64. Feature matrix
    65. 65. Feature matrix
    66. 66. Feature matrix 75% 60% 85%50% 55% 80% 100% 100% 75% 75%
    67. 67. Product management: story mapping time ves over time & How p roduct evol es prior itise featur
    68. 68. Product management: story mapping Id eas times oal G Sto ries ves over time & How p roduct evol es prior itise featur
    69. 69. Product management: story mapping time ves over time & How p roduct evol es prior itise featur
    70. 70. Product management: story mapping✔ ✗ ✔ ✔ ✔ ✔✔ ✗ ✗ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✗ time✔ ✗ ✔ ✗ ✔ ✔ ✔ ✗ ✔✔ ✔ ✔ ✔ ✔ ✔ ✗ ves over time & How p roduct evol es prior itise featur
    71. 71. Our learning journey✤ Benefits of splitting✤ Engineer the power and affordability to change - and change again✤ Keeping track
    72. 72. Questions & Answers
    73. 73. Obrigada!
    74. 74. Jenny Wong @jenny_wongDanilo Sato @dtsato

    ×