The Art of Storytelling


Published on

Published in: Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

The Art of Storytelling

  1. 1. 1
  2. 2. Picture: 2
  3. 3. Acknowledgments:Mike Cohn’s User stories applied and Agile Estimation and Planning.Jeff Patton’s work on User Role Modeling. 3
  4. 4. 4
  5. 5. Mike Cohn: simple, clear, short description of customer valued functionality 3 parts: written description used for planning, conversation to fleshout details, tests to determine completeness.Ron Jefferies: 3Cs - Card, conversation, confirmation.Rachel Davies: user story represents customer requirements rather than documentsthem. 5
  6. 6. Template: As a type of user, I can achieve some goal so that I can gain some value.Add a title, some notes, assumptions, constraints, priority, estimate. 6
  7. 7. Examples 7
  8. 8. On the back, we add acceptance criteria.Use this template for acceptance tests: Given [context] And [some context] When[event] Then [outcome] And [another outcome].Or simpler version of verify or test. 8
  9. 9. Examples 9
  10. 10. Too much info. Running out of room? 10
  11. 11. Tom Poppendieck advises us to use smaller card.User story covers the who, what and why? It does not cover how? That is where theconversation comes in. 11
  12. 12. The main purpose of a story is to act as a reminder and encourage conversation toflush out details the closer we are to implementing a story.Business, PM, Developer, TesterPicture : 12
  13. 13. 13
  14. 14. 14
  15. 15. IEEE 830: The system shall…1000 requirements in Excel, become 30 functional specs, each about 50 pages.Hand it over to the developers and testers (1500 pages).Process is tedious, error prone, time consuming, boring, hard to see the big picture,hard to prioritize, not goal focused (task oriented).Use cases do a better job at putting things in context, but are still too detailed toadapt to changing customer need.They are bigger, larger in scope, there is the main scenario and then the extensions,pre/post conditions.They act more as an agreement between customer and developer rather than aforum for conversation. 15
  16. 16. User stories directly support the Agile manifesto:User stories support focusing on working software over comprehensivedocumentation.Conversation supports individuals and interactions and customer collaboration.Brevity and high level of user story supports responding to change. 16
  17. 17. Emphasize verbal rather than written communication.Encourage conversation, face to face discussions as opposed to document handoffs. 17
  18. 18. Encourage deferring details until you have better understanding about what youreally need.Avoids unnecessary detailed planning which might change by the time we reachdevelopment time. 18
  19. 19. Provide right size for planning.High level, focus on value and can be prioritized. 19
  20. 20. Comprehensible by customers and developers.Picture: 20
  21. 21. Works for iterative development.Start at high level and flush out details with each iteration and repeat. 21
  22. 22. 22
  23. 23. 1. Use human user. Write story from user’s perspective and understand his goal and value for the story.2. Avoid using generic as a user or as a customer. Think of role as group of users that share common characteristics and based on those characteristics their interactions with system will be different. Think penny pinching college student, busy corporate lawyer, or juggling mother of 3. Try to profile roles and figure out how often will they use the system, how much domain knowledge do they have, are they technically savvy, what is their goal? Pain points?3. Use extreme users. Extreme users are not really target audience, but simply bringing them up can produce different context and lead to interesting discussion. For example, think of the Pope. Or think of a hacker.As a hacker, I can access customer’s payment information to pay for my vacation.Picture: 23
  24. 24. More examples 24
  25. 25. More examples 25
  26. 26. 26
  27. 27. Bill Wake - Invest acronym: Independent, negotiable, valuable, estimatable, small,and testable.Picture: 27
  28. 28. Independent: try to make sure that stories are not interdependent as this might leadto prioritization and planning problems.Independent is different from logical order of developing things. By independent, wemean story features. For example, in earlier credit card example, we wanted tosupport amex, mc and visa. If there are 2 stories, one for mc and another for visa,then estimates will depend on which one gets done 1st because implementing the 2ndwill be relatively straight forward.Options are to combine the stories, or split in a different way (discussed later).If for some reason dependency cannot be removed, then provide 2 estimates on eachstory, one for each order combination. 28
  29. 29. Negotiable:Brief and not a detailed contract.Encourage conversation and negotiation between customer and developers.Picture: 29
  30. 30. Valuable:Provide value to the customer or the user.Start with goal stories and break it out from there.Standish Group: 64% of features are never or rarely used in reality.Ensure value is written. If customer cannot think of value, then they might see workas unnecessary and eliminate it.If value is clearly specified, team might find different ways to achieve same goal withsame value but with less effort.Because story is delivering piece of functionality, customer can figure out how muchfunctionality costs and then decide if they still need it.Not all value is monetary, mitigating risk is value.As a [type of user] I want [some functionality] to avoid [some operational risk,process weakness, ...] 30
  31. 31. Estimatable:Developers need to estimate story.Story needs to be written so developers can understand it and have idea of how toimplement it.Reasons we can’t estimate are lack of domain knowledge, lack of technicalknowledge, or too big.Picture: 31
  32. 32. Small: Not too big, not too small, but just right (1 story half the iteration length).Provide focus and short horizon for the team. Its easier to get lost in the details withlarger story.Easier to adapt and give flexibility to reconfigure and adapt to changes.Large stories increase risk that team will deliver nothing at end of iteration.Large stories can create blockages and bottlenecks. One person who is tied up inlarge story may also be only person who can complete key piece of another story.Picture: 32
  33. 33. Testable:Need to verify that story is complete.Make sure there is acceptance criteria.Non-testable stories usually occur with non-functional requirements: Ease of use,fast, bug free.Try to re-write so that some metric can be measured and test can be written (ideallyautomated). Example: Test that system responds in 1 second or less at least 95% ofthe time.Picture: 33
  34. 34. 34
  35. 35. 35
  36. 36. DependencyStory dependent on another story makes it hard to give correct estimate.Split so one story handles dependency and other handle specifics.Picture: 36
  37. 37. Size – Too biga. Cannot give accurate estimate: Story needs to be more manageable and enable more accurate estimate.b. Cannot fit into iteration: If for example iteration is 1 week long and story is longer than week then it needs to be split to fit into iteration.c. Cannot fit into what’s remaining of iteration: Team has already committed to 38 story points and there is still room for 2 point story but remaining stories are 3 story points or more.Picture: 37
  38. 38. Risk:If complex and risky, split to create spike story which is experimental in nature withmain goal to gain technical knowledge.Picture: 38
  39. 39. Story contains multiple sub stories that are large enough to stand out on their own. 39
  40. 40. Combine many small items onto one larger story.Example: Bug reports can be combined into one “Fix Bugs” story. 40
  41. 41. 41
  42. 42. Slice Vertically: Stories should represent some level of end to end functionality. Thisreduces overall risk and delivers value to customer.Do simplest thing that could possibly work.Important to not split stories into tasks like design, code front end, code middle tier,code back end.Better to deliver cohesive subset of all layers of feature than delivering all of one layeras standalone.Having entire backend ready without corresponding GUI is not very useful.Having feature that allows user to add entity through GUI and have it persisted isfunctionality that can be useful and provides some value. 42
  43. 43. Data Boundaries:Separate local requirements from international requirement.Handling one type of credit card from another.Start with USD then add foreign currency.Picture: 43
  44. 44. Operational boundaries:CRUD boundaries.Separating into search which returns search result count and then search displaywhich displays actual results.Happy path 1st , exceptions next.Picture: 44
  45. 45. Cross Cutting Concern:Features that effect multiple aspects of the application like security, logging, errorhandling can each be separated out of main functionality features.Screen with different menu options based on the login user’s credentials.Security specific feature can be split from main functionality of screen.Picture: 45
  46. 46. Performance constraints:Split functional requirement from non functional requirements.Example: Feature can be enabled without caching and then another story can handlecaching specifics.Picture: 46
  47. 47. Priority:Multiple priorities within a story.Login story might have different priorities for authentication than for handling errorconditions like locking out user after multiple logins.Necessity: Minimum needed to get working software.Flexibility: What are some alternative ways of doing it, what additional data we wantto capture.Safety: Better validation rule to avoid ugly error messages.Comfort, luxury, and performance: More usable, sexier to look at (animation), hotkeys.1.Opening game: Skeleton spans system and contains necessary features2. Mid game: Add capability, flexibility and safety3. End game: Finish with usability, performance, sex appeal and reserve time forunforeseen additions and adaptationsPicture: 47
  48. 48. 48
  49. 49. Contact me 49
  50. 50. 50