Removing Terminology Barriers to Deliver Success

1. Removing Terminology Barriers to Deliver Success @paul_gerrard Paul Gerrard paul@gerrardconsulting.com gerrardconsulting.com

2. Agenda Case Study (2012) Business Stories, Communication, Requirements and Testing Case Study Outcome Lessons Learned This talk is less about terminology and more about communication in general. Intelligent Definition and Assurance

3. Case Study

4. MCH Medway Community Healthcare is a £57 million business with 1,250 staff providing a wide range of both planned and unscheduled care in local settings such as healthy living centres, inpatient units and people's homes. On 1 April 2011 MCH became a social enterprise Community Interest Company (CIC), providing community NHS services to the people of Medway.  @ Intelligent Definition and Assurance

5. Project background • MCH procured and were implementing a community health care system for use by clinical staff • Home visits would be managed by a central system • Clinical staff would use mobile devices to access it • A lot of changes to working practices • 3rd party supplier will build it. Intelligent Definition and Assurance

6. Client viewpoint Essential that clinical staff were involved to ensure buy-in and get the requirements right Wanted a partnership with the supplier to develop a custom solution Potentially, the solution could be sold to other health regions They were keen to develop a standard approach to acceptance testing. Intelligent Definition and Assurance

7. Supplier viewpoint Supplier had already delivered several similar systems using a packaged solution This proposed solution project was the package with customisation Assumed the amount of software change required was limited (~10%) Assumed that the client business would adapt to the package. Intelligent Definition and Assurance

8. Early optimism • Project kicks off • Requirements workshops generate a lot of requirements content and enthusiasm • Supplier is involved but doesn’t attend all sessions • Two levels of requirement • Business requirements – around 80 • Functional requirements – around 500 • Requirements are captured in a spreadsheet, versioned, not shared with supplier directly. Intelligent Definition and Assurance

9. Setback • At the meeting to review and sign-off the final requirements catalogue: • Requirements appear to be more detailed than supplier realised • It’s evident to the client that the supplier does not fully understand some critical requirements • Assumptions about the level of customisation are wrong – more customisation will be required • Concern that delivery will be delayed. Intelligent Definition and Assurance

10. What happened? • Supplier assumed healthcare home visits were the same as any command/control business • The language that clinical staff used was unfamiliar to the supplier team • The package could not easily manage: • Fixed processes defined by the requirements • Business and data rules implied by requirements • Package satisfied many requirements, but failed to match several critical ones. Intelligent Definition and Assurance

11. The challenge • Client view • 6 Critical Business Requirements still at risk (30 functional requirements) • Clinicians lack confidence in solution • Unclear strategy for Acceptance Testing • Supplier view • Frustration at lack of flexibility of the clinical staff • Lack of understanding of ‘simple requirements • “How will we deliver and on time?” Intelligent Definition and Assurance

12. Could business stories help? • We had been talking to MCH about using business stories and our technology • The Business Story Method promotes the use of stories to: • Example and validate requirements • Provide a basis for testing – both development and acceptance testing • But MCH wanted to use the method and technology in a later project • They asked us whether we could help • This is what we said… Intelligent Definition and Assurance

13. Business Stories, Communication, Requirements and Testing

14. The challenge of software Getting knowledge out of stakeholders heads Confirming that the techies understand the need Building the system (the easy part?) Confirming the system does what is required Communicating what the system does Convincing the stakeholder to accept, to pay, to go live with confidence Too many communications channels. Intelligent Definition and Assurance

15. How stories help Stories identify system features and example them Stories can validate requirements Requirements PLUS stories provide a better foundation for developers (less wriggle room) Stories provide logical tests for acceptance; testers can add detail and procedure, if necessary Stories can generate BDD/TDD test code Customer-Supplier contract supported by stories improves requirements stability and the relationship Intelligent Definition and Assurance

16. Stories and Projects Customer Domain Stories validate requirements + Test Detailing Requirements Stories derived from written requirements can be used to walk-through business scenarios and when users see the proposed system ‘in action', requirements anomalies stand out and trigger informed discussions of situations, variations and outcomes. A disciplined approach to story-writing and… Stories Structured OR Agile Requirements Management Tests derived from stories Stories derived from requirements Acceptance Testers Supplier Domain Stories generate test code for TDD Stories example the rules Requirements Define rules Agile Software Development • Developers using TDD can use business stories as a ‘starter for 10’ • Coverage of Business Stories is a necessary, but not sufficient, contractual requirement DevO’Lopper

17. Structured stories (other variations exist) Story Header • Feature: ship orders • As a orders clerk • I want to acknowledge and ship the order • So thatwe fulfil a book order • Scenario: ship a single book from stock • Given I select a valid order • And the ordered book is in stock • When I choose ‘acknowledge and ship’ • Then order status is changed to ‘shipped’ • And an address label is printed Key word Story text Each Story has multiple Scenarios Scenarios can be data driven Intelligent Definition and Assurance

18. Anatomy of a business story header • The story brings together these aspects so we can view the feature from different viewpoint to explore it • Note that roles can sometimes vary, but it is often better to reference ‘personas’ that have multiple roles. • Personas could be “18 year old male gamer” or “65 year old female retired nursery school teacher” for example. Intelligent Definition and Assurance

19. Anatomy of a scenario • The parallel with test cases is obvious: • given=precondition(s), when=steps, then=outcome(s) • A scenario maps directly to a test case – but we haven’t used the word test yet. • If I do – stop me. Intelligent Definition and Assurance

