Beginners Guide to Composing User Stories

1. Composing
User
Stories
Raja
.
S
July
2014

2. We
Are
Here
!!!
Implementa2on
Story
Refinement
Coding
Tes2ng
Planning
Storytelling
Chartering
Project
happen
in
a
context,
created
by
their
charter
Once
you
have
some
stories,
you
can
plan
with
them
Storytelling,
the
art
of
composing
user
stories,
is
the
focus
of
this
album
Implementa2on
involves
some
story-­‐related
acIviIes
in
refinement
and
tes2ng.
We’ll
touch
on
them
slightly,
but
they’re
mostly
out
of
scope
for
this
album
This
drawing
is
linear,
but
real
projects
move
more
freely
among
these
acIviIes

3. What
is
in
a
ChaMer
?
A
Project’s
Charter
Drives
the
Stories
You
will
Create.
Whether
formal
or
informal,
a
charter
establishes
clear
expecta2ons
between
a
sponsor
and
a
team
The
charter
answers
key
quesIons
that
set
the
context:
• Vision:
The
ulImate
end-­‐state
that
will
saIsfy
the
sponsor
• Mission:
The
way
in
which
we
propose
to
accomplish
the
vision
• Principles:
What
values
guide
the
team’s
behavior?
• Objec2ves:
What
are
the
measurable
,
external
outcomes
for
which
the
sponsor
is
funding
the
project.
What
tests
will
tell
us
if
those
objecIves
were
met?
• Boundaries:
What
is
the
project
responsible
for?
What
comes
in
or
goes
out?
What
are
the
key
events?
• CommiLed
Resources:
What
resources
will
be
made
available
to
the
team?
• Authorizing
Players:
Who
is
sponsoring
the
work?
Who
will
judge
it?

4. Telling
Stories
with
the
Product
Backlog

5. Requirements
=
CommunicaIon
Tool
• Can
be
well
thought
through,
reviewed
and
edited
• Provide
a
permanent
record
• Are
easily
shared
with
groups
of
people
• Time
consuming
to
produce
• May
be
less
relevant
or
superseded
over
Ime
• Can
be
easily
misinterpreted
WriLen
Requirements
• Instantaneous
feedback
and
clarificaIon
• InformaIon-­‐packed
exchange
• Easier
to
clarify
and
gain
common
understanding
• Easily
adapted
to
any
new
informaIon
known
at
the
Ime
• Can
spark
ideas
about
problems
and
opportuniIes
Verbal
Requirements

6. User
Stories
Seek
to
Combine
the
Strengths
of
WriLen
and
Verbal
Communica2on,
Where
Possible
Supported
by
a
Picture.
*
Kent
Beck
Coined
the
Term
User
Stories
in
Extreme
Programming
Explained
1st
EdiIon,
1999.

7. What
is
a
User
Story?
A
concise,
wriLen
descrip2on
of
a
piece
of
func2onality
that
will
be
valuable
to
a
user
(or
owner)
of
the
soTware
Stories
are:
• User’s
needs
• Product
descripIons
• Planning
items
• Tokens
for
a
conversaIon
• Mechanisms
for
deferring
conversaIon

8. User
Story
–
Ambiguity
Yes,
it
is.
You’ll
hear
“User
Story”
(or
“story”)
used
to
talk
about
at
least
three
things:
• The
feature
itself
(whether
implemented
yet
or
not)
• The
“headline”
wriMen
on
a
card
• The
headline,
details,
discussions,
and
key
tests
that
together
describe
a
feature
The
context
will
tell
you
which
meaning
of
story
is
in
play.
Isn’t
the
Term
“User
Story”
Ambiguous?

9. A
user
story
describes
a
s2mulus;
the
system
produces
results
in
response
to
that
s2mulus
• All
stories
have
the
same
basic
structure:
Heading
(Itle)
and
details
User
Story
–
Basic
Structure
Heading
Details
User Logs in with Expired License
Take user to home page
Disable all links and buttons
Add prominent renewal link that takes
user to the Store
– Ask for exact text and location

10. The
Heading:
Role–Ac2on–Context
The
“Role–Ac2on–Context”
formula
works
very
well
for
wri2ng
story
headings
that
reflect
events
and
responses:
The
words
in
the
heading
create
and
reflect
a
domain
vocabulary:
• The
people
using
our
system
• How
they
can
act
• What
they
can
act
upon
Heading
–
RAC
Style
Someone
or
something
that
sends
a
s2mulus
into
a
system
boundary
How
the
role
triggers
the
s2mulus.
Usually
as
simple
as
verb
+
object
Op2onal:
Where
or
when
the
ac2on
applies
Role
User Logs in with Expired License
Ac2on
Context

