Dev Day
0 likes•212 views
This document discusses using executable specifications with Scrum. It covers defining requirements as user stories with scenarios to remove ambiguity. Scenarios are used as acceptance tests that are automated using a behavior-driven development framework. This allows requirements to be executed as part of the development process and for acceptance testing. The document provides examples of user stories, scenarios, and how they map to automated tests in a BDD framework to support Scrum teams.
![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](https://image.slidesharecdn.com/29a38938-79c5-4f2e-80cd-9a893b823053-150626071716-lva1-app6891/85/Dev-Day-15-320.jpg)
Dev Day
- 1. Executable Specifications With Scrum Aruna Dissanayake
- 2. 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. 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. 4 Uncertainty Matrix Low Low High High Uncertainty of “What” Uncertainty of “How” Traditional R&D Agile Chaos
- 5. 5 Requirements Design Verifica;on Implementa;on Design Spec Test Spec Req. Spec Traditional Requirements
- 6. 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. 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. 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. 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 WhatWho Why
- 10. 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. 11 Focusing on Value Feature Usage Frequency (A Standish Group Study)
- 12. 12 Backlog Grooming Rank Illustrate Size Split Value/Priority Sprint Backlog
- 13. 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. 14 Scenarios Current State Expected State Precondi;ons Ac;on Consequences Given When Then
- 15. 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. 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. 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. 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. 19 Putting All Together Rank Illustrate Size Split Grooming Team Spec Review Sprint Planning Sprint Backlog Sprint Sprint Release Sprint Review Sprint Retro
- 20. 20 BDD “Behavior-Driven Development is about implementing an application by describing its behavior from the perspective of its stakeholders.” -David Chelimsky
- 21. 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. 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 Framework Domain Model Automa;on Framework U;lity Methods Network/ Internet dB SUT
- 23. 23 Popular BDD Automation Frameworks • Cucumber - Best for Ruby • JBehave - Best for Java • SpecFlow - Best for .NET
- 24. 24 JBehave Story Mapping
- 25. 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
- 26. Thank You!