20. Requirements and Business Stories Roles Personas Scope of the Dictionary Business Story As a … I want … So that … Requirement Feature Feature Feature Feature Scenarios Examples Given … When … Then …

21. Stories and scenarios validate requirements Requirement Business Story Feature + Scenarios Scenarios Scenarios Users might start with a story Features and scenarios provide specific examples Requirements articulate general rules Stories validate requirements Trusted requirements and stories emerge from collaboration Intelligent Definition and Assurance

22. The dictionary Requirement A customer may search for an item using any text string. If a customer selects an item the system will … customer Business Story customer Feature Batch update for all reqs, all stories Feature <Data Item> The Index Feature Record Update Feature Scenarios customer <Data Item> Glossary key: Glossary of Terms [Proposed Term] Defined Term - Not Approved customer A customer is… Defined Term - Approved <Data Item> (Scenarios Only) Intelligent Definition and Assurance

23. Uses of the Dictionary • Where is a particular term used? • A business term • A business rule • Anything that can be named in the glossary • Trace usage across requirements, features, scenarios and tests • Use for impact analysis • New forms of coverage by business term are now possible. Intelligent Definition and Assurance

24. businessstorymethod.com DeFOSPAM How to validate a requirement with business stories Google it to see a summary

25. Typical questions to ask of a requirement Definition Feature Outcome Scenarios Prediction Ambiguity Missing What do the nouns and verbs actually mean? What features are being described here? What outcomes do these features provide? What scenarios (normal, extreme, edge and exceptional) should they cope with? Are all outcomes predictable from the text? Are all outcomes unambiguous? Is anything (definitions, features, scenarios or outcomes) missing? Intelligent Definition and Assurance

26. D e F O S P A M Identify the terms One story per feature One scenario per outcome One scenario per scenario Can’t predict? Scenario + guess outcome Two scenarios with conflict Add a story as a suggestion Definitions Features Outcomes Scenarios Prediction Ambiguity Missing Intelligent Definition and Assurance

27. Which and how many scenarios are enough? Scenarios are created to meet several goals To understand feature scope? To get stakeholder to accept? To validate the requirement? To estimate the work to build this feature? To system test this feature? To unit test this feature? Intelligent Definition and Assurance

28. The bigger picture Organisation Applications Initiatives Business Processes Requirements Projects The Dictionary Stake Holders Features Business Story Goals Process Steps Scenarios Risks Example Data Test Procedures Automated Checks Intelligent Definition and Assurance

29. Case Study Outcome Back to the case study

30. How it worked The users were sceptical, so the Project Manager started up the process of creating stories He demonstrated the process to the team; the team were enthused and then took control Focus on critical requirements and created stories detailing required features with examples We helped them to use BSM to capture the requirements, stories and scenarios BSM was used for reporting and review The BSM reports were used as acceptance tests or at least checklists of things to cover. Intelligent Definition and Assurance

31. The client experience Stories provided a better medium for communication between client and supplier to discuss requirements Supplier could challenge requirements and client could demonstrate/illustrate with examples Implemented consistent, understood language for requirements Client adopted acceptance driven testing using stories Clinical staff involved in requirements performed all the acceptance testing with the same trusted requirements. Intelligent Definition and Assurance

32. Positive client reaction Intelligent Definition and Assurance

33. The use of business stories was so successful that they are adopting the same approach on all future projects Intelligent Definition and Assurance

34. Lessons Learned

35. You need BOTH requirements and examples • Requirements are often too general to specify the need (sufficiently) • Examples as tests can be satisfied by partial solutions • Deriving features and scenarios from requirements provides concrete examples: • “Is THIS what you want” • “THIS is inconsistent” • Stories provide a simple mechanism to challenge requirements internally and by the supplier. Intelligent Definition and Assurance

36. Business Stories help client – supplier communications Requirements plus stories provide a more thorough definition of the software’s purpose The developers will appreciate the detail and concrete examples The examples are a better medium for discussion between client and supplier staff. Intelligent Definition and Assurance

37. Business Stories connect Agile teams to non-Agile Business • The Supplier used an Agile approach • The Client had no interest in being Agile • Traditional requirements can be exampled by Agile business stories so that: • Client can use their requirements as references for internal staff • Supplier can use those same stories for BDD/TDD approach in their Agile iterations • Client can reuse them for acceptance too. Intelligent Definition and Assurance

38. Contracts • For as long as we’ve been creating software • Customers assume they can communicate their requirements to the supplier • Suppliers assume a vague requirement is inevitable and they can fix problems later (and charge?) • Most software contracts drawn up by suppliers: • They protect the supplier more than client • They allow the supplier to manage the client • If requirements + stories are contractual, the client can pin down supplier and control them. Intelligent Definition and Assurance

39. Thank-You Intelligent Definition and Assurance

40. References • Our THINKING: Business Story Method(overall method, DeFOSPAM etc.) • http://businessstorymethod.com • Our TECHNOLOGY • http://businessstorymanager.com • Free Story Platform for QA (a subset of BSM) • http://sp.qa • If you want to know how to implement the Business Story Method or tool – do get in touch Intelligent Definition and Assurance

41. Removing Terminology Barriers to Deliver Success @paul_gerrard Paul Gerrard paul@gerrardconsulting.com gerrardconsulting.com