© 2023 Thoughtworks
Driving
Engagement
with User Stories
Vishal Prasad (he/him)

© 2023 Thoughtworks 2
Unlearn to
Relearn
Part 1.
Agenda
● This is fast paced interactive workshop (~20 mins per part)
● Timebox must be respected, follow the law of the facilitator
● When time can’t be bought, use the parking lot
Things to know
Refine new
Learnings
Part 2.
Specification
by Example
Part 3.
Housekeeping
Discussions
Part 4.
13:40
© 2023 Thoughtworks

© 2023 Thoughtworks
Part One: Unlearn to Relearn
13:40

© 2023 Thoughtworks
What is a User Story?
4
13:43
2 mins

© 2023 Thoughtworks
In a written form, a
user story describes
functionality that will
be valuable to either a
user or purchaser of a
system or software.
5
13:46
© 2023 Thoughtworks

© 2023 Thoughtworks
What are the various
components or
sections of a User
Story?
3 mins
13:49
● Add as many components or
sections you can think of
● Add only one item on one sticky
● Duplicates are fine

© 2023 Thoughtworks 7
a written description
for planning and a
reminder
Card.
User stories are composed of 3 aspects
Source: Ron Jeffries | Rachel Davies
Anchored with the belief that software requirements is a communication problem
to flesh out the
details of the
requirement
Conversation.
tests that convey &
document details to
determine completion
Confirmation.
13:52
© 2023 Thoughtworks

© 2023 Thoughtworks
User Stories have no fixed
structure as long as the 3Cs are
managed.
13:52

© 2023 Thoughtworks
Exercise Zero
Write a User Story to
view your emails
3 mins in groups of 3
13:55
● Begin with a goal that a user wants
to achieve
● Have a conversation to agree upon
what is needed
● Identify as many test cases as
possible

© 2023 Thoughtworks
Part Two: Refine new Learnings
13:55

© 2023 Thoughtworks
● Why write user story on cards?
● Why hold these conversations?
● Why not just continue writing
requirement documents or use
cases?
● What’s new with user stories?
Why use
User Stories?
Why Change?
13:58

© 2023 Thoughtworks 12
14:06

© 2023 Thoughtworks
The customer gets a Peanut
Butter & Jelly Sandwich when
ordered
14:10

© 2023 Thoughtworks
The customer gets a Peanut
Butter & Jelly Sandwich when
ordered
● The sandwich is 3 inches wide and 4
inches long
● The sandwich has exactly 2 pieces of
bread (slice 1 & 2)
● One face of bread slice 1 has 10gm
peanut butter evenly spread
● One face of bread slice 2 has 10gm jelly
evenly spread
● Customer doesn’t get Peanut Butter &
Jelly on their hands when holding the
sandwich
14:10

© 2023 Thoughtworks
● Contrary to common belief,
reducing the amount of
instructions can yield better
results if the constraints are
well-defined.
The customer gets a Peanut
Butter & Jelly Sandwich when
ordered
● The sandwich is 3 inches wide and 4
inches long
● The sandwich has exactly 2 pieces of
bread (slice 1 & 2)
● One face of bread slice 1 has 10gm
peanut butter evenly spread
● One face of bread slice 2 has 10gm jelly
evenly spread
● Customer doesn’t get Peanut Butter &
Jelly on their hands when holding the
sandwich
14:10

© 2023 Thoughtworks
● Contrary to common belief,
reducing the amount of
instructions can yield better
results if the constraints are
well-defined.
● The creation steps must be left to
the people with the appropriate
skills (e.g. the sandwich maker,
the guitar designer, the
carpenter, the electrician, the
programmer, etc.)
The customer gets a Peanut
Butter & Jelly Sandwich when
ordered
● The sandwich is 3 inches wide and 4
inches long
● The sandwich has exactly 2 pieces of
bread (slice 1 & 2)
● One face of bread slice 1 has 10gm
peanut butter evenly spread
● One face of bread slice 2 has 10gm jelly
evenly spread
● Customer doesn’t get Peanut Butter &
Jelly on their hands when holding the
sandwich
14:10

© 2023 Thoughtworks
● Contrary to common belief,
reducing the amount of
instructions can yield better
results if the constraints are
well-defined.
● The creation steps must be left to
the people with the appropriate
skills (e.g. the sandwich maker,
the guitar designer, the
carpenter, the electrician, the
programmer, etc.)
● The acceptance conditions must
be provided by the customer or
the user of the requirement.
The customer gets a Peanut
Butter & Jelly Sandwich when
ordered
● The sandwich is 3 inches wide and 4
inches long
● The sandwich has exactly 2 pieces of
bread (slice 1 & 2)
● One face of bread slice 1 has 10gm
peanut butter evenly spread
● One face of bread slice 2 has 10gm jelly
evenly spread
● Customer doesn’t get Peanut Butter &
Jelly on their hands when holding the
sandwich
14:10