11. Good
Headings
Which
are
Good
Headings?
Which
of
the
following
fit
the
Role–Ac2on–Context
formula
(Good)
and
which
Do
Not?
Good
Bad
1. “The
system
shall
process
Visa™
cards.”
2. ATM
Customer:
Iden2fies
self
System:
Presents
op2ons
for
deposit,
withdrawal,
or
fast
cash
ATM
Customer:
Selects
fast
cash
etc.
3. “Student
Schedules
a
Course”
4. “Grading”

12. As
a
type-­‐of-­‐user,
I
want
to
ac-on
so
that
business-­‐goal
DescripIon
–
Connextra
Style
User
stories
replace
detailed
requirements
and
specificaIons
with
just
enough
detail.
Just
enough
for
what?
For
esImaIng,
planning,
understanding,
discovering,
and
evolving
the
system,
and
basically,
moving
forward
The
details
elaborate
on
the
heading.
They
describe
the
sImulus,
the
response,
and
any
specifics
that
maMer
to
the
customer.
The
details
shouldn’t
be
technical,
nor
should
they
spell
out
development
tasks
or
guide
implementaIon
The
Details
Elaborate
on
the
Heading
You
can
use
any
simple
means
to
write
the
details,
as
long
as
you
get
your
point
across:
• A
few
phrases
• Bullet
points
• Diagrams
• Hand-­‐drawn
pictures
“Wri2ng
the
Stories
is
Not
the
Point,
Communica2ng
is
the
Point”
– Kent
Beck
and
Mar-n
Fowler

13. When
Do
We
Get
the
Details
• During
planning
sessions
• Even
deeper
conversaIons
about
other
details
as
they
begin
to
implement
the
story
• Decisions,
details,
and
specificaIons
can
be
captured
in
automated
tests,
as
a
picture,
on
a
whiteboard,
or
by
any
other
useful
means
• Key
Principle:
"Defer
decisions
unIl
the
last
responsible
moment.”

14. Pre-­‐requisites
Some
details
are
clearly
needed
earlier
than
others.

15. Summary
User
Stories
Provide
a
Lightweight
Way
to
Manage
Requirements.
• “A
user
story
is
a
chunk
of
funcIonality
(some
people
use
the
word
feature)
that
is
of
value
to
the
customer.”
• A
story
card
consists
of
a
heading
(Itle)
and
details
• The
formula
Role–AcIon–Context
can
help
you
write
effecIve
story
headings
• A
story
is
useful
even
before
we
work
out
its
details:
“A
user
story
is
a
promissory
note
for
a
conversaIon.”
(Cockburn)
• “CCC:
Card,
ConversaIon,
ConfirmaIon”
(Jeffries)

16. What
Makes
a
User
Story
Good
A
Story
Should
be
• Understandable
to
customers
and
developers
• Testable
• Valuable
to
the
customer
• Small
enough
so
that
the
programmers
can
build
half
a
dozen
in
an
iteraIon
– Kent
Beck
and
Mar-n
Fowler

17. INVEST
–
Acronym
Bill
Wake
devised
the
acronym
INVEST
as
a
reminder
of
the
properIes
of
good
stories
Independent
Nego2able
(and
Nego2ated)
Valuable
Es2matable
Small
Testable
Stories
ideally
describe
non-­‐overlapping
bits
of
funcIonality,
possible
to
implement
in
any
order
The
customer,
developers,
and
testers
can
agree
on
what
the
story
means
precisely
enough
that
tests
can
be
created
Stories
have
flexibility;
there’s
room
for
a
collaboraIve
definiIon
of
success
Stories’
value
makes
sense
from
a
customer
or
end
user’s
perspecIve.
They’re
not
described
in
terms
of
a
developer’s
tasks
The
team
can
esImate
the
difficulty
of
the
story
(at
least
to
a
rough
level)
The
story
is
small
enough
for
its
purpose.
For
implementaIon,
it
can
be
completed
in
less
than
an
iteraIon.
For
longer
term
planning,
the
story
is
larger

18. What
Characterizes
Great
User
Story
Essen2al
The
user
story
describes
something
that
helps
achieve
essenIal
management
objecIves
External
The
user
story
perspecIve
views
the
system
as
a
black
box,
describing
what
is
to
happen,
not
how
it
happens
Instantaneous
The
user
story
happens
at
an
instant
in
Ime
rather
than
over
a
duraIon
of
Ime
Detectable
The
user
story
has
an
explicit
sImulus
(acIon-­‐
or
Ime-­‐based)

