SlideShare a Scribd company logo
1 of 114
Liz Keogh
@lunivore
Behaviour-Driven Development
Feature Injection
Cynefin and Differentiation
Splitting Stories
An Example of an Example
Given Fred has bought a microwave
And the microwave cost £100
When we refund the microwave
Then Fred should be refunded £100.
An Example of an Example
Given baby rabbits cost £10
When we sell Snowy the Baby Rabbit
Then the customer should be charged £10.
Examples
Given a context
When an event happens
Then an outcome should occur
“Given Scenario” – an antipattern
Given Fred puts a microwave in the basket
And the microwave cost £100
When Fred buys the microwave
Then he should be charged £100
When we refund the microwave
Then Fred should be refunded £100.
Cucumber
Feature: Addition
In order to avoid silly mistakes
As a math idiot
I want to be told the sum of two numbers
Scenario: Add two numbers
Given I have entered 50 into the calculator
And I have entered 70 into the calculator
When I press add
Then the result should be 120 on the screen
This is what most people
associate with BDD
BDD is about having conversations
BDD should make it easy
to create software
A scenario is an idea, not a promise
A scenario is an idea, not a promise
Having conversations
Exercise
Think of the
best conversations
you’ve had.
What made them awesome?
Questions
Uncertainty
IdeasSupport
Boring!
Given Fred bought a microwave
And has receipt number 1857123
And receipt 1857123 lists it at £100
When we scan the receipt
Then the screen should show the list of items
When we select the microwave
And we refund it
And scan Fred’s credit card
Then Fred should be refunded £100.
Examples
Given a context
When an event happens
Then an outcome should occur
Make sure you get it right
Assume you got it wrong
Is there a context in which
this event will create
a different outcome?
Examples
Given Fred has bought a microwave
And the microwave cost £100
And the microwave was on 10% discount
When we refund the microwave
Then Fred should be refunded £90.
Examples
Given Fluffy the baby rabbit
is 1 ½ months old
When we try to sell Fluffy
Then we should be told he’s too young
Is this the only outcome
that matters?
If we could achieve it with pixies,
would it be enough?
Examples
Given Fred has bought a microwave
And the microwave cost £100
When we refund the microwave
Then the microwave should be
added to the stock count.
Examples
Given each rabbit eats an average of
20g of carrots a day
When we sell 10 rabbits
And 5 rabbits are born
Then our order for carrots should
go down by 700g a week
Same scenario?
Then Fred should be refunded £100
Then the microwave should be added
to the stock count
Same scenario?
Then I should be given £20
And £20 should be debited
from my account
Then my eyes glaze over…
When we select “baby rabbit” from the list of pets
And the customer declines all special offers
And we want a VAT receipt
And we select payment by credit card
And the customer is present
Then the receipt should say £10
And we should have £10 more takings
And the number of rabbits in stock should
decrease
And …
Then my eyes glaze over more
When we click the “Pets” drop-down
And we select “baby rabbits”
And we click “No”
And we check “VAT receipt”
And we click “Pay”
And we select “Credit Card”
And we click “Yes”
And …
Exercise
Come up with
two scenarios
with
two outcomes
from your own work,
one of which can be split
and one of which can’t.
(They don’t have to be about software)
And you can keep going…
Given Fred has bought a microwave
And the microwave cost £100
And the microwave is faulty
When we refund the microwave
Then a fault ticket should be printed.
Exercise
What other benefits
can you think of
that might come from
talking through
different scenarios?
Acceptance criteria vs. Scenarios
Given Fred has bought a microwave
And the microwave cost £100
And the microwave was on 10% discount
When we refund the microwave
Then Fred should be refunded £90.
Acceptance criteria vs. Scenarios
Given an item was sold
with a discount
When a customer gets a refund
Then he should only be refunded
the discounted price.
Acceptance criteria vs. Scenarios
Items should be refunded
at the price at which they were sold.
Acceptance criteria vs. Scenarios
Given Fluffy the baby rabbit
is 1 ½ months old
When we try to sell
Fluffy the baby rabbit
Then we should be told
that he’s too young
Acceptance criteria vs. Scenarios
Given a pet is below
recommended selling age
When we try to sell
that pet
Then we should be told
that the pet is too young
Acceptance criteria vs. Scenarios
We shouldn’t be able
to sell pets
younger than the
recommended
selling age
Exercise
Can you derive some scenarios
from these acceptance criteria?
The user should be able to add and remove bold,
italics and underlines.
When browsing an item, users should be able to see
what other users who browsed the item bought.
Pets shouldn’t be listed for sale
until they’re old enough.
Vision
Makes money
Saves money
Protects money
Goal
Needed
to go liveIncidental
Stake-
holder
Capability
Users
can achieve
a business
outcome
Feature
User interface
component
which enables
a capability
Story
A slice through
a feature
to enable
faster feedback
Scenario
An example
of how the system
might behave
from a user
perspective
Code
Ideas turning into
realityDeveloper
Vision
Goal
Capability
Feature
Story
Scenario
Code
Vision
Goal
Capability
Feature
Story
Scenario
Code
Capability
Vision
Goal
Capability
Feature
Story
Scenario
Code
Scenario
Exercise
Who are your stakeholders?
Is there a stakeholder for whom
this application will
not meet their goal?
Are all of the stakeholder’s goals
met by this?
If we could achieve it with pixies,
would it be enough?
Traditional
Rework
Developers Testers
Deliberate Discovery skills
BDD
Less Rework
Developers Testers
Deliberate Discovery skills
Testers
Real Options
Options have value.
Options expire.
Never commit early
unless you know why.
Developer
The Big Bucket
A Gantt Chart…
1 1 1
3 3
2 2
1
2
3
1
1
1
3
3
2
2
…on its side
Backlog
1
1
1
3
3
2
2
If a project has
no risks,
don’t do it.
Prioritizing for deadline
$$$$$$$$
$$$$$$$$
$$$$$$$$
$$$$$
$$$$$
$$
$$
$$
Shipped (1 year)
Not Shipped
Deadline
Minimum Viable Product
$$$$$$$$
$$$$$$$$
$$$$$$$$
$$$$$
$$$$$
$$
$$
$$
Shipped (2 months)
Not Shipped
Not Shipped
Shipped (2 months)
Types of Software
Differentiators
Commodities
KatasExpedite
Types of Software
Spoilers
Cynefin
Simple
ComplicatedComplex
Chaotic
With thanks to
David Snowden and Cognitive Edge
Cynefin
With thanks to
David Snowden and Cognitive Edge
Disorder
Cynefin
SimpleChaotic
With thanks to
David Snowden and Cognitive Edge
Cynefin
Breaking
things
down
Cynefin
Trying
things
out
BDD works really well…
…hereish.
Exercise
Help me
stop the spammers!
Fractal beauty
Vision
Goal
Goal
Goal
Capability
Capability
Feature
Feature
Feature
Story
Story
Story
Scenario
Scenario
Code
Code
Code
Goal
Scenario
Goal
Feature
A Real Project
Vision
Goal
Capability
Capability
Feature
Feature
Story
Story
Story
Scenario
Code
Code
Code
Whoops,
forgot
Oops, didn’t
know about
that…
Look what I
found!
Don’t need
this… Can’t
remember
what this
was for…
Goal
Scenario
Goal
Feature
A Real Project
Vision
Goal
Capability
Capability
Feature
Feature
Story
Story
Story
Scenario
Code
Code
Code
Whoops,
forgot
Oops, didn’t
know about
that…
Look what I
found!
Don’t need
this… Can’t
remember
what this
was for…
Um
Er…
Oh!
Oh F…
Dammit!
Hmm!
That’s
funny!
Ooh, look!
Interesting! Sh..!
Oops!
We’re uncovering better ways of
developing software by doing it
Vision
Goal
Goal
Goal
Capability
Capability
Feature
Feature
Feature
Story
Story
Story
Scenario
Scenario
Code
Code
Code
We’re discovering how to
discover stuff by doing it
Whoops,
forgot
Oops, didn’t
know about
that…
Look what I
found!
Don’t need
this…
Can’t
remember
what this
was for…
Um…
Er…
Oh!
Oh F…
Dammit!
Hmm!
That’s
funny!
Ooh, look!
Interesting!
Sh..!
Oops!
Different levels of granularity
Risk (Newest Stuff) First
Vision
Goal
Goal
Goal
Capability
Capability
Feature
Feature
Feature
Story
Story
Story
Scenario
Scenario
Code
Code
Code
Feature
Goal
Capability
Scenario
Code
Story
High-level, risk-first
High-level, risk-first
Exercise
What should your board
look like now?
Boring!
Given Fred has bought a microwave
And the microwave cost £100
When we refund the microwave
Then Fred should be refunded £100.
Interesting!
Given Fred has bought a
120kg fridge-freezer
When we refund the fridge-freezer
Then um…
Exercise
Can you derive a more interesting scenario
from these acceptance criteria?
The user should be able to add and remove bold,
italics and underlines.
When browsing an item, users should be able to see
what other users who browsed the item bought.
Pets shouldn’t be listed for sale
until they’re old enough.
Fred Buyer
999 Letsby Avenue
London
N1 0UC
By Spiking
Fred
Buyer
Save
New
Stabilizing
Walking Skeleton
Walking Skeleton
By Input
By Output
By Behaviour
With thanks to
Michael James
Having conversations
Liz Keogh
http://lizkeogh.com
@lunivore