© 2023 Thoughtworks
Let’s
discuss
INVEST
5 mins
18
14:15
© 2023 Thoughtworks

© 2023 Thoughtworks
Part Three: Specification by Example
14:15

© 2023 Thoughtworks 20
A collaborative method for specifying
requirements and tests to:
● produce a living, reliable
documentation
● define expectations clearly and
make validation efficient
● reduce rework
● assure delivery teams and
business stakeholders that the
software built is right for its
purpose
Specification by
Example
a Single source of Truth
14:20

© 2023 Thoughtworks 21
What problem are we
trying to solve?
Business.
Three Amigos
The primary perspectives to examine an increment of work before, during, and after
development
How might we build a
solution to solve that
problem?
Development.
What about this, what
could possibly
happen?
Testing.
14:20
© 2023 Thoughtworks

© 2023 Thoughtworks
Acceptance Test Driven Development
14:20
Three Amigos in Action discussing Valet Parking (Source: Markus Gärtner)

© 2023 Thoughtworks
Acceptance Test Driven Development
14:20
Three Amigos in Action discussing Valet Parking (Source: Markus Gärtner)
Dev
Let’s discuss the parking lot cost calculation requirements.

© 2023 Thoughtworks
Acceptance Test Driven Development
14:20
Three Amigos in Action discussing Valet Parking (Source: Markus Gärtner)
Dev
Let’s discuss the parking lot cost calculation requirements.
Biz
We have 3 types of parking lots. Some have costs per hour, some per day, some have a daily
or weekly maximum.

© 2023 Thoughtworks
Acceptance Test Driven Development
14:20
Three Amigos in Action discussing Valet Parking (Source: Markus Gärtner)
Dev
Let’s discuss the parking lot cost calculation requirements.
Biz
We have 3 types of parking lots. Some have costs per hour, some per day, some have a daily
or weekly maximum.
Dev
How do you refer to the different parking lots? Are there names for them?

© 2023 Thoughtworks
Acceptance Test Driven Development
Biz
Valet parking, short-term parking, and regular parking. If you lose your ticket, you will be
charged a fee of $10.00.
14:20
Three Amigos in Action discussing Valet Parking (Source: Markus Gärtner)

© 2023 Thoughtworks
Acceptance Test Driven Development
Biz
Valet parking, short-term parking, and regular parking. If you lose your ticket, you will be
charged a fee of $10.00.
Dev
Let’s concentrate on the 3 types. What’s the difference between them?
14:20
Three Amigos in Action discussing Valet Parking (Source: Markus Gärtner)

© 2023 Thoughtworks
Acceptance Test Driven Development
Biz
Valet parking, short-term parking, and regular parking. If you lose your ticket, you will be
charged a fee of $10.00.
Dev
Let’s concentrate on the 3 types. What’s the difference between them?
Biz
For valet parking, the passenger drops his or her car off at the valet drop off and gets a
receipt to get the car back.
14:20
Three Amigos in Action discussing Valet Parking (Source: Markus Gärtner)

© 2023 Thoughtworks
Acceptance Test Driven Development
Dev
What can you tell us about parking costs?
14:20
Three Amigos in Action discussing Valet Parking (Source: Markus Gärtner)

© 2023 Thoughtworks
Acceptance Test Driven Development
Dev
What can you tell us about parking costs?
Biz
Valet parking costs $18.00 per day. For 5 hours or less you get a reduction of $6.00.
14:20
Three Amigos in Action discussing Valet Parking (Source: Markus Gärtner)

© 2023 Thoughtworks
Acceptance Test Driven Development
Dev
What can you tell us about parking costs?
Biz
Valet parking costs $18.00 per day. For 5 hours or less you get a reduction of $6.00.
Test
Wait a moment, you mean for even 30 minutes I get charged $12.00, for 3 hours I have to pay
the same, as well as for 5 hours? But for 5 hour and 1 minute I have to pay $18.00 as well as
for 12 or 24 hours?
14:20
Three Amigos in Action discussing Valet Parking (Source: Markus Gärtner)

© 2023 Thoughtworks
Acceptance Test Driven Development
Biz
Yes, absolutely right.
14:20
Three Amigos in Action discussing Valet Parking (Source: Markus Gärtner)