19. EssenIal
Stories
• Essen2al
user
stories
provide
value
to
sponsors
• What
provides
value?
SoTware
that
helps
achieve
a
project
charter's
vision,
mission,
or
key
objec2ves
• Sponsors
ul2mately
care
about
effects,
the
changes
in
the
outside
world
resul2ng
from
the
system
• Here
is
the
vision
statement
project
charter:
§ Rapidly
spawned,
knowledge
workers,
skilled
in
the
fundamentals
of
collaboraIve
learning
§ User
stories
that
contribute
to
achieving
this
vision
are
essenIal.
Thus,
knowledge
workers
adds
eIqueMes
of
collaboraIon
in
enterprise
to
his
learning
plan
is
essenIal
because
it
lets
Knowledge
workers
teach
themselves
§ The
story
knowledge
workers
adds
eIqueMes
of
poetry
learning
to
his
learning
plan
is
not
essenIal
to
the
vision.
In
other
words,
it
is
not
currently
something
valued
by
sponsors

20. External
Stories
• User
stories
that
are
external
to
a
system
boundary
focus
on
organiza2onal
and
business
concerns
rather
than
technical
ones
• The
user
story
perspec2ve
views
the
system
as
a
black
box,
describing
what
is
to
happen,
not
how
it
happens
within
the
black
box
• The
external,
organiza2onally-­‐focused
language
of
user
stories
survives
changes
in
technology;
how
a
user
story
gets
implemented
is
up
to
the
programmers
• A
given
user
story
might
have
hundreds
of
ways
it
could
be
implemented
• When
wri2ng
User
Stories,
don't
include
any
technological
assump2ons
about
how
the
story
"should"
be
implemented
• User
stories
reflect
end-­‐to-­‐end
func2onality

21. Instantaneous
Stories
A
Great
Story
Describes
an
Instantaneous
Event.
The
story’s
ac2on
or
event,
happens
at
an
instant
in
2me
rather
than
over
a
dura-on
of
2me
The
phrase
“Clock
hands
move
around
clock
face”
fails
this
criterion
because
there
is
no
single
instant
in
2me
during
which
that
happens
The
clock’s
hands
reaching
a
certain
posi2on
or
2me
would
be
an
instantaneous
event
These
stories
headings
are
examples
of
instantaneous
events
• System
sends
daily
summary
email
• Customer
selects
report

22. User
stories
are
triggered
by
something
–
and
that
trigger
must
be
detectable
by
the
system
Ed
Yourdon
(author
of
the
classic,
modern
structured
analysis)
describes
three
types
of
event
triggers:
• Flow-­‐oriented
Events:
Triggered
by
data
arriving;
the
most
common
sort
Example:
Customer
cancels
order.
• Temporal
Events:
Triggered
by
a
point
in
Ime.
Example:
System
processes
credit
cards
at
9:00PM
• Control
Events:
Triggered
by
external
sImulus;
common
in
real-­‐Ime
systems
Example:
Alarm
sensor
signals
door
open
Detectable
Stories

23. Quiz
External
Stories
Quiz
Please
drag
the
boxes
to
re-­‐order
them
from
best
to
worst,
in
terms
of
their
taking
an
external
perspecIve
of
the
system.
Place
these
in
the
correct
order:
Student
Reveals
Answers
Student
Reveals
Answers
via
JavaScript
Student
Clicks
“Show
Answers”
Student
Reveals
Answers
by
Joining
Quiz
Answer
Column
in
Quiz
Table
with
Quiz
QuesIon
Table
Instantaneous
Stories
Quiz
For
each
item,
tell
whether
it
takes
place
at
an
Instant
or
over
a
Dura2on
of
Ime.
We
prefer
stories
with
s2muli
that
are
instantaneous,
rather
than
occurring
over
a
period
of
2me.
1.
Taxpayer
Submits
Tax
Form
2.
Admin
Reads
Report
3.
Device
Monitors
Blood
Pressure
4.
User
Selects
Context-­‐SensiIve
Help
Instant
Dura2on
Can
You
Hear
Me
Now?
Which
events
are
detectable?
For
each
event,
please
tell
whether
it
is
Detectable
or
Not.
1.
System
is
to
send
a
warning
noIce
3
days
before
library
book
is
due
2.
User
presses
keyboard
key(s)
to
capture
contents
of
the
screen
3.
Elevator
passenger
imagines
going
to
the
12th
floor
4.
The
developer
runs
into
the
project
manager
in
the
hallway
and
tells
her
that
the
task
is
completed
5.
The
government’s
tax
department
has
flagged
your
tax
return
and
is
considering
whether
to
audit
you.
(This
is
from
the
perspecIve
of
the
taxpayer,
not
the
government)
Detectable
Not

