BDD for Agile Teams

Introduction to BDD

• What is the problem BDD is trying to solve
• Imagine you had to do the same project all over again!
• Creating software is a learning exercise
• BDD’s objectives and benefits
• What BDD is not
• Origins of BDD
• BDD’s tool set
• Overview of BDD
• Benefits of “living documentation”

BDD discovery driven by examples

• Example-driven Product Backlog Refinement BDD style
• BDD discovery is based on concrete examples
• BDD-style examples
• What does a good example look like?

Facilitation of BDD discovery workshops

• Facilitation of BDD discovery workshops with an explorative mindset
• Facilitation of 3-amigo workshops
• Facilitation of Example Mapping workshops
• Practicing Example Mapping
• Facilitation of Feature Mapping workshops
• Practicing Feature Mapping

Formulation of executable specifications with Gherkin

• Introduction to the automatable specification language Gherkin
• How to formulate an example as a Gherkin scenario
• Improving the readability of Gherkin scenarios
• Practice writing a complete Gherkin scenario

Writing good scenarios

• BDD’s underlying principles for writing scenarios
• BRIEF scenarios
• Business Language
• Real Data
• Essential
• Intention Revealing
• Focused and Brief
• When not to use BRIEF scenarios

Organizing scenarios in Feature files 

• Purpose of  Feature files
• Enhance Feature files with descriptions
• How to specify a business rule
• Organizing Feature files for the documentation

Advanced Gherkin syntax for more readable scenarios

• Data Tables in individual steps
• Tables of examples
• The Background keyword

Integrating the BDD practices into a Sprint

• Map BDD practices to Scrum events
• BDD activities during Product Backlog Refinement
• BDD activities during Sprint Planning
• BDD activities during the Sprint
• BDD activities during Daily Scrum
• BDD activities during Sprint Review
• BDD activities during Sprint Retrospective

• Product Owners who can improve the effectiveness of Product Backlog Refinements sessions 
  
  
• Business Analysts who contribute by helping translate requirements into executable specifications that both developers and business stakeholders can read
  
  
• Testers who contribute by discussing the testability and edge cases of requirements and can learn how to implement automated acceptance tests as a safety net
  
  
• Developers contribute by focusing their coding effort by developing towards specific outcomes and acceptance criteria.