More Related Content

What's hot

Agile presentation
Agile presentationAgile presentation
Agile presentation
infolock
 

What's hot (20)

Another Scrum Cheat Sheet (great one pager)
Another Scrum Cheat Sheet (great one pager)Another Scrum Cheat Sheet (great one pager)
Another Scrum Cheat Sheet (great one pager)
 
User Story Workshop
User Story WorkshopUser Story Workshop
User Story Workshop
 
BDD with Cucumber
BDD with CucumberBDD with Cucumber
BDD with Cucumber
 
BDD WITH CUCUMBER AND JAVA
BDD WITH CUCUMBER AND JAVABDD WITH CUCUMBER AND JAVA
BDD WITH CUCUMBER AND JAVA
 
Strategies to split user stories
Strategies to split user storiesStrategies to split user stories
Strategies to split user stories
 
Definition of Ready (XP2011)
Definition of Ready (XP2011)Definition of Ready (XP2011)
Definition of Ready (XP2011)
 
Successfully Implementing BDD in an Agile World
Successfully Implementing BDD in an Agile WorldSuccessfully Implementing BDD in an Agile World
Successfully Implementing BDD in an Agile World
 
User Story Mapping
User Story MappingUser Story Mapping
User Story Mapping
 
User Stories
User StoriesUser Stories
User Stories
 
Agile Overview
Agile OverviewAgile Overview
Agile Overview
 
User Story Mapping Workshop (Design Skills 2016)
User Story Mapping Workshop (Design Skills 2016)User Story Mapping Workshop (Design Skills 2016)
User Story Mapping Workshop (Design Skills 2016)
 
Scrum - Requirements and User Stories
Scrum - Requirements and User StoriesScrum - Requirements and User Stories
Scrum - Requirements and User Stories
 
Cucumber & gherkin language
Cucumber & gherkin languageCucumber & gherkin language
Cucumber & gherkin language
 