24. • First,
the
mere
existence
of
the
story
implies
that
the
project
community
considers
it
important.
Stories
that
actually
get
implemented
are
(hopefully)
essen2al.
If
you
don’t
need
the
story,
get
rid
of
it.
(If
you
track
stories
on
cards,
you’ll
get
a
saIsfying
feeling
when
you
r-­‐r-­‐rip
it
up)
• If
you
model
the
system’s
interacIons
properly,
the
role
is
usually
an
external
enIty
(user,
accountant,
another
system)
sending
a
sImulus
into
the
system
• Instantaneous
events
manifest
themselves
in
the
acIon,
usually
through
the
choice
of
the
verb
• When
the
means
of
interacIng
with
the
system
are
clear,
such
as
a
buMon-­‐click
or
API
call,
the
acIon
describes
a
detectable
event
• A
proper
context
helps
to
pinpoint
all
the
criteria,
and
helps
us
to
write
beMer
stories
Four
Criteria's
and
RCA
Format
I’m
not
sure
I
understand
how
these
four
criteria
relate
to
the
Role–Ac2on–Context
structure

25. Summary
The
Four
Criteria:
Essen2al,
External,
Instantaneous,
and
Detectable
Can
Help
Keep
Your
Stories
on
Track
1
Essen2al:
Valuable
to
sponsors
(as
part
of
the
charter)
2
External:
Takes
an
outside-­‐the-­‐system
perspecIve
3
Instantaneous:
Happens
at
a
moment
in
Ime,
not
over
an
interval
of
Ime
4
Detectable:
The
system
has
a
way
to
tell
that
the
story
is
triggered

26. What
are
Roles
When
we
say
User,
we’re
usually
talking
about
an
individual,
a
person
A
role
is
an
abstracIon:
A
name
for
how
a
parIcular
group
of
people
use
the
system
The
name
“role”
comes
from
theater:
An
actor
plays
a
role
by
acIng
like
someone,
but
they
don’t
really
become
that
person
Even
more
common,
a
single
role
can
be
filled
by
different
people:
Many
people
are
Shoppers
A
system
may
enforce
roles
(eg.,
only
Administrators
can
install
soqware),
but
we
don’t
require
that
Roles
need
not
be
explicit
in
the
system:
We
can
be
a
Browser
and
a
Shopper,
without
any
need
for
the
system
to
keep
track
of
which
role
we’re
playing
One
person
can
have
mul2ple
roles:
A
person
may
be
acIng
like
a
Browser
and
a
Shopper
at
different
Imes
in
a
single
session
Roles
Iden2fy
PaLerns
of
Using
the
System

27. Search
Widely
for
Roles
Roles
help
us
create
higher-­‐value
systems
by
focusing
on
the
needs
of
par2cular
groups
of
users
A
brainstorming
and
refinement
process
can
help
us
iden2fy
roles
(from
So6ware
for
Use
by
Constan2ne
and
Lockwood):
• Compile
–
Brainstorm
or
otherwise
generate
as
many
candidates
as
possible
• Organize
–
Review
and
sort
them;
understand
their
relaIonships;
consolidate
them
• Detail
–
Fill
in
any
missing
data
• Refine
–
Improve
and
complete
the
model
Develop
an
Ini2al
Model
of
Roles
and
Their
Rela2onships.

28. Characters
of
Users
Knowledge
about
users
can
help
iden2fy
missing
roles
and
guide
us
in
how
we
use
roles
Categories
of
users
can
suggest
missing
roles,
and
guide
us
in
how
we
treat
roles
we
know
about
Roles
Characteris2cs
Primary
or
Secondary
Do
we
need
to
address
this
user’s
needs
sooner
or
can
we
wait
Ill
later?
Example:
Customer
is
a
primary
role
for
the
vacaIon
site;
customers
bring
in
money
so
we
want
to
support
them
early
Favored
or
Disfavored
Are
we
trying
to
help
this
user
or
avoid
helping
them?
Example:
A
compeItor
is
a
disfavored
user;
we
might
add
watermarks
to
our
pictures
t
make
it
harder
for
compeItors
to
steal
them
Direct
or
Indirect
Does
this
user
operate
they
system
themselves
or
does
somebody
else
use
the
system
on
their
behalf?
Example:
Customer
is
a
direct
user,
while
a
Giq
Recipient
is
an
indirect
user

29. Primary
or
Secondary
Think
about
MyFakeVaca2on.info;
which
roles
are
Primary
and
which
are
Secondary?
Primary Secondary
1. Marke2ng
Manager:
All
the
markeIng
manager
wants
is
that
within
six
months
of
iniIal
release,
markeIng
starts
receiving
reports
monthly
reports
on
the
effecIveness
of
adverIsing
campaigns
2. Vaca2on
Creator:
A
member
of
the
markeIng
department
who
creates
a
vacaIon
by
uploading
a
set
of
compaIble
photographs
3. Hacker:
On
Day
1,
some
hackers
will
try
to
score
a
free
vacaIon
by
looking
for
bugs
in
the
checkout
process

