Driving Engagement with User Stories

© 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

Part One: Unlearn to Relearn
13:40

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

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

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

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

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

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

Part Two: Refine new Learnings
13:55

● 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

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

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

● Contrary to common belief,
reducing the amount of
instructions can yield better
results if the constraints are
well-defined.
ordered
inches long
bread (slice 1 & 2)
evenly spread
sandwich
14:10

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.)
ordered
inches long
bread (slice 1 & 2)
evenly spread
sandwich
14:10

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.
ordered
inches long
bread (slice 1 & 2)
evenly spread
sandwich
14:10

Let’s
discuss
INVEST
5 mins
18
14:15

Part Three: Specification by Example
14:15

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

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

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

14:20
Dev
Let’s discuss the parking lot cost calculation requirements.

14:20
Dev
Biz
We have 3 types of parking lots. Some have costs per hour, some per day, some have a daily
or weekly maximum.

14:20
Dev
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?

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

Biz
Dev
Let’s concentrate on the 3 types. What’s the difference between them?
14:20

Biz
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

Dev
What can you tell us about parking costs?
14:20

Dev
Biz
Valet parking costs $18.00 per day. For 5 hours or less you get a reduction of $6.00.
14:20

Dev
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

Biz
Yes, absolutely right.
14:20

Biz
Test
What about 24 hours and 1 minute? Would this be $30.00 then, or $36.00?
14:20

Biz
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

Dev
What about weekly limits? Are there any for valet parking?
14:20

Biz
No that’s basically all there is for valet parking.
Dev
14:20

Biz
No that’s basically all there is for valet parking.
Test
OK, then let me write these down as examples.
Dev
14:20

Dev
What about weekly limits? Are there
any for valet parking?
14:20

Dev
Biz
No that’s basically all there is for
valet parking.
14:20

Dev
Biz
valet parking.
Test
OK, then let me write these down
as examples.
14:20

Dev
Biz
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

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

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)

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 |

Viewing your emails expressed in Gherkin
14:35

Part Four: Housekeeping Discussions
14:35

Guidelines for Good User Stories
14:40
Source: Mike Cohn

14:40
Source: Mike Cohn
● Start with Goal Stories; these
can then be used to generate
additional stories

14:40
Source: Mike Cohn
additional stories
● Slice the Cake; do not split
stories around technical
lines, follow INVEST

14:40
Source: Mike Cohn
additional stories
● Write Closed Stories; a story
that finishes by achieving a
meaningful goal

14:40
Source: Mike Cohn
additional stories
meaningful goal
● Put Constraints on Cards;
these are NFRs that must be
obeyed and can apply to
multiple stories

14:40
Source: Mike Cohn
additional stories
meaningful goal
multiple stories
● Keep UI Out as Long as
Possible; use supplements
to denote these

14:40
Source: Mike Cohn
additional stories
meaningful goal
multiple stories
to denote these
● Include User Roles in the
Stories; instead of “a user”

14:40
Source: Mike Cohn
additional stories
meaningful goal
multiple stories
to denote these
● Some Things Aren’t Stories;
use supplements to denote
these, e.g. UI guidelines, API
details, Compliance Docs,
etc.

14:40
Source: Mike Cohn
additional stories
meaningful goal
multiple stories
to denote these
etc.
● One card is written for one
user, written in active voice,
and written by the customer

14:40
Source: Mike Cohn
additional stories
meaningful goal
multiple stories
to denote these
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

Definition of Done
14:45

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

Definition of Done
● May or may not be applicable
to individual stories
14:45

Definition of Done
● Must be executed after every
code commit, on an integrated
environment
14:45

Definition of Done
environment
14:45
Definition of Ready

Definition of Done
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

Definition of Done
environment
14:45
by a story and its
understood.
● This is NOT a requirements’
sign-off process
Definition of Ready

Definition of Done
environment
14:45
by a story and its
understood.
● This is NOT a requirements’
sign-off process
● Probably an anti-pattern
Definition of Ready

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

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

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

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

Zero Defect Policy
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

Zero Defect Policy
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
This
is
only
one
way
of
delivering
a
Zero
Bug
Promise!

Keep in touch
Vishal Prasad
Thoughtworker
vishalp@thoughtworks.com

Driving Engagement with User Stories

More Related Content

Similar to Driving Engagement with User Stories

More from Vishal Prasad

Recently uploaded

Driving Engagement with User Stories