5 Whys of Scrum
5 Whys of Scrum5 Whys of Scrum
5 Whys of Scrum
 
AGILE METHODOLOGY
AGILE METHODOLOGYAGILE METHODOLOGY
AGILE METHODOLOGY
 
Scrum 101
Scrum 101Scrum 101
Scrum 101
 
Certified Scrum Product Owner: class desk, posters and photos
Certified Scrum Product Owner: class desk, posters and photosCertified Scrum Product Owner: class desk, posters and photos
Certified Scrum Product Owner: class desk, posters and photos
 
User Story Maps: Secrets for Better Backlogs and Planning
 User Story Maps: Secrets for Better Backlogs and Planning User Story Maps: Secrets for Better Backlogs and Planning
User Story Maps: Secrets for Better Backlogs and Planning
 
Agile presentation
Agile presentationAgile presentation
Agile presentation
 
Agile-overview: Agile Manifesto, Agile principles and Agile Methodologies
Agile-overview: Agile Manifesto, Agile principles and Agile MethodologiesAgile-overview: Agile Manifesto, Agile principles and Agile Methodologies
Agile-overview: Agile Manifesto, Agile principles and Agile Methodologies
 

Similar to Behavior Driven Development

Energy-Wise Renovations
Energy-Wise RenovationsEnergy-Wise Renovations
Energy-Wise Renovations
ccseerc
 
Exploring the Essence of Mark-on,Mark-down and Mark-up.
Exploring the Essence of Mark-on,Mark-down and Mark-up.Exploring the Essence of Mark-on,Mark-down and Mark-up.
Exploring the Essence of Mark-on,Mark-down and Mark-up.
Unfooledbyu
 
Maths A - Chapter 3
Maths A - Chapter 3Maths A - Chapter 3
Maths A - Chapter 3
westy67968
 
Presentation the-business-pi-ppt-unit-5
Presentation the-business-pi-ppt-unit-5Presentation the-business-pi-ppt-unit-5
Presentation the-business-pi-ppt-unit-5
digitalfen
 

Similar to Behavior Driven Development (20)

Bdd for Life
Bdd for LifeBdd for Life
Bdd for Life
 
Behaviour Driven Development by Liz Keogh
Behaviour Driven Development by Liz KeoghBehaviour Driven Development by Liz Keogh
Behaviour Driven Development by Liz Keogh
 
Bdd: a bit of an experiment
Bdd: a bit of an experimentBdd: a bit of an experiment
Bdd: a bit of an experiment
 
Modelling by Example Workshop - PHPNW 2016
Modelling by Example Workshop - PHPNW 2016Modelling by Example Workshop - PHPNW 2016
Modelling by Example Workshop - PHPNW 2016
 
Week 6 - Media Negotiation
Week 6 - Media NegotiationWeek 6 - Media Negotiation
Week 6 - Media Negotiation
 
Innovation - Bootstrapping New Product Development (without betting the farm)
Innovation - Bootstrapping New Product Development (without betting the farm)Innovation - Bootstrapping New Product Development (without betting the farm)
Innovation - Bootstrapping New Product Development (without betting the farm)
 
From the book: 50 Proven Ways to Be Persuasive
From the book: 50 Proven Ways to Be PersuasiveFrom the book: 50 Proven Ways to Be Persuasive
From the book: 50 Proven Ways to Be Persuasive
 
CYCLES Course (4): Communication and Check
CYCLES Course (4): Communication and CheckCYCLES Course (4): Communication and Check
CYCLES Course (4): Communication and Check
 
MONEY SAVING TIPS
MONEY SAVING TIPSMONEY SAVING TIPS
MONEY SAVING TIPS
 
Energy-Wise Renovations
Energy-Wise RenovationsEnergy-Wise Renovations
Energy-Wise Renovations
 
The Analysis of Consumer Choice
The Analysis of Consumer ChoiceThe Analysis of Consumer Choice
The Analysis of Consumer Choice
 
So you have a product idea?
So you have a product idea?So you have a product idea?
So you have a product idea?
 
Exploring the Essence of Mark-on,Mark-down and Mark-up.
Exploring the Essence of Mark-on,Mark-down and Mark-up.Exploring the Essence of Mark-on,Mark-down and Mark-up.
Exploring the Essence of Mark-on,Mark-down and Mark-up.
 
Maths A - Chapter 3
Maths A - Chapter 3Maths A - Chapter 3
Maths A - Chapter 3
 