30. Favored
or
Disfavored
For
MyFakeVaca2on.info;
which
stakeholders
are
Favored
and
which
are
Disfavored?
Favored Disfavored
1. Purchaser
of
a
vaca2on
2. Travelocity
3. Our
photography
partner
4. M4dd06h4x0r
(a
hacker)

31. Oqen
ForgoMen
Role
You
Won’t
Support
Every
Stakeholder,
But
Look
for
Key
Roles
Beyond
The
Obvious
Users.
Certain
roles
are
easy
to
forget
because
they’re
oqen
not
everyday
users
of
the
system,
but
they
an
important
impact
on
the
acceptability
of
the
system
as
a
whole:
• Administrators
• Operators
• Supervisors
• ExecuIves
• Auditors
• Hackers
and
other
disfavored
users

32. Dig
Deeper
Deeper
Knowledge
about
Users
Can
Suggest
Useful
Dis2nc2ons
in
Roles.
Understanding
these
characterisIcs
will
be
especially
helpful
in
designing
the
interface.
For
the
people
in
the
roles
you
iden2fy:
• What
are
their
goals?
• What
is
their
domain
exper2se?
• What
is
their
technology
exper2se?
• How
oTen
will
they
use
the
system?
• What
else
is
important
about
them?

33. How
to
Start?
Refine,
Revise,
Redistribute
Review
with
Project
Community
DraT
Stories
Use
in
Planning
Suppose
you’re
just
star2ng
to
write
stories.
How
and
where
do
you
start?
The
following
process
is
oTen
useful:
Does
this
look
familiar?
It’s
a
straighoorward
interpreta2on
of
a
standard
Agile
approach:
So
get
a
pen,
a
bunch
of
3”
x
5”
index
cards
or
a
whiteboard,
and
start
wri2ng!
Start
small
and
g
r
a
d
u
a
l
l
y
improve
your
work.

34. This
Sequence
of
Steps
Can
Help
You
Focus
Your
Story
Wri2ng.
A
Procedure
for
Story
Telling
1. Pick
any
area
of
the
product,
or
any
idea
from
your
charter.
2. Iden-fy
the
main
actor
(role),
or
some
leading
actor
• What
would
this
person
do?
• What
does
this
person
care
about?
• Ignoring
the
users
interface,
what
does
this
person
try
to
achieve?
Turn
the
answers
into
stories:
Role,
Ac2on,
Context
3. Does
a
story
depend
on
another,
unwriLen
story?
Write
that
story.
(We
prefer
independent
stories,
but
not
at
the
cost
of
missing
stories)
4. Is
there
some
overlap
between
stories?
No
worries.
Ideally,
you
can
redistribute
their
purpose
(to
make
them
independent);
if
not,
keep
them
as
is.

35. Being
Adventurous
Gather
a
group
of
people
and
brainstorm.
What
do
you
absolutely
have
to
do
to
accomplish
the
project’s
mission?
(psst:
Try
this
without
the
developers
in
the
room,
to
increase
the
focus
on
the
business
need)
Something
doesn’t
feel
right?
Tear
up
some
cards
for
good
measure
If
you
write
a
“wishful
thinking”
story:
What
would
the
soqware
have
to
support
before
that
story
could
ever
be
considered?
That’s
another
set
of
stories
Ignore
the
plan,
write
everything
down
Browse
the
table
of
contents
or
top-­‐level
headings
of
an
exisIng
spec,
recasIng
the
funcIonality
as
stories

36. Tips
• Review
your
charter
and/or
mission;
have
you
missed
anything
needed
to
support
it?
• Consider
the
project
community
–
users
and
stakeholders;
are
there
users
or
needs
you
haven’t
addressed?
• Review
what
you’ve
done
with
someone
else
• Look
at
your
domain
vocabulary.
Stories
you’ve
already
wriMen
will
have
people
(roles),
acIons,
and
objects.
Are
there
combinaIons
that
suggest
a
new
story
you
need?
• Shuffle
your
stories
in
various
ways:
By
role,
by
when
it
happens,
by
priority,
by
esImate.
Does
this
suggest
any
stories?
• Move
on.
If
you’re
not
used
to
wriIng
stories,
you
may
be
surprised
by
how
few
high-­‐
level
stories
you
need.
Maybe
it’s
Ime
to
move
on
to
stories
that
will
be
implemented
soon,
working
out
details
such
as
business
rules
or
tests
If
You
Get
Stuck
While
Wri2ng
Stories,
Try
These
Ideas:

