Riteniamo, che non vi sia dubbio sul fatto le User Story (introdotte da eXtreme Programming) e il Product Backlog (definito in Scrum) rappresentino due portentosi strumenti per la gestione agile dei requisiti e delle specifiche sia funzionali che non funzionali. Ma … hanno alcuni limiti. Ad esempio, nonostante le notevoli caratteristiche del Product Backlog, la sua unidimensionalità non consente di creare un modello dei requisiti adatto a scalare e che consenta di gestire le dipendenze che possono essere presenti tra i vari elementi che lo costituiscono. In questo workshop presenteremo e utilizzeremo un altro potente strumento che spesso utilizziamo durante gli User Story Workshop sia in fase d’Inception, sia all’inizio di ogni nuova release di un prodotto. Si chiama “User Story Mapping”. Ci divertiremo con voi ad utilizzarlo in una simulazione che partendo dalla Vision di un prodotto ci consentirà di mappare i bisogni di un numero selezionato di utenti su un insieme di funzionalità organizzate in una mappa. Inoltre vedremo come sia possibile utilizzare questo strumento per gestire le diverse release di un prodotto a partire dal così detto “Walking Skeleton” fino alle successive MMF (Mininum Markatable Feature) Sapete cos’è il modello di Kano, FURPS+, o come il nome della capitale della Russia possa essere utilizzato per assegnare priorità alle diverse storie? Se vi abbiamo incuriosito, o se pensate che avere un nuovo strumento mentale da aggiungere alla vostra cassetta degli attrezzi potrebbe esservi utile, partecipate. Sarete certamente i benvenuti.

1. Armani
-­‐
Rodriguez
May
17
2014

2. Fabio
Armani
fabio.armani@icloud.com,
@fabioarmani
Andrea
Torino
Rodriguez
rodryz@gmail.com,
@agilerod

3. Why
• It
allows
you
to
see
the
big
picture
in
your
backlog.
• It
gives
you
a
be8er
tool
for
making
decisions
about
grooming
and
priori<zing
your
backlog.
• It
promotes
silent
brainstorming
and
a
collabora<ve
approach
to
genera<ng
your
user
stories.

4. Why
• It
encourages
an
itera<ve
development
approach
where
your
early
deliveries
validate
your
architecture
and
solu<on.
• It
is
a
great
visual
alterna<ve
to
tradi<onal
project
plans.
• It
is
a
useful
model
for
discussing
and
managing
scope.
• Allows
you
to
visualize
dimensional
planning
and
real
op<ons
for
your
project/product.

5. Silent
Brainstorming

6. Silent
Brainstorming

7. Silent
Brainstorming
• Decide
on
the
type
of
ques<on
• Step
1:
generate
ideas
individually.
One
idea
per
post-­‐it
• Step
2:
read
and
put
ideas
on
the
table
• Step
3:
group
the
ideas
(clustering)
• Step
4:
Name
each
group
• Step
5:
prepare
for
vo<ng
• Step
6:
each
person
votes
for
their
top
3
• Step
7:
facilitator
tallies
the
votes
• Step
8:
act
on
the
item(s)
with
the
highest
vote!

8. Dimensional
Planning

9. Dimensional
Planning
• In
Scrum
the
Product
Backlog
is
an
ordered
list
of
features.
Unfortunately
the
linearity
of
the
ordered
list
is
not
consistent
with
the
way
us
humans
think
about
problems.
• Problems
even
in
the
business
space
are
mul<-­‐
dimensional.
So,
we
probably
also
should
think
of
solving
our
problems
in
mul<ple
dimensions.
This
is
where
Dimensional
Planning
comes
in
handy
when
spliXng
Product
Backlog
Items
in
your
Product
Backlog
during
the
Refinement
or
Grooming
mee<ngs.

10. Dimensional
Planning
• In
Scrum
the
Product
Backlog
is
an
ordered
list
of
features.
Unfortunately
the
linearity
of
the
ordered
list
is
not
consistent
with
the
way
us
humans
think
about
problems.
• Problems
even
in
the
business
space
are
mul<-­‐
dimensional.
So,
we
probably
also
should
think
of
solving
our
problems
in
mul<ple
dimensions.
• This
is
where
Dimensional
Planning
comes
in
handy
when
spliXng
Product
Backlog
Items
in
your
Product
Backlog
during
the
Refinement
or
Grooming
mee<ngs.

