Upgrade to Pro — share decks privately, control downloads, hide ads and more …

How to Improve Your Requirements with Tiny Stories

77d585b881102ee229be5d5af4a11b8b?s=47 Jeffrey
October 21, 2013

How to Improve Your Requirements with Tiny Stories

How to Improve Your Requirements with Tiny Stories

Presented at Project Summit / Business Analyst World in Boston, MA

An accompanying video can be found:

From the conference abstract:
Stop writing boring requirements! No matter how much you love them, they often get in the way of communicating. The secret to good communication isn't is writing more, it's in doing it differently. Instead of stale requirements you should tell tiny stories! Seriously!

During this presentation we will talk about writing requirements with little stories, sometimes known as Behavior Driven Development (BDD), Specification by Example, or Given-When-Then. In the IIBA Agile Extension to the BABOK, it's called Get Real Using Examples (4.6.1). The key isn't the many different names, it's about structuring your requirements based upon behavior. And using this to ensure everyone from user-to-developer-to-stakeholder understands the functionality and goals.

Come and learn about Tiny Stories and how it will help you keep your project on track.

77d585b881102ee229be5d5af4a11b8b?s=128

Jeffrey

October 21, 2013
Tweet

Transcript

  1. How to Improve Your Requirements with Tiny Stories

  2. JEFFREY DAVIDSON consulting business analyst ThoughtWorks. jeffrey.davidson@thoughtworks.com @JeffreyGoodReq goodrequirements.com www.thoughtworks.com

    ®
  3. © Jeffrey Davidson, 2013 Today’s Goals !  Appreciate why we

    need to change !  Practice the structure for easy to understand requirements (stories) !  Discuss why natural language & business terms are better !  Learn how scenarios add huge power
  4. © Jeffrey Davidson, 2013 It’s not easy !  We can

    only hope to make reliable those things that we can understand. !  We can only consider a few things at a time. !  Intertwined things must be considered together. !  Complexity undermines understanding. Rich Hickey Simple Made Easy @ StrangeLoop 2011
  5. © Jeffrey Davidson, 2013 Requirements should be . . .

    !  Valuable !  Concise !  Design-free !  Attainable !  Complete !  Consistent !  Unambiguous !  Verifiable !  Atomic
  6. © Jeffrey Davidson, 2013 Requirements should be . . .

    !  Valuable !  Concise !  Design-free !  Attainable !  Complete !  Consistent !  Unambiguous !  Verifiable !  Atomic
  7. © Jeffrey Davidson, 2013 My realization Value comes from understanding

  8. © Jeffrey Davidson, 2013 My realization There is no difference

    between requirements and understanding
  9. © Jeffrey Davidson, 2013 Principles of good business analysis !

     We build better software when we understand the goals of what we are building
  10. © Jeffrey Davidson, 2013 Principles of good business analysis !

     We are working on difficult concepts and need to use every tool possible to increase our understanding
  11. © Jeffrey Davidson, 2013 Principles of good business analysis !

     We want a common understanding for everyone involved; from user to stakeholder to analyst to developer to tester to user
  12. © Jeffrey Davidson, 2013 My realization There is no difference

    between requirements and understanding
  13. © Jeffrey Davidson, 2013 Corollaries to the principles !  We

    build a common understanding best when we communicate using natural language and business terms
  14. © Jeffrey Davidson, 2013 Corollaries to the principles !  Functional

    requirements are best understood in context with actors, actions, and results These things are called Stories
  15. © Jeffrey Davidson, 2013 Let’s tell a story . .

    . .
  16. © Jeffrey Davidson, 2013 – – context You & Your

    condition What you do What you see Help me tell a better story event response
  17. © Jeffrey Davidson, 2013 Help me tell a better story

    You are a ____ !  Princess ( or Prince ) !  Little girl ( or boy ) !  Teenager
  18. © Jeffrey Davidson, 2013 Help me tell a better story

    You and ____ !  Friend !  Dog !  Parent !  No one
  19. © Jeffrey Davidson, 2013 Help me tell a better story

    You were ____ !  Sleeping !  Walking !  Flying !  Dreaming
  20. © Jeffrey Davidson, 2013 Help me tell a better story

    You were ____ !  In the forest !  By the ocean !  In your bed !  In town
  21. © Jeffrey Davidson, 2013 Help me tell a better story

    When ____ !  You hear a sound !  The pet runs off !  You walk around the corner !  You float Pick 2
  22. © Jeffrey Davidson, 2013 Help me tell a better story

    Then you ____ !  See a monster !  Run !  Say “Hello” !  Hear a horse ask for your help
  23. © Jeffrey Davidson, 2013 Help me tell a better story

    Once upon a time _____ and _____ were ____ _____. As they were ____ they ____ and ____. Then they ____.
  24. © Jeffrey Davidson, 2013 – – Given You & Your

    condition What you do What you see Simple Structure When Then
  25. © Jeffrey Davidson, 2013 What should we be writing? !

     Fine grained, focused bits of behavior !  Told in a story format
  26. © Jeffrey Davidson, 2013 What is it? !  It’s a

    bunch of tiny stories, using a particular grammatical structure !  It’s finding places of misunderstanding, and filling it with understanding !  It’s a conversation, captured
  27. © Jeffrey Davidson, 2013 Business Terms & Natural Language !

     Make it understandable Imagine your grandmother following these directions
  28. © Jeffrey Davidson, 2013 Generic over Specific !  Generic behavior

    (no design) Imagine performing the same actions on a telephone interface!
  29. © Jeffrey Davidson, 2013 !  Given: !  When: !  Then:

    Tiny Stories: Let’s practice!
  30. © Jeffrey Davidson, 2013 How did we do? Were you

    design agnostic? Did you use natural language? Was everything in business terms?
  31. © Jeffrey Davidson, 2013 !  Given: !  When: !  Then:

    Tiny Stories: Let’s practice again!
  32. © Jeffrey Davidson, 2013 Requirements versus Examples Examples . .

    . !  . . . amplify what we know !  . . . point out holes !  . . . are easy to test !  . . . take requirements & make them real
  33. © Jeffrey Davidson, 2013 Let’s make some examples! !  Given:

    I have selected a date to purchase tickets !  When: I submit my selection !  Then: I receive a confirmation for each seat
  34. © Jeffrey Davidson, 2013 Let’s make some examples! !  A

    simple sample example
  35. © Jeffrey Davidson, 2013 Given: Origin Dest Pass Date Boston

    Bahamas 1 Jan 15, 2014 When: Submit Then: Display “Congratulations, you are ready for your trip! Your confirmation numbers are NNNNNN” ConfirmationNo 000001
  36. © Jeffrey Davidson, 2013 Let’s make some examples! !  A

    more complicated sample example
  37. © Jeffrey Davidson, 2013 Given: # Origin Dest Pass Date

    1 Boston Bahamas 1 Jan 15, 2014 2 Boston Bahamas 3 Jan 15, 2014 3 Bahamas Boston 4 Jan 20, 2014 When: Submit
  38. © Jeffrey Davidson, 2013 Then: Display “Congratulations, you are ready

    for your trip! Your confirmation numbers are NNNNNN” # Confirmation 1 000001 2 000002, 000003, 000004 3 000005, 000006, 000007, 000008
  39. © Jeffrey Davidson, 2013 Let’s make some examples! !  Let’s

    make one together
  40. © Jeffrey Davidson, 2013 Stories are about … !  What’s

    happening !  How we got here !  What’s important •  Not everything goes into a story •  Some things belong behind the scenes !  Understanding
  41. © Jeffrey Davidson, 2013 My realization There is no difference

    between requirements and understanding
  42. © Jeffrey Davidson, 2013 Benefits To build the right product

    effectively, software dev practices need: !  Assurance all stakeholders & delivery team members understand what needs to be delivered in the same way Gojko Adzic Specification by Example, 2011
  43. © Jeffrey Davidson, 2013 Benefits To build the right product

    effectively, software dev practices need: !  Precise specifications so delivery teams avoid wasteful rework caused by ambiguities and functional gaps Gojko Adzic Specification by Example, 2011
  44. © Jeffrey Davidson, 2013 Benefits To build the right product

    effectively, software dev practices need: !  An objective means to measure when a piece of work is complete Gojko Adzic Specification by Example, 2011
  45. © Jeffrey Davidson, 2013 Who Benefits? !  Everyone! !  Seriously,

    it helps everyone. •  Business Stakeholders •  Users •  Testers •  Developers •  Analysts
  46. © Jeffrey Davidson, 2013 It’s not about tools “These tools

    are intended for use by programmers to guide coding, but they can also be used to express business facing tests that drive development, involving customers more closely in the process.” Lisa Crispin & Janet Gregory Agile Testing, 2010
  47. © Jeffrey Davidson, 2013 Downsides !  May not help velocity

    !  New-ish (to lots of BAs) !  Tools (and all that jazz) may cause clutter, slow-down, new learning, other stuff
  48. © Jeffrey Davidson, 2013 My realization There is no difference

    between requirements and understanding
  49. © Jeffrey Davidson, 2013 Ferry Boats & Bridges

  50. © Jeffrey Davidson, 2013 My Primary Sources !   Gojko

    Adzic BDD / Specification by Example gojko.net !   Martin Fowler Crevasse of Doom (ferry boats & bridges) martinfowler.com !   Liz Keogh BDD lunivore.com !   Chris Matts Feature Injection theitriskmanager.wordpress.com !   Dan North BDD & Crevasse of Doom dannorth.net
  51. © Jeffrey Davidson, 2013 Share & Tell This is licensed

    under Creative Commons Sharealike [CC BY 3.0] !  Please use it !  Please share it !  Please improve it !  As long as you credit me somewhere
  52. © Jeffrey Davidson, 2013 Video Taped copy Today’s presentation was

    recorded on a home video camera and will be uploaded for public viewing. I am happy to share access to this presentation upon your request.
  53. How to Improve Your Requirements with Tiny Stories JEFFREY DAVIDSON

    consulting business analyst ThoughtWorks. jeffrey.davidson@thoughtworks.com @JeffreyGoodReq goodrequirements.com www.thoughtworks.com ®