37. Access
Your
SoluIon
• Did
you
cover
the
most
important
interac2ons?
• Is
each
user-­‐triggered
story
an
end-­‐to-­‐end,
user-­‐level
task?
(This
is
someImes
known
as
the
“Coffee
Break
Rule”:
Would
the
user
feel
like
it’s
a
good
Ime
to
take
a
coffee
break
aqer
compleIng
this
task?)
• Do
your
story
headings
follow
the
Role–Ac2on–Context
format?
• Are
your
headings
short
(typically
five
or
fewer
words,
rarely
if
ever
ten
words)?
• Are
your
headings
technology-­‐
and
[user]
interface-­‐independent?
• Are
you
seeing
a
domain-­‐level
vocabulary
emerge?

38. Summary
• There
are
a
variety
of
ways
to
organize
your
story
wri2ng.
Think
about
your
charter,
about
product
areas,
about
roles,
acIons,
and
contexts
• You’ve
pracIced
wriIng
stories
in
the
Role–Ac2on–Context
format
• You
can
use
the
self-­‐assessment
quesIons
to
help
you
asses
stories
in
live
projects

39. SECOND
BATCH
(REST
27
SLIDES)

40. System
and
Boundary
Consider
the
soTware
owned
and
run
by
a
small
doctor’s
office
to
manage
its
appointments,
medical
records,
and
insurance
claims.
Which
of
the
following
are
Inside
the
system
boundary
and
which
are
Outside?
Inside
Outside
1. Recep2onist
(who
schedules
appointments)
2. Database
(on
which
appointments
and
medical
records
are
stored)
3. Insurance
Claims
System
(to
which
our
system
transmits
claims
via
a
standard
protocol)
4. The
Internet
(over
which
encrypted
informa2on
is
sent)

41. CCL
–
Pillar,
System
and
Boundary

42. Requirements
Always
Emerge
It
is
impossible
to
know
all
requirements
in
advance
“Thinking
harder”
and
“thinking
longer”
can
uncover
some
requirements,
but
Emergent
requirements
are
those
are
users
cannot
iden2fy
in
advance
Every
project
has
some
emergent
requirements

43. So
What
Do
We
Do?
• We
Talk
More,
Write
Less
– But
write
some
if
you
need
to
• Show
SoTware
to
Users
• Acknowledge
that
Requirements
Emerge
– And
all
that
this
implies
• Progressively
Refine
Our
Understanding
of
the
Product
– And
express
this
progressive
refinement
in
the
product
backlog

44. Stories
Make
Great
Backlog
Items
Card
• Stories
are
tradiIonally
wriMen
on
note
cards
• May
be
annotated
with
notes,
esImates,
etc.
Conversa2on
• Details
behind
the
story
come
out
during
conversaIons
with
product
owner
Confirma2on
• Acceptance
tests
confirm
the
story
was
coded
correctly

45. Beat
the
System
There’s
usually
a
beLer
role
name
than
“The
System.”
You
may
be
tempted
to
have
a
role
“The
System,”
e.g.,
System
Generates
Daily
Summary
Report
Instead,
try
describing
the
human
who
makes
use
of
what
the
system
does:
Supervisor
Selects
Daily
Summary
Report.
It’s
even
beMer
if
you
can
idenIfy
what
the
human
is
going
to
do
with
the
result:
Supervisor
Adjusts
Schedule
Moving
from
the
domain
of
informaIon
processed
in
the
user’s
head
back
to
user
acIons
can
help
us
focus
beMer
on
the
user’s
true
needs
(Don’t
force
it,
though
–
“The
System”
may
be
the
most
expressive
name)

46. Humans
Only
!!!
A
role
can
correspond
to
a
human
or
an
automated
system.
Should
roles
be
filled
only
by
humans,
or
can
we
name
automated
systems?
Roles
can
be
either:
• We
like
the
role
to
menIon
the
human
when
the
human
feels
like
they’re
interacIng
with
the
system
(even
if
that
interacIon
is
through
another
system
such
as
a
web
browser)
• But
consider
the
system
boundary
(context
diagram);
if
an
automated
system
connects
to
our
system,
it’s
fine
to
name
that
system
as
the
role
• For
example,
out
pet
sales
system
“talks”
to
the
bank’s
automated
credit
card
processing
system,
so
Credit
Card
Processor
would
be
a
fine
role
name

47. Summary
• Roles
iden2fy
paLerns
of
usage;
different
roles
interact
differently
with
the
system
• Don’t
forget
important
roles
such
as
operators,
administrators,
and
auditors
• Deepen
your
understanding
of
the
user
by
considering
their
goals,
domain
and
technology
experIse,
and
frequency
of
use
• Use
adjec2ves
to
succinctly
idenIfy
roles
(Go
beyond
User)
• Rather
than
using
System
as
a
role,
try
to
iden2fy
who
acts
and
who
benefits