© 2023 Thoughtworks
Acceptance Test Driven Development
Biz
Yes, absolutely right.
Test
What about 24 hours and 1 minute? Would this be $30.00 then, or $36.00?
14:20
Three Amigos in Action discussing Valet Parking (Source: Markus Gärtner)

© 2023 Thoughtworks
Acceptance Test Driven Development
Biz
Yes, absolutely right.
Biz
Oh, that is of course $36.00.
Test
What about 24 hours and 1 minute? Would this be $30.00 then, or $36.00?
14:20
Three Amigos in Action discussing Valet Parking (Source: Markus Gärtner)

© 2023 Thoughtworks
Acceptance Test Driven Development
Dev
What about weekly limits? Are there any for valet parking?
14:20
Three Amigos in Action discussing Valet Parking (Source: Markus Gärtner)

© 2023 Thoughtworks
Acceptance Test Driven Development
Biz
No that’s basically all there is for valet parking.
Dev
What about weekly limits? Are there any for valet parking?
14:20
Three Amigos in Action discussing Valet Parking (Source: Markus Gärtner)

© 2023 Thoughtworks
Acceptance Test Driven Development
Biz
No that’s basically all there is for valet parking.
Test
OK, then let me write these down as examples.
Dev
What about weekly limits? Are there any for valet parking?
14:20
Three Amigos in Action discussing Valet Parking (Source: Markus Gärtner)

© 2023 Thoughtworks
Acceptance Test Driven Development
Dev
What about weekly limits? Are there
any for valet parking?
14:20
Three Amigos in Action discussing Valet Parking (Source: Markus Gärtner)

© 2023 Thoughtworks
Acceptance Test Driven Development
Dev
What about weekly limits? Are there
any for valet parking?
Biz
No that’s basically all there is for
valet parking.
14:20
Three Amigos in Action discussing Valet Parking (Source: Markus Gärtner)

© 2023 Thoughtworks
Acceptance Test Driven Development
Dev
What about weekly limits? Are there
any for valet parking?
Biz
No that’s basically all there is for
valet parking.
Test
OK, then let me write these down
as examples.
14:20
Three Amigos in Action discussing Valet Parking (Source: Markus Gärtner)

© 2023 Thoughtworks
Acceptance Test Driven Development
Dev
What about weekly limits? Are there
any for valet parking?
Biz
No that’s basically all there is for
valet parking.
Test
OK, then let me write these down
as examples.
Parking Duration Parking Costs
30 minutes $12.00
3 hours $12.00
5 hours $12.00
5 hours 1 minute $18.00
12 hours $18.00
24 hours $18.00
1 day 1 minute $36.00
3 days $54.00
1 week $126.00
14:20
Three Amigos in Action discussing Valet Parking (Source: Markus Gärtner)

© 2023 Thoughtworks
Behaviour-driven development (BDD) takes the position that
you can turn an idea for a requirement into implemented,
tested, production-ready code simply and effectively, as long as
the requirement is specific enough that everyone knows what’s
going on. To do this, we need a way to describe the requirement
such that everyone – the business folks, the analyst, the
developer and the tester – have a common understanding of the
scope of the work. From this they can agree a common
definition of “done”, and we escape the dual gumption traps of
“that’s not what I asked for” or “I forgot to tell you about this
other thing”.
14:25
- Dan North

© 2023 Thoughtworks
Behaviour Driven Development with Gherkin
14:25
Each line that isn’t a blank line has to start with a Gherkin keyword, followed by any text you
like. The only exceptions are the free-form descriptions placed underneath Example /
Scenario, Background, Scenario Outline and Rule lines.
The primary keywords are:
● Feature
● Rule (as of Gherkin 6)
● Example (or Scenario)
● Given, When, Then, And, But for steps (or *)
● Background
● Scenario Outline (or Scenario Template)
● Examples (or Scenarios)

© 2023 Thoughtworks
Securing your emails expressed in Gherkin
14:30
Feature: Advanced Authentication
As an Email User, I want to secure my
account so only I see my emails
Background:
Given email domain is “thoughtworks”
And accessing IP is “unrestricted”
Example: Accessing emails from a new IP
Given “jon” is accessing emails
When logged in IP has never been used
Then email “jon” the new location info
Scenario Outline: SSO response messages
Given auth token doesn’t exist for <id>
When SSO authentication is requested
And <response> is received
Then denote <message>
Examples:
|id |response |message |
|jon |unrestricted |authenticated|
|sal |restricted |restricted |
|wolf|invalid |invalid |
|jon |service down |unreachable |

