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.

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 ®