48. Where
are
the
Details
Process
mapping,
sketching,
and
storytes-ng
help
define
a
story’s
details.
The
heart
of
a
story
is
the
high-­‐level
funcIonality
captured
in
the
headline,
but
that
doesn’t
define
funcIonality
enough
to
just
go
implement
it
Implementa2on
requires
detailed
decisions
about
how
the
feature
will
work,
and
how
we’ll
know
it’s
done
User
stories
don’t
come
with
a
built-­‐in
method
for
these
decisions:
Every
team
is
different,
and
there
are
many
approaches
We’ll
briefly
explore
three
techniques
that
many
teams
have
found
helpful:
Process
Mapping,
Sketching,
and
Storytes2ng

49. Process
Mapping:
Follow
the
Object
• Triggers,
pulses,
and
audio
are
the
key
objects
• This
map
shows
how
a
trigger
goes
to
a
sound
generator,
and
its
audio
goes
to
a
mixer;
the
drum
clock
generates
a
pulse
that
goes
through
a
paMern
sequencer
that
drives
drum
audio,
which
goes
to
its
own
volume
control
and
the
mixer;
then
all
audio
goes
to
a
master
volume
control
and
out
to
a
speaker
• One
way
to
figure
out
should
happen
is
to
follow
the
object;
track
an
object
as
it
moves
through
–
and
is
transformed
by
–
the
system
• Consider
an
electronic
keyboard
with
a
built-­‐in
rhythm
secIon
where
you
can
set
the
drummer
up
with
a
loud
bossa
nova,
then
play
your
tune
on
the
keyboard
What
do
we
find
when
we
map
the
objects?

50. Triggers,
pulses,
and
audio
are
the
key
objects
This
map
shows
how
a
trigger
goes
to
a
sound
generator,
and
its
audio
goes
to
a
mixer;
the
drum
clock
generates
a
pulse
that
goes
through
a
paMern
sequencer
that
drives
drum
audio,
which
goes
to
its
own
volume
control
and
the
mixer;
then
all
audio
goes
to
a
master
volume
control
and
out
to
a
speaker
Modern
keyboards
work
more
in
the
digital
domain,
but
that’s
irrelevant
to
the
main
point;
in
process
mapping
we
idenIfy
(and
devise)
the
moIon
and
transformaIon
of
objects
in
the
system
Follow
an
objet
to
find
its
movement
through
&
transforma2on
by
the
system.
Keyboard
Sound
Generator
Clock
Drum
Sound
Generator
PaLern
Sequencer
Rhythm
Volume
Mixer
Overall
Volume
Trigger
Audio
Pulse
Audio
Trigger
Audio
Audio
Audio
Speaker
(Audible
Sound)

51. Watch
the
People
Watching
people
gives
a
different
perspec2ve
on
the
value
stream
(compared
to
focusing
on
key
objects
such
as
transacIons).
Focusing
on
people
lets
you
ask
them
several
key
quesIons:
1. What
do
you
do
in
the
normal
case?
(This
may
reveal
places
the
system
can
ease
or
eliminate
work)
2. Are
these
special
cases
or
excep2ons
that
are
handled
differently?
How
do
they
work?
(This
may
reveal
process
flows
you
didn’t
know
about)
3.
What
else
do
you
do?
(This
may
reveal
key
objects
and
opportuniIes
you
weren’t
aware
of)
Objects
usually
carry
the
value,
but
people
give
you
key
insights.
A
map
of
the
flow
of
items
and
the
processes
that
work
with
them
can
be
a
very
useful
tool.

52. Remembrance
of
Things
Past
Data-­‐intensive
systems
require
details
about
where
to
find
and
store
data.
• Objects
and
people
are
interesIng,
but
we
oqen
also
need
to
map
the
data
that’s
been
remembered
by
the
system
• For
data-­‐intensive
systems,
working
out
where
to
find
data
is
a
key
challenge
• Some
feeds,
databases,
and
so
on
are
outside
and
others
inside
the
system
boundary.
As
usual,
our
context
maMers
• The
level
of
detail
depends
on
the
stage
• In
early
planning,
it’s
enough
to
know
“We
can
get
that
data
somewhere.”
For
implementaIon,
we
need
details
about
where
the
data
is
and
the
transformaIons
it
needs

53. StorytesIng
Storytests
help
create
the
meaning
of
a
story.
Storytests
are
tests
in
the
language
of
the
domain,
wriMen
to
clarify
a
story
They
aren’t
meant
to
be
exhausIve
but
to
communicate
a
story’s
essence
ImplementaIon
requires
details,
but
less
is
needed
to
understand
and
esImate
stories
Tests
are
not
ripe
apples
on
a
tree,
waiIng
to
be
plucked
and
used;
rather,
creaIng
tests
helps
create
the
meaning
of
the
story
What
do
we
do
with
storytests?
Concrete
examples
are
great
for
helping
discuss
stories,
and
are
prime
candidates
for
automaIon

