User Stories Writing Workshop

1.
openware
Stefano
Leli
Fabio
Armani
stefano.leli@gmail.com armani.fabio@gmail.com
@sleli @fabioarmani

2. What
is
a
User
Story?

3. User
Story:
is
• A
user
story
is
a
very
high-­‐level
defini@on
of
a
requirement,
containing
just
enough
informa@on
so
that
the
developers
can
produce
a
reasonable
es@mate
of
the
effort
to
implement
it.

4. User
Story
• Define
a
valuable
user
value
story
• implement
and
test
it
in
a
short
itera5on
• demonstrate/and
or
deliver
it
to
the
user
• capture
feedback
• learn
• repeat
forever!

5. What
a
"User
Story"
is
not

6. User
Story:
is
not
• It
is
not
a
use
case
or
a
soIware
requirement,
i.e.
a
formal
and
long
specifica@on
document
• One
of
the
biggest
misunderstandings
with
user
stories
is
how
they
differ
from
tradi@onal
requirements
specifica@ons

8. Ini@al
User
Stories
(informal)

9. Example
User
Stories
Students
can
purchase
monthly
parking
passes
online.
Parking
passes
can
be
paid
via
credit
cards.
Parking
passes
can
be
paid
via
PayPal
™.
Professors
can
input
student
marks.
Students
can
obtain
their
current
seminar
schedule.
Students
can
order
official
transcripts.
Students
can
only
enroll
in
seminars
for
which
they
have
prerequisites.
Transcripts
will
be
available
online
via
a
standard
browser.

11. Ini@al
User
Stories
(formal)

12. As
<type
of
user>,
<func5on>
so
that
I
can
achieve
<some-­‐goal>

15. 3
C

16. 3
C
Card,
conversa@on
&
confirma@on

17. Card

18. user
stories
need
to
be
short
and
Card
concise
enough
so
that
they
can
fit
on
a
single
card

20. Conversa@on

21. Conversa@on
the
conversa@on
is
much
much
more
important
than
the
story
itself

23. Confirma@on

24. Confirma@on
by
defini@on,
user
stories
must
be
testable

26. INVEST
in
your
User
Stories

27. INVEST
in
User
Stories
• Independent
Avoid
dependencies
with
other
stories
Write
stories
to
establish
founda@on
Combine
stories
if
possible
to
deliver
in
a
single
itera@on
• Nego+able
Stories
are
not
a
contract
Too
much
detail
up
front
gives
the
impression
that
more
discussion
on
the
story
is
not
necessary
Not
every
story
must
be
nego@able,
constraints
may
exist
that
prevent
it
• Valuable
Each
story
should
show
value
to
the
Users,
Customers,
and
Stakeholders

28. INVEST
in
User
Stories
• Es+mable
Enough
detail
should
be
listed
to
allow
the
team
to
es@mate
The
team
will
encounter
problems
es@ma@ng
if
the
story
is
too
big,
if
insufficient
informa@on
is
provided,
or
if
there
is
a
lack
of
domain
knowledge
• Sized
Appropriately
Each
story
should
be
small
enough
to
be
completed
in
a
single
itera@on
Stories
that
may
be
worked
on
in
the
near
future
should
be
smaller
and
more
detailed
Larger
stories
are
acceptable
if
planned
further
out
(Epics)
• Testable
Acceptance
criteria
should
be
stated
in
customer
terms
Tests
should
be
automated
whenever
possible
All
team
members
should
demand
clear
acceptance
criteria

29. User
Stories
(planning)

30. Epics

31. Epics
• Epics
are
large
user
stories,
typically
ones
which
are
too
big
to
implement
in
a
single
itera@on
and
therefore
they
need
to
be
disaggregated
into
smaller
user
stories
at
some
point.

32. Themes

33. Themes
• A
theme
is
a
collec@on
of
related
user
stories.
• For
example,
for
a
university
registra@on
system
there
might
be
themes
around
students,
course
management,
transcript
genera@on,
grade
administra@on,
financial
processing.
• Themes
are
oIen
used
to
organize
stories
into
releases
or
to
organize
them
so
that
various
sub-­‐teams
can
work
on
them.

37. Kano
Model
According
to
Kano,
there
are
3
classes
of
features:
• Prerequisites
-­‐
If
your
product
doesn’t
have
these
features,
it
will
immediately
be
removed
from
considera@on.
Who
wants
a
house
without
a
bathroom?
• Linear
Features
-­‐
The
more
the
be]er,
but
their
higher
the
cost.
A
family
that
wants
three
bedrooms
will
not
consider
a
house
with
one,
but
they
might
consider
a
house
with
2
or
4
bedrooms.
• Exciters
-­‐
Unique
features
which
only
this
product
has
and
which
convince
the
customer
to
say
“Yes!
I
want
it!
This
one
and
no
other”

41. CMS
1.0
(Hands-­‐On)

43. User
Story
(spligng)

50. CMS
1.1
(Hands-­‐On)

52. Benefits

53. Benefits
• XP
and
other
agile
methodologies
favor
face-­‐
to-­‐face
communica@on
over
comprehensive
documenta@on
and
quick
adapta@on
to
change
instead
of
fixa@on
on
the
problem.

54. User
stories
achieve
this
by:
• Being
very
short.
They
represent
small
chunks
of
business
value
that
can
be
implemented
in
a
period
of
days
to
weeks.
• Allowing
developer
and
the
client
representa@ve
to
discuss
requirements
throughout
the
project
life@me
• Needing
very
li]le
maintenance
• Only
being
considered
at
the
@me
of
use
• Maintaining
a
close
customer
contact
• Allowing
projects
to
be
broken
into
small
increments
• Being
suited
to
projects
where
the
requirements
are
vola@le
or
poorly
understood.
Itera@ons
of
discovery
drive
the
refinement
process.
• Making
it
easier
to
es@mate
development
effort

55. Limita@ons

56. Limita@ons
Some
of
the
limita@ons
of
user
stories
in
agile
methodologies:
• They
can
be
difficult
to
scale
to
large
projects
• They
are
regarded
as
conversa@on
starters

57.
openware
Stefano
Leli
Fabio
Armani
stefano.leli@gmail.com armani.fabio@gmail.com
@sleli @fabioarmani