11. Dimensional
Planning

12. Dimensional
Planning

13. Dimensional
Planning
From
dirt
road
to
flying
cars
• Dirt
road
• Cobblestone
road
• Asphalted
road
• Highway
• Flying
cars

14. Dimensional
Planning

16. Real
Op<ons
• How
and
when
(not)
to
make
decisions
• Defer
commitments

17. Problem
Customer
Supplier
Implement
Generate
op<ons
Test
and
choose
op<ons

18. Don’t
try
to
decide
too
fast!

20. Real
Op<ons
• Have
a
value
• Have
a
cost
(=
the
price
of
the
op<on)
• Have
a
price
(“strike
price”)
when
we
exercise
the
op<on
• Have
an
expira<on
date/condi<on
~
“Call
Op<on”
An
op<on
is
not
an
obliga<on

21. Grooming

23. Living
Charter
=
Chartering

24. How
to
create
a
User
Story
Map

25. Group
Task
Group
Task Task Task
Group
Task Task

27. Backbone

28. Walking
Skeleton

30. Some
defini<on
• The
post-­‐its
you
create
in
Step
2
are
the
User
Tasks
(blue
post-­‐its
in
the
diagram).
• The
groups
and
group
names
in
steps
3
and
4
are
the
User
Ac3vi3es
(orange
post-­‐its).
Jeff
calls
these
top
two
rows
the
backbone
and
walking
skeleton
of
your
applica<on.
• The
user
stories
(yellow
post-­‐its)
are
organized
under
each
User
Task
in
order
of
highest
to
lowest
priority
for
that
User
Task.
• The
chronological
order
of
how
users
will
typically
use
the
applica<on
goes
lej
to
right
(Time).

31. How
to
priori<ze
a
User
Story
Map

33. Story
…
Story
1
Story
2
Story
3
Sprint
N-­‐1
Sprint
N
Sprint
N+1
Story
3

34. Story
Slicing
Story
1
Story
2
Story
3
Story
4
Story
5
Story
6
Story
7
Story
8
Story
9
Sprint
N-­‐1
Sprint
N
Sprint
N+1
Wri<ng
story
tests
Automa<ng
story
tests
Implemen<ng
the
user
story

35. Risk
&
Assump<ons
• Where
are
the
risky
stories?
• Where
are
our
biggest
assump<ons?

37. Applying
Cynefin
• A
way
to
understand
complexity
is
that
ac<ng
in
the
space
causes
the
space
to
change,
and
cause
and
effect
can
only
be
understood
in
retrospect.

38. Applying
Cynefin
"When
you
start
wri<ng
tests,
or
having
discussions,
and
the
requirements
begin
changing
underneath
you
because
of
what
you
discover
as
a
result,
that’s
complex.
You
can
look
back
at
what
you
end
up
with
and
understand
that
it’s
much
be8er,
but
you
can’t
come
up
with
it
to
start
with,
nor
can
you
define
what
“be8er”
will
look
like
and
try
to
reach
it.
It
emerges
as
you
work."
"...
This
is
the
land
of
high-­‐feedback,
risk
and
innova<on:
generally
stuff
you’ve
never
done
before,
anything
that
the
business
are
unsure
about,
new
technologies,
etc."

39. Re-­‐priori3ze
o;en

40. How
to
do
it?
1. Divide
into
groups
of
3-­‐5
people
2. Start
by
gathering
“things
people
do”
–
the
tasks.
Write
them
down
individually
and
then
read
them
aloud
to
your
group
– Likely
they
start
with
a
verb.
– These
are
high
level
user
stories
called
“Tasks”
(walking
skeleton)
– This
forms
your
story
map
skeleton
3. Group
them
silently
(simply
because
it
is
faster)
4. Name
the
groups
and
lay
them
out
in
order
of
<me
(lej
to
right)
– These
are
called
“User
Ac3vi3es”
(backbone)

41. How
to
do
it?
5. Add
more
detailed
user
stories
below
the
main
tasks
6. Priori<ze
top
to
bo8om
7. Break
into
releases
8. Assign
values

42. Itera<ve
1 2 3 4 5
Credit:
Jeff
Pa8on
Incremental

45. thanks

46. Fabio
Armani
www.open-­‐ware.org
f.armani@open-­‐ware.org,
@fabioarmani
Andrea
Torino
Rodriguez
rodryz@gmail.com,
@agilerod