54. Best
Ideas
Where
do
you
get
your
best
ideas
for
func2onality?
(Your
opinion;
there’s
no
single
right
answer)
Building
models
of
users
and/or
ac2vi2es
Watching
users
in
ac2on
(doing
their
work)
Brainstorming,
alone
or
with
others
Listening
to
what
users
tell
us
they
need

55. Layout
Overall
System
As
you
proceed,
your
pile
of
stories
will
grow
and
you’ll
rip
up
some
stories
It
helps
to
organize
the
cards
according
to
some
criterion
• Theme
• Category
• Flow
• NavigaIon
• EvoluIonary
Path
• Release
or
IteraIon
WriIng
headings
according
to
the
Role-­‐Ac2on-­‐
Context
formula
helps
a
lot
here
You
can
also
use
paper
mockups
of
screens
and
flow
Organize
your
stories
to
reveal
the
big
picture
The
example
on
the
right
shows
how
a
user
would
navigate
in
the
new
applicaIon

56. Priori2zing
the
Product
Backlog

57. The
Product
Backlog
Iceberg
A
descripIon
of
desired
funcIonality
told
from
the
perspecIve
of
the
user
or
customer
User
Story
A
large
user
story
Epic
A
collecIon
of
related
user
stories
Theme

58. How
Much
Detail?
Process
Fixed
Input
Must
be
described
in
just
enough
detail
to
be
turned
into
the
output
by
the
process
Output
Fixed
Just-­‐in-­‐2me
just-­‐enough

59. What
Makes
a
Good
Story?
Independent
I
Negotiable
N
Valuable
V
Estimatable
E
Sized Appropriately
S
Testable
T

60. • Dependencies
lead
to
problems
esImaIng
and
prioriIzing
• Can
ideally
select
a
story
to
work
on
without
pulling
in
18
other
stories
Independent
• Stories
are
not
contracts
• Leave
or
imply
some
flexibility
Nego2able
• To
users
or
customers,
not
developers
• Rewrite
developer
stories
to
reflect
value
to
users
or
customers
Valuable
• Because
plans
are
based
on
user
stories,
we
need
to
be
able
to
esImate
them
Es2matable
• Small
enough
to
complete
in
one
sprint
if
you’re
about
to
work
on
it
• Bigger
if
further
off
on
the
horizon
Sized
Appropriately
• Testable
so
that
you
have
a
easy,
binary
way
of
knowing
whether
a
story
is
finished
• Done
or
not
done;
no
“parIally
finished”
or
“done
except”
Testable
I
N
V
E
S
T

61. PrioriIzing
the
Product
Backlog
Three
Steps
Organize
Needs
into
Themes
Priori2ze
Themes
Assess
Importance
of
Each
Theme
1
2
3

62. Why
Themes?
OTen
Individual
Stories
Cannot
be
Priori2zed
Against
Each
Other
• The
‘A’
key
or
the
‘E’
key?
• Tables
or
Undo?
• The
leq
front
wheel
or
the
right
front
wheel?
• Increased
leg
room
or
a
larger
engine?
What’s
More
Important
in
a
Word
Processor?
What’s
More
Important
on
a
Car?
1
2

63. Eliminate
redundant
stories
Write
each
story
on
its
own
note
card
or
post-­‐it
Label
each
group
with
a
theme
name
Group
similar
stories
Review
the
results
If
you
have
a
lot
of
themes
or
have
small
themes,
consider
making
themes
of
themes
Steps
for
Organizing
into
Themes
If
you
started
with
a
story-­‐wri2ng
workshop,
you
may
already
have
themes.

64. Affinity
Grouping
Distribute
cards
equally
to
all
par2cipants
• No
parIcular
paMern
to
how
you
do
this
Someone
reads
a
card
and
places
in
on
wall
/
table
• Others
look
for
similar
cards
and
add
them
to
it
Next
person
reads
a
card,
places
it,
and
others
place
similar
cards
with
it
Con2nue
repea2ng
un2l
out
of
cards

65. User
Story
Template
–
1
As
a
[user
role]
I
want
to
[goal]
• So
I
can
[reason]
• As
a
[type
of
user]
I
want
to
[perform
some
task]
so
that
I
can
[reach
some
goal]
Example:
• As
a
registered
user
I
want
to
log
in
• So
I
can
access
subscriber-­‐only
content

66. User
Story
Template
–
2
• Who
(user
role)
• What
(goal)
• Why
(reason)
– Gives
clarity
as
to
why
a
feature
is
useful
– Can
influence
how
a
feature
should
funcIon
– Can
give
you
ideas
for
other
useful
features
– That
support
the
user's
goals

67. THANK
YOU!