Dev Day

Executable Specifications With Scrum Aruna Dissanayake

2  

Agenda

• What we build vs How we build • Moving from Waterfall to Agile • Understanding stakeholder desires • Defining Boundaries • Expressing desires • Focusing on Value • Confirming Stories • Executing requirements • A BDD Test framework

3  

If you are going to put time and effort into solving a problem, solve it right •  first ensure you solve the right problem and •  then solve it right

Philip Stanhope, 4th Earl of Chesterfield

What

How

4  

Uncertainty Matrix

Low  

Low  

High  

High  

Uncertainty  of  “What”  

Uncertainty  of  “Ho

w”  

Traditional

R&D

Agile

Chaos

5  

Requirements  

Design  

Verifica;on  

Implementa;on  Design  Spec  

Test  Spec  

Req.  Spec  

Traditional Requirements

6  

Does Agility Means No Specs?

•  Short  Feedback  Cycles  •  Sprints  should  fulfill  the  requirements  in  the  

order  stakeholders  want  to  evaluate  them  

Sprint  Backlog  

7  

Why Does Software Exist?

A desire is a discrete piece of demonstrable functionality that is valuable to a stakeholder or a group of stakeholders.

• Specifications describe the important desires perceived as requirements

8  

Defining the Boundaries

• Scope is the guardrails of our journey discovering stakeholder desires

• Define certainties and the thing that will hardly change

•  Shared vision – what the software needs to accomplish •  Meaningful common goal – why we build this product •  List of high-level features/epics – the boundary of our product

9  

Expressing Desires via User Stories

As a <role>, I want <desire> so that <benefit>

•  Independent: Should not depend on other stories •  Negotiable: Should be able to change or discard •  Valuable: Should provide value to stakeholders •  Estimable: Should be able to estimate rough size •  Small: Should not take more than few days to implement •  Testable: Should help deriving the acceptance criteria

What Who Why

10  

Sample User Story

Story: Multiplying two numbers As a math novice I want to find the product of two numbers So that I can practice multiplication tables

11  

Focusing on Value

Feature  Usage  Frequency    (A  Standish  Group  Study)  

12  

Backlog Grooming

Rank  

Illustrate  

Size  

Split  

Value/Priority  

Sprint  Backlog  

13  

Removing the Ambiguity of Stories

• Stories are loosely written with minimal information

• Words can be ambiguous leading to miscommunications

• Ambiguity can be removed by giving concrete examples

•  Storyboards •  Scenarios

14  

Scenarios

Current  State  

Expected  State  

Precondi;ons  

Ac;on  

Consequences  

Given  

When  

Then  

15  

Gherkin

Given [List of Preconditions] When [an Action Occurred] Then [List of Consequences] Eg: Story: Multiplying two numbers As a math novice I want to find the product of two numbers So that I can practice multiplication tables Scenario 1: Simple multiplication Given I have entered 2 And I have entered 3 When I press “*” button Then 6 should be displayed as the result

16  

Another Example

Story: Account Holder withdraws cash As an Account Holder I want to withdraw cash from an ATM So that I can get money when the bank is closed Scenario 1: Account has sufficient funds Given the account balance is Rs10,000 And the card is valid And the machine contains enough money When the Account Holder requests Rs2,000 Then the ATM should dispense Rs2,000 And the account balance should be Rs8,000 And the card should be returned

17  

Scenario 2: Account has insufficient funds Given the account balance is Rs1,000 And the card is valid And the machine contains enough money When the Account Holder requests Rs2,000 Then the ATM should not dispense any money And the ATM should say there are insufficient funds And the account balance should remain Rs1,000 And the card should be returned Scenario 3: Card has been disabled Given the card is disabled When the Account Holder requests Rs2,000 Then the ATM should retain the card And the ATM should say the card has been retained Scenario 4: The ATM has insufficient funds ...

18  

Two Step Scenario Review

User  Story  

Basic  Scenario  1  

Basic  Scenario  2  

Basic  Scenario  …  

Basic  Scenario  n  

Extended  Scenario  1  Extended  Scenario  2  Extended  Scenario  …  Extended  Scenario  m  

Extended  Scenario  1  Extended  Scenario  2  Extended  Scenario  …  Extended  Scenario  m  

Extended  Scenario  1  Extended  Scenario  2  Extended  Scenario  …  Extended  Scenario  m  

Extended  Scenario  1  Extended  Scenario  2  Extended  Scenario  …  Extended  Scenario  m  

Step  1   Step  2  Backlog  Grooming   Team  Spec  Review    

Prior  to  Sprint  Planning  

19  

Putting All Together

Rank  

Illustrate  

Size  

Split  

Grooming   Team  Spec    Review  

Sprint  Planning  

Sprint  Backlog  

Sprint  

Sprint  Release  

Sprint  Review  

Sprint  Retro  

20  

BDD

“Behavior-Driven Development is about implementing an application by describing its behavior from the perspective of its stakeholders.”

-David Chelimsky

21  

Executing Scenarios

• Scenarios are the best acceptance tests •  Automatically provides traceability •  Minimal extra effort building the acceptance test suite

Requirements  Specifica;on  

Acceptance  Test  

User  Story  

Scenario  Executes  

22  

From Scenarios to Acceptance Tests

Scenarios  User  Story  

Scenarios  User  Story  

Scenarios  User  Story  

Epic  or  Feature  

Epic  or  Feature  

Internal  DSL  

Steps  

Steps  

Steps  

BDD  Fram

ework  

Domain  Model  

Automa;on  Framework  U;lity

 Metho

ds  

Network/Internet  

dB  

SUT  

23  

Popular BDD Automation Frameworks

• Cucumber - Best for Ruby •  JBehave - Best for Java • SpecFlow - Best for .NET

24  

JBehave Story Mapping

25  

BDD For Scrum Teams With Dev & QA

Developers  

QA  Engineers  

Product  Owner  

SnT1  –  Automate  Key  Scenarios  SnT2  –  Implement  Feature  SnT3  –  Fix  Cri;cal/Blocker  Bugs,  Create                          Release  off  CI  System,  Release  Notes,  etc    

SnT1  –  Plan  exploratory  tes;ng,  Finalize  extended                            Scenarios  with  the  Product  Owner  SnT2  –  Automate  extended  Scenarios  SnT3  –  Verify  test  results  and  accept  the  release,                              Exploratory  Tes;ng,  Bug  repor;ng,  Release                          packaging,  etc    

T1    (  2-­‐3  days  )   T2      (5-­‐10  days  )   T3    (2-­‐3  days  )  

T1    (  2-­‐3  days  )   T2      (5-­‐10  days  )   T3    (2-­‐3  days  )  

Sn  

Sn+1  

Rank  

Illustrate  

Size  

Split  

Grooming   Team  Spec    Review  

Sprint  Planning  

Sprint  Backlog  

Sprint  

Sprint  Release  

Thank You!