Math 6 - Application of Percent (Commission, Simple Interest, Percent of Incr...
Math 6 - Application of Percent (Commission, Simple Interest, Percent of Incr...Math 6 - Application of Percent (Commission, Simple Interest, Percent of Incr...
Math 6 - Application of Percent (Commission, Simple Interest, Percent of Incr...
 
Moving away from legacy code (AgileCymru)
Moving away from legacy code  (AgileCymru)Moving away from legacy code  (AgileCymru)
Moving away from legacy code (AgileCymru)
 
The Million Dollar Case Study - Outreach to Suppliers
The Million Dollar Case Study - Outreach to SuppliersThe Million Dollar Case Study - Outreach to Suppliers
The Million Dollar Case Study - Outreach to Suppliers
 
Applied Data Science for monetization: pitfalls, common misconceptions, and n...
Applied Data Science for monetization: pitfalls, common misconceptions, and n...Applied Data Science for monetization: pitfalls, common misconceptions, and n...
Applied Data Science for monetization: pitfalls, common misconceptions, and n...
 
Presentation the-business-pi-ppt-unit-5
Presentation the-business-pi-ppt-unit-5Presentation the-business-pi-ppt-unit-5
Presentation the-business-pi-ppt-unit-5
 
Haven
HavenHaven
Haven
 

More from Liz Keogh (8)

The Lego Kanban Game
The Lego Kanban GameThe Lego Kanban Game
The Lego Kanban Game
 
TDD All the Things!
TDD All the Things!TDD All the Things!
TDD All the Things!
 
Retrospectives
RetrospectivesRetrospectives
Retrospectives
 
The feedback workshop
The feedback workshopThe feedback workshop
The feedback workshop
 
Organic, not chaotic
Organic, not chaoticOrganic, not chaotic
Organic, not chaotic
 
How to test the inside of your head
How to test the inside of your headHow to test the inside of your head
How to test the inside of your head
 
The 100k proposition
The 100k propositionThe 100k proposition
The 100k proposition
 
Agile101
Agile101Agile101
Agile101
 

Recently uploaded

Future Visions: Predictions to Guide and Time Tech Innovation, Peter Udo Diehl
Future Visions: Predictions to Guide and Time Tech Innovation, Peter Udo DiehlFuture Visions: Predictions to Guide and Time Tech Innovation, Peter Udo Diehl
Future Visions: Predictions to Guide and Time Tech Innovation, Peter Udo Diehl
Peter Udo Diehl
 

Recently uploaded (20)

Optimizing NoSQL Performance Through Observability
Optimizing NoSQL Performance Through ObservabilityOptimizing NoSQL Performance Through Observability
Optimizing NoSQL Performance Through Observability
 
The Metaverse: Are We There Yet?
The  Metaverse:    Are   We  There  Yet?The  Metaverse:    Are   We  There  Yet?
The Metaverse: Are We There Yet?
 
WSO2CONMay2024OpenSourceConferenceDebrief.pptx
WSO2CONMay2024OpenSourceConferenceDebrief.pptxWSO2CONMay2024OpenSourceConferenceDebrief.pptx
WSO2CONMay2024OpenSourceConferenceDebrief.pptx
 
Google I/O Extended 2024 Warsaw
Google I/O Extended 2024 WarsawGoogle I/O Extended 2024 Warsaw
Google I/O Extended 2024 Warsaw
 
Introduction to FDO and How It works Applications _ Richard at FIDO Alliance.pdf
Introduction to FDO and How It works Applications _ Richard at FIDO Alliance.pdfIntroduction to FDO and How It works Applications _ Richard at FIDO Alliance.pdf
Introduction to FDO and How It works Applications _ Richard at FIDO Alliance.pdf
 
Linux Foundation Edge _ Overview of FDO Software Components _ Randy at Intel.pdf
Linux Foundation Edge _ Overview of FDO Software Components _ Randy at Intel.pdfLinux Foundation Edge _ Overview of FDO Software Components _ Randy at Intel.pdf
Linux Foundation Edge _ Overview of FDO Software Components _ Randy at Intel.pdf
 
Syngulon - Selection technology May 2024.pdf
Syngulon - Selection technology May 2024.pdfSyngulon - Selection technology May 2024.pdf
Syngulon - Selection technology May 2024.pdf
 
TEST BANK For, Information Technology Project Management 9th Edition Kathy Sc...
TEST BANK For, Information Technology Project Management 9th Edition Kathy Sc...TEST BANK For, Information Technology Project Management 9th Edition Kathy Sc...
TEST BANK For, Information Technology Project Management 9th Edition Kathy Sc...
 
Simplified FDO Manufacturing Flow with TPMs _ Liam at Infineon.pdf
Simplified FDO Manufacturing Flow with TPMs _ Liam at Infineon.pdfSimplified FDO Manufacturing Flow with TPMs _ Liam at Infineon.pdf
Simplified FDO Manufacturing Flow with TPMs _ Liam at Infineon.pdf
 
AI presentation and introduction - Retrieval Augmented Generation RAG 101
AI presentation and introduction - Retrieval Augmented Generation RAG 101AI presentation and introduction - Retrieval Augmented Generation RAG 101
AI presentation and introduction - Retrieval Augmented Generation RAG 101
 
Integrating Telephony Systems with Salesforce: Insights and Considerations, B...
Integrating Telephony Systems with Salesforce: Insights and Considerations, B...Integrating Telephony Systems with Salesforce: Insights and Considerations, B...
Integrating Telephony Systems with Salesforce: Insights and Considerations, B...
 
ECS 2024 Teams Premium - Pretty Secure
ECS 2024   Teams Premium - Pretty SecureECS 2024   Teams Premium - Pretty Secure
ECS 2024 Teams Premium - Pretty Secure
 
Connecting the Dots in Product Design at KAYAK
Connecting the Dots in Product Design at KAYAKConnecting the Dots in Product Design at KAYAK
Connecting the Dots in Product Design at KAYAK
 
Enterprise Knowledge Graphs - Data Summit 2024
Enterprise Knowledge Graphs - Data Summit 2024Enterprise Knowledge Graphs - Data Summit 2024
Enterprise Knowledge Graphs - Data Summit 2024
 
What's New in Teams Calling, Meetings and Devices April 2024
What's New in Teams Calling, Meetings and Devices April 2024What's New in Teams Calling, Meetings and Devices April 2024
What's New in Teams Calling, Meetings and Devices April 2024
 
THE BEST IPTV in GERMANY for 2024: IPTVreel
THE BEST IPTV in  GERMANY for 2024: IPTVreelTHE BEST IPTV in  GERMANY for 2024: IPTVreel
THE BEST IPTV in GERMANY for 2024: IPTVreel
 
ASRock Industrial FDO Solutions in Action for Industrial Edge AI _ Kenny at A...
ASRock Industrial FDO Solutions in Action for Industrial Edge AI _ Kenny at A...ASRock Industrial FDO Solutions in Action for Industrial Edge AI _ Kenny at A...
ASRock Industrial FDO Solutions in Action for Industrial Edge AI _ Kenny at A...
 
Future Visions: Predictions to Guide and Time Tech Innovation, Peter Udo Diehl
Future Visions: Predictions to Guide and Time Tech Innovation, Peter Udo DiehlFuture Visions: Predictions to Guide and Time Tech Innovation, Peter Udo Diehl
Future Visions: Predictions to Guide and Time Tech Innovation, Peter Udo Diehl
 
The UX of Automation by AJ King, Senior UX Researcher, Ocado
The UX of Automation by AJ King, Senior UX Researcher, OcadoThe UX of Automation by AJ King, Senior UX Researcher, Ocado
The UX of Automation by AJ King, Senior UX Researcher, Ocado
 
Strategic AI Integration in Engineering Teams
Strategic AI Integration in Engineering TeamsStrategic AI Integration in Engineering Teams
Strategic AI Integration in Engineering Teams
 

Behavior Driven Development

Editor's Notes

  1. Given, When and Then are the key bits here. Using “and” or “but” signifies that the step is the same type as the previous one.
  2. Given, When and Then are the key bits here. Using “and” or “but” signifies that the step is the same type as the previous one.
  3. This is actually two scenarios.The first scenario is concerned with payments. The second scenario is concerned with refunds. The first scenario is setting up the context for the second scenario.Talking through scenarios like this is absolutely fine. If you capture them, you might want to separate the two scenarios. As we’ll see later when we start looking for different outcomes and more interesting scenarios, once things start getting complicated these scenarios can be hard to maintain.Usually, if you see this, you’ll find there are either two different concerns in play, or that one of the scenarios is redundant.
  4. There are tools available which will take your English-language steps and turn them into real automated regression tests! Cucumber, Cucumber for the JVM, SpecFlow and JBehave are all examples of system-level BDD tools. There are others which run against smaller elements of code or classes, such as RSpec and MSpec, but you don’t have to worry about those unless you’re a developer.
  5. However, the conversations are the most important bit, so start with those.
  6. Remember that the point of BDD is to create working software. If you find that it’s getting in the way of that, you’re probably focusing too much on the process, and too little on the goal.
  7. A lot of teams that use BDD insist on having very clear examples for everything they attempt. As we’ll see later, some things resist well-defined outcomes, especially when they’re very new or innovative. BDD should be a collaboration tool, not a contractual one; it’s about trying to understand what the business want, not making it “their fault” if we end up producing the wrong thing.
  8. We should always be looking for what we want next, or what we’ve got wrong, or what we could do differently.
  9. These were some of the ideas I came up with. Others might be relevance, unexpectedness and surprise, being funny… these can all come into your scenarios, too. Make them memorable.How many people said, “These are things I value in conversations…” and started listing them, and how many shared stories of conversations they’d had? We are “homo narrans”; we learn best from stories.
  10. When I spoke to the Head of Client Management, I said, “Given a client manager has some clients, when he logs in, then he should see his clients. Given he has no clients, what should he see when he logs in then?” I was thinking about the case when they had an empty list of clients.But the Head of Client Management said, “If you’re a client manager and you have no clients, I’m about to fire you! Get on the phone and get some clients!”From my dev perspective, I was worried about empty lists. From his perspective, an empty list was a business about to be bankrupted. So that taught me quite a bit about the domain!
  11. If you find yourself talking in ways that seem unnatural, you’re probably thinking too hard about the solution, rather than the problem. This is a very solution-focused scenario. Also try and avoid any reference to the UI, as that’s part of the solution space too.
  12. “Should” is a magic word that allows us to question whether an example really should happen.
  13. Should it happen now, or should it happen later? Or at all? Should it always happen? Is there a context in which it doesn’t happen?
  14. This is the pattern I call “context questioning”.
  15. This is the pattern I call “outcome questioning”.A pixie is a small person. If you’ve ever read Terry Pratchett’s “Discworld” novels, you’ll know that when you take a photo in the Discworld, a little goblin or person inside the camera quickly paints the picture for you! I sometimes find it helpful to imagine that there are similar tiny people inside all of our machines, painting on the inside of our computer monitors and sitting crouched in our cash machines.As a developer, I love writing code. I can’t help it! So as soon as you start talking to me about the problem, I start writing software in my head – moving to the solution space. If I can imagine that pixies are going to do the job instead, it makes it much easier to think about, and question, what the pixies should do, instead of the implementation of it.
  16. I also introduced the example of a cash machine. What else needs to happen if there’s a pixie in the machine giving me my £20? Oh, yes, it needs to debit the account! Now, we know that for a cash machine the two scenarios *cannot* be shipped separately. But for this, they probably can. So talking through scenarios can help you to decide what your scope is, too, as well as uncovering extra scope.
  17. I also introduced the example of a cash machine. What else needs to happen if there’s a pixie in the machine giving me my £20? Oh, yes, it needs to debit the account! Now, we know that for a cash machine the two scenarios *cannot* be shipped separately. But for this, they probably can. So talking through scenarios can help you to decide what your scope is, too, as well as uncovering extra scope.
  18. These are two separate aspects of behaviour, so you probably want to put them in different scenarios. It’s OK to get this wrong, though, and if someone comes up with an interesting outcome, it’s probably better just to capture it quickly. Remember that it’s more important to keep the conversation fluid and allow ideas to flow than to do it “right”.
  19. These are not two separate aspects of behaviour. This is one transaction. It needs to happen in the same scenario, because we can’t ship one without the other. That just isn’t useful.
  20. If you have a scenario that gets like this, you might want to start splitting it up. Nobody is really interested in talking about all these outcomes at once.
  21. This is even worse. Focusing on the GUI ties you to a particular GUI. If you ever have a search box instead of a drop down, this is going to be a maintenance nightmare. I can tell from this scenario that whoever wrote it hasn’t actually had any conversations with anyone!
  22. Transactional outcomes often have two different outcomes for two different stakeholders.Imagine paying someone money online. You want to have some kind of confirmation, don’t you? Would it be OK to pay the other person without getting that confirmation? Or get the confirmation when you haven’t paid? These kind of outcomes have to be shipped together.
  23. As you talk through different scenarios, you’ll find new requirements. If you’re after an MVP (Minimum Viable Product) – the smallest thing that you could usefully ship and make money from or learn from – then think about whether you really *need* to ship the scenario or not. For instance, you could usefully deploy a cash machine which doesn’t work for people who have overdrafts, and it will still cut the bank queues down.
  24. Another benefit we talked about is that developers start using the language in the code, so that they can talk more easily to the business and their code is easier to read and more maintainable.
  25. This is a scenario with specific data. We can’t tell from this what the actual rules are. It’s an exemplar; an example made to *illustrate* behaviour. It’s not really a description of the behaviour.
  26. This isn’t a scenario, even though it’s phrased as GWT. It’s acceptance criteria. It’s a description of the behaviour which is true for all the contexts mentioned… unless you can think of another context which changes this!
  27. We don’t need to phrase things as GWT if the scenarios can easily be derived.
  28. This isn’t a scenario, even though it’s phrased as GWT. It’s acceptance criteria. It gives us the rules for all pets, not just rabbits. If someone started with this, we could ask them, “Can you give us an example?” Using concrete examples with real baby rabbits entices our imaginations in a way that abstractions don’t. I bet you even have an image in your head of what colour Fluffy is too!
  29. There are multiple ways of phrasing acceptance criteria. If we can’t imagine scenarios from the criteria then we can create some to help illustrate the behaviour. It’s perfectly OK to capture obvious scenarios in this form – you don’t have to write *everything* down! The trick with BDD is to get to the things we’re discovering which are new as quickly as possible.
  30. When we talked through the examples, a lot of them read as acceptance criteria. I ask concrete questions like, “What’s his name? Can you think of an example of text that Fred might want to make bold? Can you think of an example of that?” Even just repeating “Can you give me an example of that?” usually helps reduce abstract acceptance criteria to something that really fires the imagination.
  31. When Chris Matts taught me Feature Injection, he explained it in much the way I explained it to you. However, he has some different emphasis that’s worth reading, and is strongly aligned with the later sections on differentiation. Here’s his article on it: http://www.infoq.com/articles/feature-injection-success
  32. There’s always someone who cares about the project; who has fought to get the budget for it, or perhaps funded it directly. This is the project owner. Everyone else is a proxy.
  33. As well as the project owner, there will be several other stakeholders whose needs have to be met in order to go live. Often these are “gatekeeping” stakeholders – security, support, audit, legal, etc. You can engage these stakeholders before-hand and get some tests for their goals.Tom Gilb is pretty big on quantifying goals. Here’s a good article on it: http://projectmanagement.atwork-network.com/2012/03/20/qa-tom-gilb-on-quantifying-project-objectives/You may also find my blog post on identifying stakeholders across the whole value stream useful: http://leansystemssociety.org/value-streams-are-made-of-people/
  34. To deliver the stakeholder goals, we look to see what capabilities are needed. A capability is “the capability to do something”. For instance:The capability to trade copperThe capability to book a holidayThe capability to comment on an articleThe capability to calculate counterparty exposureetc. We can also find smaller capabilities within larger ones if we need to. A 1-year, enterprise-wide project in a trading company we used this in had about 30 capabilities for the whole project, some of which were – in a rough estimate – 10 times smaller than others. Capabilities may also be principles that extend across the whole project (security, performance, etc.) They *all* have stakeholders, even the ones we refer to as “non-functional” or “technical”. Working out who the stakeholder for a requirement is, and phrasing it in terms of the business benefit, can really help to narrow down what actually *needs* to be delivered.
  35. Some capabilities will be delivered in the form of software features. There may be one or many features related to a capability. For instance, in order to comment on an article we may need user registration, comment reporting (in case of spam, vulgarity or libel), and the comment box itself.The features that we choose to implement may change frequently during a project, especially if the capabilities we’re delivering are new. Capabilities don’t change often, though, so one trick is to find the newest capabilities, and work out a way to get feedback on those quickly!More on that in the differentiation / Cynefin section.
  36. The reason we split features into stories is to get feedback and trust. Showing that you’ve delivered *something* that the stakeholders can see and play with is usually more valuable than trying to get a whole “complete vertical slice”. If there’s a way to show progress or get feedback more quickly, do that. Why code an entire slice if you can throw something smaller away?
  37. Scenarios can be used to help discover the scope of features and capabilities, and to split features into stories. If we can’t think of an example in which a capability or feature proves its value to the business, maybe it won’t…
  38. And finally, we get to code.
  39. And later on in this talk, I show why this doesn’t actually work as neatly as this diagram shows  But it’s a useful model to bear in mind for the moment.
  40. We focus on the capability wherever possible because it gives us options for changing the lower-level steps beneath. The features we use to deliver a stakeholders’ goals often change, but the capabilities the business needs to meet those goals rarely do.
  41. We focus on scenarios in BDD because it’s the place where the technical, problem-solving developers and the non-technical business analysts and problem-finding testers meet.
  42. Who are the stakeholders for your project?Are there any which are missing? Are there capabilities that are simply delivered as an industry standard? Do you actually need them?
  43. Remember the “context questioning” question? (Do you?)This is what it looks like when we apply it at the stakeholder level.
  44. This is what outcome questioning looks like (do you remember that?)We can also do this for the other levels. Is there some context in which this feature won’t be usable? Is there some market context in which we won’t make money with this?
  45. Testers are “whattabout” people. They ask, “What about this scenario? Or this one?”They can do this while devs are thinking about the solution, and analysts are trying to help them with it. This keeps us in the problem space for a bit longer, and helps us avoid that premature commitment. Conversations aren’t very expensive.
  46. Here’s how evil testers are. Adev once asked me, “Why do we need testers, if we’re doing automated testing and having conversations around scenarios?” So I wrote this on a napkin. “What’s in the middle?” I asked.
  47. “It’s a 3,” he said.“Put your tester hat on. What’s in the middle now?”
  48. “I don’t know,” he said. “I mean, it might be a 3. But if I’m a tester, I’ll ask.”“That’s why we need testers. Of course it’s a 3, but a tester thinks about what really ought to be there, and we devs just fill in the gaps.”Then I showed it to a *real* tester.
  49. “Might not be a 3,” the real tester said.Evil. Evil! And very, very, valuable.
  50. For most things in life, we have choices. We can pay to extend those choices. An option is the right, but not the obligation, to have something.Implementation is a commitment. If we implement before we’ve had a chat about something, we are probably investing in the wrong thing.Similarly, if we do too much analysis about something when trying something out would be the right thing to do, we’re probably investing in the wrong thing.Automation is also a commitment!BDD, done well, helps us find the right balance between conversation and prototype.
  51. If you don’t have actual testers, get someone to play that role. Someone who *isn’t* a dev. Us devs are very good at abstraction, and will start solving a problem before we see the whole problem. I don’t believe that an awesome dev can also be an awesome tester, or vice-versa.
  52. That’s just how you pronounce it. Cynefin is a way of making sense of problems, and working out what kind of problem you have (relatively; the boundaries are fuzzy). This is important because…
  53. This is how requirements have traditionally been gathered. Stakeholders are used to only having one chance to get everything they want, so they put in things that they think they *might* want. Even in Agile, we frequently have these Waterfall habits. How many projects have you been on where analysts or PMs spent time “grooming the backlog”?
  54. Traditionally, we tend to do the most valuable things first. This gives us milestones. We normally manage these with a Gantt chart! But we’re *Agile* now, so let’s slice things up into stories…
  55. …and then…
  56. Bingo! Our big bucket of requirements has become a backlog. Now, we can start with the most valuable features. But really, why are the others even in there? What do we actually *need* to do to release something valuable?What if one of those 1s was really valuable, and only needed a 2 or 3 to go with it to release it? Why would you do all of them?
  57. This is a great book to read. All projects have something new associated with them. If they don’t, get the experts in to do it (for instance, a SAP rollout).
  58. We normally do this because we think that a deadline is the risky part of the project. I find a lot of deadlines are purely political anyway. I don’t know about you, but I hate working weekends and evenings just so a PM can look cool because they got their project in “on time”!
  59. What if there was some aspect of the project that was differentiating? How little could we get away with doing just to get that one differentiating feature out of the door? Now we’re making money earlier, and if it turns out that our feature is too hard or it doesn’t rock the market, we haven’t invested huge amounts of money.
  60. The summary of the next few slides can be found here:http://lizkeogh.com/2012/03/11/cynefin-for-devs/http://en.wikipedia.org/wiki/CynefinAnd this article is worth the money IMO:http://hbr.org/2007/11/a-leaders-framework-for-decision-making/ar/1The short version: There are different kinds of software.There are some things we do which make our project different to other, similar projects. Even if the only thing we do different is that it’s meant to be maintainable, or we’re doing it in HTML5, or we’re doing it for this new customer with these few new requirements, there’s always a reason we do the project, and the reason is something that didn’t exist before. People have differentiators, projects have differentiators, and so do whole organisations!If we make a cameraphone for the first time, it also has to be able to make calls, receive calls and look up numbers, otherwise it’s just a camera. These are commoditised requirements.There are also some pieces of work that are urgent and unplanned – production bugs that we have to expedite, for instance.And lastly, we have katas – simple problems with very well understood outcomes, which we often use as exercises to try out other, more complex ideas.
  61. Spoilers happen when we see someone else’s differentiator and want it for ourselves. Eventually the differentiators become so spoiled that they’re commoditised. Everyone now has phones with cameras on them!
  62. This matches the Cynefin framework.In the simple domain, we can understand problems easily and fix them. Cause and effect are tightly coupled, and we work by categorizing the problem.In complicated domains, we need expertise to understand the relationship between cause and effect, but they’re still predictable. We work by analyzing the problem.In the complex domain, cause and effect are only correlated in retrospect, and we can’t predict outcomes. They emerge. We have to probe, or run experiments, to understand what happens. The experiments must be safe to fail.In the chaotic domain, cause and effect aren’t correlated. Chaos is short-lived, and often very destructive. We have to act to stop our house from burning down or someone from bleeding to death!
  63. There is a fifth domain in which we’re not sure which of the other domains dominates. So we usually act according to our preferred domain.Developers, for instance, love working in complex spaces, so they will usually take a complicated problem andautomate it, turning it into a different, complex problem.Some managers love command-and-control, which works very well when an urgent situation requires people to act, but not so well when you need people to interact in order to get an emergent outcome.
  64. Along the border between simplicity and chaos lies complacency, which results in a small cliff-edge, like the fold in a sheet. It’s very easy to tip into chaos, and hard to get back out of it again without going all the way round all the domains!
  65. When I showed you Feature Injection, I showed you a method of breaking down problems into smaller and smaller pieces. But we know that only works for problems which are well-understood, and for which expertise is enough!We have an expression, “Frog thinking vs. Bicycle thinking”. You can break a bicycle into pieces and put it back together again, but you can’t do that with a frog!
  66. For things which are new, we can’t break them down. We don’t know enough about them. Breaking them down will give us the *illusion* of certainty without giving us certainty!Instead, in this space, find something we can *try out* and learn from.
  67. On the left, you’ll start hearing the language of uncertainty.On the right, you’ll see people getting bored.BDD is brilliant for learning more about the domain in the middle, and for helping to work out when you don’t need to have any more conversations and can start coding something – either because it’s well-understood, or because it’s time to try an experiment!
  68. What capabilities do I need to deliver if I want an app to quickly report text spammers to my mobile phone company?Which of those capabilities do we know have already been delivered?What’s the scope of this project? Would it be valuable to do it for just “3” (my network)? How about just spam containing “PPI”? What else would we absolutely need in order to release that safely?If you released that as an MVP, what would be the next thing you added to it? Another stakeholder, or another feature for “3” and me (Liz)? This is how we do release planning!
  69. Conversations are a reasonably small commitment.
  70. This book is all about Real Options, and I recommend it.
  71. On one project, I got them to list the capabilities of their application. They always talked in terms of the 3 main architectural components, so we listed them in terms of the components’ capabilities.“Put a red dot on anything you haven’t done before,” I said.We estimated in very large-scale points. “Which is the smallest? Call that 20. Which is the biggest? How much bigger? Call that 400. Is there something in the middle that’s about 200? Fantastic; rank the rest.”After they’d finished, I said, “Now double everything with a red dot on, unless you can think of a good reason not to.”This included risk associated with people, process and technology… so anything where they were unclear about how it would happen, or who or when it would happen with, as well as new problems the company had never solved before.I now have a much better way of doing this: http://lizkeogh.com/2013/09/05/capability-based-planning-and-lightweight-analysis/
  72. The team broke off different capabilities and the analysts split them into features. If the devs decided a feature was too big for a sprint, they split them into stories using scenarios. Mostly the scenarios were end-to-end.
  73. If you were to take on the ideas in this talk, what would you like your Scrum or Kanban board to look like?
  74. The ideas about uncertainty and certainty – and complexity and complicatedness -mean that this is a *really boring* scenario. This teaches us nothing, and if all our scenarios look like this we are yawning.
  75. But by changing the context, we can suddenly discover uncertainty. Fred didn’t walk back into the store with a 120kg fridge-freezer on his shoulder… so, what do we do now?
  76. Can you think of any scenarios which actually teach us something about our domain? Anything which might have more than one answer that’s “right”? Or anything which you can’t think of what the right answer is?
  77. Those examples – the ones where we don’t know the answer and we have to try something out - *those* are the ones we want to find the most.
  78. Hard-coding data behind a UI is a great way to get feedback on a new UI. You can also do things like send hard-coded messages over a message bus to test the performance, etc. Do whatever is new, first.
  79. In any architecturally complex system, the feature we’re building will only need part of that system. By building just enough for the feature, we can get information about whether our chosen architecture will suit our stakeholders’ needs while leaving our options open elsewhere in the system for the future.
  80. We code just enough of the architecture to get our feature working.
  81. Sometimes showing an architect that you’ve left it open for change, so that it can be moved to the “ideal” architecture later, is enough. The best architects love this, because it lets *them* try things out and be wrong… and options have value.
  82. We can look at different inputs and get different scenarios, then decide which of those inputs to do…
  83. Or we can do the same things with outputs.
  84. Sometimes the format of input and output is the same, but the content of output will change depending on internal rules. For instance, Amazon ships orders over a certain price for free, and Amazon Prime users get it more quickly.
  85. This was a real project I worked on which had something similar. All those little squares are user stories. How can we possibly spot uncertainty when we break everything down up-front like this?Instead, I recommend breaking things down to the capability and maybe the feature level, then letting the devs break those down into stories based on what they think they can usefully do before the next time they’re due to see stakeholders for feedback.
  86. Remember the Asteroids game? The big asteroids travel very slowly. The smaller asteroids travel faster. The way to die quickly is to split up all the asteroids into tiny little ones that you can’t keep track of. If you do this with your stories, you’ll find your project just as hard to handle. Take one big chunk at a time, finish it off, then go for the next one.
  87. Think of the last time you did a long project, > 9 months or so.How long would it take to do the same project again with the same people, same technology, same requirements, same everything… just *again*?That’s how much of our projects is taken up with learning! The more innovative the project, the more learning will go on. If you’re into Theory of Constraints, you can think of a project as a factory which processes ignorance into non-ignorance through learning. By focusing on that, we go faster.If you haven’t come across Theory of Constraints, here’s the book to read: EliyahuGoldratt, “The Goal”http://www.amazon.co.uk/The-Goal-Process-Improvement-ebook/dp/B002LHRM2O/Along with “Waltzing with Bears”, it’s one of my two most recommended texts to get hold of. It’s also a fiction book, so a very easy read!
  88. Here’s my stand-up template. Using this will help the team focus on the interesting things that people find out, which will accelerate the learning of the whole team as well as enabling them to respond to each other’s discoveries.As another hint: PMs, or anyone with authority, should speak last if at all. If they start the meeting off it will automatically turn into a status update meeting to that person.Those of you telling the team who should speak next… what would happen if you stopped doing that? If they had a beanie toy, or a ball, to throw to each other to determine the order in which they went and who spoke? What amazing stuff *could* happen?
  89. Remember this?Have fun with the conversations!