given/when/then-ready sprint planning (agile tour vienna 2015)

Gáspár Nagycoach • trainer • bdd addict • creator of specflow

@gasparnagy • [email protected]



Given/When/Then-ready sprint planningAgile Tour Vienna • 21/11/2015

Copyright © Gaspar NagyCopyright © Gaspar Nagy

specsolutions.eu/bddaddict

bdd addict

given.when.then

CAUTION!

on stage


What is BDD?


An Oversimplified BDD Process

Scenario: Books can be added to the shopping basket

Given the following books

| Author | Title |

| Martin Fowler | Analysis Patterns |

| Gojko Adzic | Bridging the Communication Gap |

And my shopping basket is empty

When I add the book “Analysis Patterns” to my shopping basket

Then my shopping basket should contain 1 copy of “Analysis Patterns”


The Feature File

Scenario: Books can be added to the shopping basket

Given the following books

| Author | Title |

| Martin Fowler | Analysis Patterns |

| Gojko Adzic | Bridging the Communication Gap |

And my shopping basket is empty

When I add the book “Analysis Patterns” to my shopping basket

Then my shopping basket should contain 1 copy of “Analysis Patterns”

Who writes the

scenarios?How do you

set the title of

the scenario?

Can I have multiple

when/then steps?


If you have these questions you are probably on the wrong track…


The Sprint Planning


Demo: Planning the Pizza Selection Story


Explain the story as a PO


Let’s write a Gherkin from the result

Scenario: ...

Given ...

When ...

Then ...


De-briefing

• PO was unprepared

• We discussed the topics in a foreign language

• The domain was known, but not very exact

• Quality of notes?

• How easy it to write the first scenario?

• Quality of scenario?


An efficient meeting…


Demo: Planning the Pizza Selection Story


Participate in the facilitated discussion as PO


How It's Made


Well guided planning meeting can improve the “BDD-efficiency” quite much

• Someone needs to facilitate the discussion – not the PO

• The facilitation can be rotated so that everyone gets practice

• The facilitator can guide the discussion with• Asking questions

• Moderating (stopping?) discussions

• Everyone can ask of course…


#1 – Pick a guide line

• Choose a theme that you can use to order the questions

• The “sequence of actions” is usually good• ie. “What you do first?”

• If you use story mapping for planning the stories, this comes quite naturally


#2 – Keep collecting acceptance criteria

• Once you hear an important rule/behavior/check, note it down as an acceptance criterion

• Don’t forget that AC is not necessarily text, but formulas, wireframes or anything that describes the required behavior


#3 – Make notes visible to everyone

• Writing them up to the whiteboard can work well

• Using (and sharing on projector) a notepad, OneNote or SpecLog is also very good

• Pro: stored already in a searchable form, usually better visible (zoom), easy to go back to earlier notes

• Con: harder to get a full overview

• Stop the discussion while the AC is captured

• The team should have an agreement on the captured result• Was this really what we were discussing about?


#4 – Collect examples

• Ask for examples if not provided

• Examples can help • understanding the topic

• discover misunderstandings

• keep the requirements real

• Discover more: Specification by Example, Example mapping


#5 – Write a glossary

• As a facilitator, keep watching the domain terms and their usage

• Highlight if they are used inconsistently

• Suggest choosing a term• “Why don’t we give this a name?”

• The terms can be just highlighted in the notes, but you can also build up a glossary as the discussion goes

• Discover more: Domain Driven Design


+1 – Formulate the scenarios in Gherkin

• Not necessarily in the planning meeting

• Just before you start implementing the story works usually

• Don’t do it alone

• Try to find broader agreement especially for the first scenarios in a certain topic

• At this point, you are not discussing the behavior, but finalizing the ubiquitous language

• Discover more: Three Amigos


One page summary

#1 – Pick a guide line

#2 – Keep collecting acceptance criteria

#3 – Make notes visible to everyone

#4 – Collect examples

#5 – Write a glossary


What about my answers?

Who writes the

scenarios?

How do you

set the title of

the scenario?

Can I have multiple

when/then steps?


The answers

• Who writes the scenarios?• It does not matter, because we are all on the same page regarding the behavior. But it

makes sense if a developer is typing it in with a tester or PO sitting next to him/her.

• How do you set the title of the scenario?• You never set it, you start from the acceptance criterion that will be the title.

• Can I have multiple when/then steps?• The scenario is the formalization of an AC – a simple check. For that you usually

need only one when step and only one or two then steps.


Try is at home!





Thank you!


specsolutions.eu/bddaddict

bdd addict

given.when.then

CAUTION!

on the loose

given/when/then-ready sprint planning (agile tour vienna 2015)

Software