How to Use Behavior Based Requirements to Build Understanding and Save Your Project

There is confusion on your projects and you struggle to get people to understand what needs to be built and why. It doesn’t have to be this way--you can build a common understanding with your team and your stakeholders using Behavior Based Requirements.

Using this new technique, you will capture more from your partners and stakeholders. You will find developers understanding more. You will build a common understanding from user to tester. Oh, and you will save your project.

Transcript

1. How to Use Behavior Based Requirements to Build Understanding & Save Your Project Jeffrey Davidson jeffrey@davidson.net @JeffreyGoodReq IIBA MSP Professional Development Day April 15, 2013
2. © 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 in Simple Made Easy @ StrangeLoop 2011
3. © Jeffrey Davidson, 2013 Jeffrey tries Scrum
4. © Jeffrey Davidson, 2013 Business Analysts should be . . . !  Masters of Communication
5. © Jeffrey Davidson, 2013 Business Analysts should be . . . ! Masters of Communication !  Masters of Value
6. © Jeffrey Davidson, 2013 My realization Value comes from understanding
7. © Jeffrey Davidson, 2013 My realization There is no difference between requirements and understanding
8. © Jeffrey Davidson, 2013 My principles of good business analysis !  We build better software when we understand the goals of what we are building !  We are working on difficult concepts and need to use every tool possible to increase our understanding !  We want a common understanding for everyone involved; from user to stakeholder to analyst to developer to tester to user
9. © Jeffrey Davidson, 2013 Corollaries to the principles !  We build a common understanding best when we communicate using natural language and business terms !  Functional requirements are best understood in context with actors, actions, and results !  These things are called Stories
10. © Jeffrey Davidson, 2013 A (pretend) historical event
11. © Jeffrey Davidson, 2013 Business Analysts should be . . . ! Masters of Communication !  Master Storytellers
12. © Jeffrey Davidson, 2013 – – context You & Your condition What you do What you see Story Structure event response
13. © Jeffrey Davidson, 2013 What are Behavior Based Requirements? !  Fine grained, focused bits of behavior !  Told in a story format
14. © Jeffrey Davidson, 2013 – – Given You & Your condition What you do What you see Simple Structure When Then
15. © 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
16. © Jeffrey Davidson, 2013 Business Terms & Natural Language !  Make it understandable Imagine your grandmother following these directions
17. © Jeffrey Davidson, 2013 Generic over Specific !  Generic behavior (no design) Imagine performing the same actions on a telephone interface!
18. © Jeffrey Davidson, 2013 Behavior Based Requirements: Let’s practice! !  Given: !  When: !  Then:
19. © Jeffrey Davidson, 2013 How did we do? Were you design agnostic? Did you use natural language? Was everything in business terms?
20. © Jeffrey Davidson, 2013 Examples versus Requirements Examples . . . !  . . . amplify what we know !  . . . point out holes in our understanding !  . . . are easy to test !  . . . take requirements and make them real
21. © Jeffrey Davidson, 2013 Behavior Based Requirements: Let’s amplify! !  Given: !  When: !  Then:
22. © 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 in Specification by Example, 2011
23. © 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 in Specification by Example, 2011
24. © 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 in Specification by Example, 2011
25. © Jeffrey Davidson, 2013 Who Benefits? !  Everyone! !  Seriously, it helps everyone. •  Business •  Users •  Testers •  Developers •  Analysts
26. © 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 in Agile Testing, 2009
27. © 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
28. © Jeffrey Davidson, 2013 My realization There is no difference between requirements and understanding
29. © Jeffrey Davidson, 2013 Business Analysts should be . . . ! Masters of Communication !  Facilitators of Understanding
30. © Jeffrey Davidson, 2013 Ferry Boats & Bridges
31. © Jeffrey Davidson, 2013 – – Given You & Your condition What you do What you see When Then
32. © 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 Invented: Feature Injection theitriskmanager.wordpress.com !   Dan North Crevasse of Doom & Invented: BDD dannorth.net
33. © 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
34. How to Use Behavior Based Requirements to Build Understanding & Save Your Project Jeffrey Davidson email: jeffrey@davidson.net twitter: @JeffreyGoodReq blog: goodrequirements.com IIBA MSP Professional Development Day 2013 April 15, 2013