Removing Terminology Barriers to Deliver Success @paul_gerrard Paul Gerrard [email protected] gerrardconsulting.com.

Removing Terminology Barriers to Deliver Success

@paul_g

erra

rd

Paul [email protected]

gerrardconsulting.com

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

Slide 2

Case Study

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

AssuranceSlide 4

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.


Slide 5

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.


Slide 6

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.


Slide 7

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.


Slide 8

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

Slide 9

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.


Slide 10

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?”


Slide 11

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…


Slide 12

Business Stories, Communication,

Requirements and Testing

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.


Slide 14

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


Slide 15

Customer DomainSupplier Domain

Stories and Projects

RequirementsStories 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…

RequirementsStories 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…

StoriesStories derivedfrom requirements

Stories validaterequirements

Stories examplethe rules

Dev O’Lopper

Tests derivedfrom stories

AcceptanceTesters

RequirementsDefine rules

+ Test Detailing

Stories generatetest code for TDD

• Developers using TDD can use business stories as a ‘starter for 10’

• Coverage of Business Stories is a necessary, but not sufficient, contractual requirement

Structured OR AgileRequirements Management

Agile Software Development

Story HeaderFeature: ship ordersAs a orders clerkI want to acknowledge and ship the order

So that we fulfil a book order

Scenario: ship a single book from stockGiven I select a valid order And the ordered book is in stockWhen I choose ‘acknowledge and ship’Then order status is changed to ‘shipped’ And an address label is printed

Structured stories (other variations exist)

Key wordStory text

Each Story has multiple ScenariosScenarios can be data drivenIntelligent Definition and

AssuranceSlide 17

Anatomy of a business story headerFeature A label for the FACILITY a user needs to support

their business objective

As a… The ROLE of the user who needs to achieve the goal

I want (to)… The TASK the user wants to perform with the help of the system

So that… The GOAL of the user

• 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.

• The story brings together these aspects so we can view the feature from different viewpoint to explore it


Slide 18

Anatomy of a scenarioGiven… Pre-conditions that define the state of the system or

scenario when the user performs the task

When… The values, inputs, commands or actions executed by the user to complete the task

Then… The outcome of the task (given the preconditions and the user inputs, actions etc.)

• 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

AssuranceSlide 19

Scope of the Dictionary

Requirement

RolesPersonas

Examples

Requirements and Business Stories

Business Story

FeatureFeatureFeatureScenarios

Feature

As a …I want …So that …

Given …When …Then …

Stories and scenarios validate requirements• 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

Requirement

Feature

ScenariosScenariosScenarios

Business Story

+Intelligent Definition and

AssuranceSlide 21

A customer may search for an item using any text string. If a customer selects an item the system will …

Requirement

Business Story

FeatureFeatureFeatureScenarios

Feature

The dictionary

Glossary of Terms

The Index

customer

customer

customer

customer

Record Update

Batch updatefor all reqs, all

stories

A customer is…

Glossary key:[Proposed Term]Defined Term - Not ApprovedDefined Term - Approved<Data Item>

<Data Item>

<Data Item>

(Scenarios Only)


Slide 22

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.


Slide 23

DeFOSPAM

How to validate a requirement with business stories

Google it to see a summary

businessstorymethod.com

Typical questions to ask of a requirement• 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?

Definition

Feature

Outcome

Scenarios

Prediction

Missing

Ambiguity


Slide 25

D e F O S P A M

• Definitions• Features• Outcomes• Scenarios• Prediction

• Ambiguity• Missing

Identify the termsOne story per featureOne scenario per outcomeOne scenario per scenarioCan’t predict? Scenario + guess outcomeTwo scenarios with conflictAdd a story as a suggestion


Slide 26

Which and how many scenarios are enough?• 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?

Scenarios are created to meet several goals


Slide 27

The Dictionary

The bigger picture

Business Story

Organisation

Applications

Requirements

Features

Scenarios

Example Data Automated Checks

Business Processes

Process Steps

Test ProceduresStake

Holders

Initiatives

Goals

Risks

Projects


Slide 28

Case Study Outcome

Back to the case study

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.


Slide 30

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.


Slide 31

Positive client reaction

“Using business stories allowed us to verify our critical requirements and develop our acceptance tests in parallel; resulting in the application being ready for deployment within our stringent time scale.”

“Our testing was based around specific scenarios designed to ensure the required new functionality is present within the system. Each critical requirement was tested using stories and scenarios based on how the system was to be used once deployed.”

“The structure of the scenarios and the use of plain English made it easy for staff to contribute to the definition of the stories and provided an improved understanding to the supplier of our new system.”

“As the structure of the scenarios is exactly the same as a test case, they were also used by staff to undertake the acceptance testing.”


Slide 32

The use of business stories was so successful that they are

adopting the same approach on all future projects


Slide 33

Lessons Learned

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.


Slide 35

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.


Slide 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.


Slide 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.


Slide 39

Thank-You


Slide 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


Slide 41

http://businessstorymethod.com/

http://businessstorymanager.com/

http://sp.qa/

Removing Terminology Barriers to Deliver Success

@paul_g

erra

rd

Paul [email protected]

gerrardconsulting.com

Removing Terminology Barriers to Deliver Success @paul_gerrard Paul Gerrard [email protected] gerrardconsulting.com.

Documents

requirements business

requirements package

critical business requirements

intelligent definition

requirements workshops

functional requirements

supplier viewpoint supplier

case study slide