© 2023 Thoughtworks
Viewing your emails expressed in Gherkin
14:35

© 2023 Thoughtworks
Part Four: Housekeeping Discussions
14:35

© 2023 Thoughtworks
Guidelines for Good User Stories
14:40
Source: Mike Cohn

© 2023 Thoughtworks
Guidelines for Good User Stories
14:40
Source: Mike Cohn
● Start with Goal Stories; these
can then be used to generate
additional stories

© 2023 Thoughtworks
Guidelines for Good User Stories
14:40
Source: Mike Cohn
● Start with Goal Stories; these
can then be used to generate
additional stories
● Slice the Cake; do not split
stories around technical
lines, follow INVEST

© 2023 Thoughtworks
Guidelines for Good User Stories
14:40
Source: Mike Cohn
● Start with Goal Stories; these
can then be used to generate
additional stories
● Slice the Cake; do not split
stories around technical
lines, follow INVEST
● Write Closed Stories; a story
that finishes by achieving a
meaningful goal

© 2023 Thoughtworks
Guidelines for Good User Stories
14:40
Source: Mike Cohn
● Start with Goal Stories; these
can then be used to generate
additional stories
● Slice the Cake; do not split
stories around technical
lines, follow INVEST
● Write Closed Stories; a story
that finishes by achieving a
meaningful goal
● Put Constraints on Cards;
these are NFRs that must be
obeyed and can apply to
multiple stories

© 2023 Thoughtworks
Guidelines for Good User Stories
14:40
Source: Mike Cohn
● Start with Goal Stories; these
can then be used to generate
additional stories
● Slice the Cake; do not split
stories around technical
lines, follow INVEST
● Write Closed Stories; a story
that finishes by achieving a
meaningful goal
● Put Constraints on Cards;
these are NFRs that must be
obeyed and can apply to
multiple stories
● Keep UI Out as Long as
Possible; use supplements
to denote these

© 2023 Thoughtworks
Guidelines for Good User Stories
14:40
Source: Mike Cohn
● Start with Goal Stories; these
can then be used to generate
additional stories
● Slice the Cake; do not split
stories around technical
lines, follow INVEST
● Write Closed Stories; a story
that finishes by achieving a
meaningful goal
● Put Constraints on Cards;
these are NFRs that must be
obeyed and can apply to
multiple stories
● Keep UI Out as Long as
Possible; use supplements
to denote these
● Include User Roles in the
Stories; instead of “a user”

© 2023 Thoughtworks
Guidelines for Good User Stories
14:40
Source: Mike Cohn
● Start with Goal Stories; these
can then be used to generate
additional stories
● Slice the Cake; do not split
stories around technical
lines, follow INVEST
● Write Closed Stories; a story
that finishes by achieving a
meaningful goal
● Put Constraints on Cards;
these are NFRs that must be
obeyed and can apply to
multiple stories
● Keep UI Out as Long as
Possible; use supplements
to denote these
● Include User Roles in the
Stories; instead of “a user”
● Some Things Aren’t Stories;
use supplements to denote
these, e.g. UI guidelines, API
details, Compliance Docs,
etc.

© 2023 Thoughtworks
Guidelines for Good User Stories
14:40
Source: Mike Cohn
● Start with Goal Stories; these
can then be used to generate
additional stories
● Slice the Cake; do not split
stories around technical
lines, follow INVEST
● Write Closed Stories; a story
that finishes by achieving a
meaningful goal
● Put Constraints on Cards;
these are NFRs that must be
obeyed and can apply to
multiple stories
● Keep UI Out as Long as
Possible; use supplements
to denote these
● Include User Roles in the
Stories; instead of “a user”
● Some Things Aren’t Stories;
use supplements to denote
these, e.g. UI guidelines, API
details, Compliance Docs,
etc.
● One card is written for one
user, written in active voice,
and written by the customer

© 2023 Thoughtworks
Guidelines for Good User Stories
14:40
Source: Mike Cohn
● Start with Goal Stories; these
can then be used to generate
additional stories
● Slice the Cake; do not split
stories around technical
lines, follow INVEST
● Write Closed Stories; a story
that finishes by achieving a
meaningful goal
● Put Constraints on Cards;
these are NFRs that must be
obeyed and can apply to
multiple stories
● Keep UI Out as Long as
Possible; use supplements
to denote these
● Include User Roles in the
Stories; instead of “a user”
● Some Things Aren’t Stories;
use supplements to denote
these, e.g. UI guidelines, API
details, Compliance Docs,
etc.
● One card is written for one
user, written in active voice,
and written by the customer
● Don’t Forget the Purpose; it’s
a promise for a conversation

© 2023 Thoughtworks
Definition of Done
14:45

© 2023 Thoughtworks
Definition of Done
● A set of Passing automated
tests (and a few manual tests)
that confirms that a product
increment is product ready
14:45

© 2023 Thoughtworks
Definition of Done
● A set of Passing automated
tests (and a few manual tests)
that confirms that a product
increment is product ready
● May or may not be applicable
to individual stories
14:45

© 2023 Thoughtworks
Definition of Done
● A set of Passing automated
tests (and a few manual tests)
that confirms that a product
increment is product ready
● May or may not be applicable
to individual stories
● Must be executed after every
code commit, on an integrated
environment
14:45

© 2023 Thoughtworks
Definition of Done
● A set of Passing automated
tests (and a few manual tests)
that confirms that a product
increment is product ready
● May or may not be applicable
to individual stories
● Must be executed after every
code commit, on an integrated
environment
14:45
Definition of Ready

© 2023 Thoughtworks
Definition of Done
● A set of Passing automated
tests (and a few manual tests)
that confirms that a product
increment is product ready
● May or may not be applicable
to individual stories
● Must be executed after every
code commit, on an integrated
environment
14:45
● It is ready when the 3 amigos
have identified all tests (as a
part of INVEST) to be fulfilled
by a story and its
implementation is well
understood.
Definition of Ready

© 2023 Thoughtworks
Definition of Done
● A set of Passing automated
tests (and a few manual tests)
that confirms that a product
increment is product ready
● May or may not be applicable
to individual stories
● Must be executed after every
code commit, on an integrated
environment
14:45
● It is ready when the 3 amigos
have identified all tests (as a
part of INVEST) to be fulfilled
by a story and its
implementation is well
understood.
● This is NOT a requirements’
sign-off process
Definition of Ready

© 2023 Thoughtworks
Definition of Done
● A set of Passing automated
tests (and a few manual tests)
that confirms that a product
increment is product ready
● May or may not be applicable
to individual stories
● Must be executed after every
code commit, on an integrated
environment
14:45
● It is ready when the 3 amigos
have identified all tests (as a
part of INVEST) to be fulfilled
by a story and its
implementation is well
understood.
● This is NOT a requirements’
sign-off process
● Probably an anti-pattern
Definition of Ready

© 2023 Thoughtworks
Zero Defect Policy
14:55
An outcome of Specification by Example

© 2023 Thoughtworks
Zero Defect Policy
● Context: A common practice among teams is to
have a bug triage when a defect is reported in
production. As per an organisation’s Defect
Management Policy, this may go under one of the
few buckets like fix now, fix later, not a bug, change
request, etc.
14:55
An outcome of Specification by Example

© 2023 Thoughtworks
Zero Defect Policy
● Context: A common practice among teams is to
have a bug triage when a defect is reported in
production. As per an organisation’s Defect
Management Policy, this may go under one of the
few buckets like fix now, fix later, not a bug, change
request, etc.
● The dilemma is that although the engineering team
may bucket these in various types, it’s always a
defect for a customer / user.
14:55
An outcome of Specification by Example

© 2023 Thoughtworks
Zero Defect Policy
● By denoting requirements as tests using
Specification by Example, we automate tests
before coding and this ensures that no bugs enter
production as per the identified tests. This is a
Zero Bug Promise!
14:55
An outcome of Specification by Example

© 2023 Thoughtworks
Zero Defect Policy
● By denoting requirements as tests using
Specification by Example, we automate tests
before coding and this ensures that no bugs enter
production as per the identified tests. This is a
Zero Bug Promise!
● This does not mean that customers will not report
bugs in the future, however when that happens, it
would qualify as a missing test. This eliminates a
wasteful triage activity.
14:55
An outcome of Specification by Example

© 2023 Thoughtworks
Zero Defect Policy
● By denoting requirements as tests using
Specification by Example, we automate tests
before coding and this ensures that no bugs enter
production as per the identified tests. This is a
Zero Bug Promise!
● This does not mean that customers will not report
bugs in the future, however when that happens, it
would qualify as a missing test. This eliminates a
wasteful triage activity.
70
An outcome of Specification by Example
This
is
only
one
way
of
delivering
a
Zero
Bug
Promise!

© 2023 Thoughtworks
Keep in touch
Vishal Prasad
Thoughtworker
vishalp@thoughtworks.com