5. Product
Vision
• Shared
by
All
• Desirable
and
InspiraIonal
• Clear
and
Tangible
• Broad
and
Engaging
• Short
and
Sweet
6. Product
Vision
–
Elevator
Pitch
For
(target
customer)
Who
(statement
of
the
need
or
opportunity)
The
(product
name)
is
a
(product
category)
That
(key
benefit,
compelling
reason
to
buy)
Unlike
(primary
compeIIve
alternaIve)
Our
product
(statement
of
primary
differenIaIon)
h0p://www.joelonso8ware.com/arIcles/JimHighsmithonProductVisi.html
7. Product
Vision
Box
• As
the
name
suggests…
• Describes
the
top
2-‐3
features
of
product
9. Product
Backlog
• A
combined
list
of
all
desired
work,
including
user
focused
stories,
technical
work,
features
&
ideas
• Everything
is
expressed
in
User
Stories
• List
is
prioriIzed
by
the
Product
Owner
• Product
Owner
keeps
it
organized
with
the
team’s
help
• Anyone
can
add
items
to
the
backlog
• Evolves
over
Ime
• Always
in
progress
10. Benefits
of
Product
Roadmap
• Helps
communicate
how
you
see
the
product
develop.
• Helps
align
the
product
and
the
company
strategy.
• Helps
manage
the
stakeholders
and
coordinate
the
development,
markeIng,
and
sales
acIviIes.
• Facilitates
effecIve
porFolio
management,
as
it
helps
synchronise
the
development
efforts
of
different
products.
• Supports
and
complements
the
product
backlog.
This
allows
the
backlog
to
focus
on
the
tacIcal
product
development
aspects.
h0p://www.romanpichler.com/blog/agile-‐product-‐management-‐tools/agile-‐product-‐roadmap/
11. Product
Backlog
• The
agile
product
backlog
is
a
prioriIzed
features
list,
containing
short
descripIons
of
all
funcIonality
desired
in
the
product.
• When
using
Scrum,
it
is
not
necessary
to
start
a
project
with
a
lengthy,
upfront
effort
to
document
all
requirements.
• Typically,
a
Scrum
team
and
its
product
owner
begin
by
wriIng
down
everything
they
can
think
of
for
agile
backlog
prioriIzaIon.
This
agile
product
backlog
is
almost
always
more
than
enough
for
a
first
sprint.
The
Scrum
product
backlog
is
then
allowed
to
grow
and
change
as
more
is
learned
about
the
product
and
its
customers.
• h0p://www.mountaingoatso8ware.com/
scrum/product-‐backlog
12. Who
owns
Product
Backlog?
h0p://www.romanpichler.com/blog/agile-‐product-‐management-‐tools/agile-‐product-‐roadmap/
13. ….should
be
“DEEP”
• Emergent
• PrioriIzed
• EsImated
• Detailed
Appropriately
D
E
E
P
14. From
Product
Roadmap
to
Product
Backlog
h0p://www.romanpichler.com/blog/agile-‐product-‐management-‐tools/agile-‐product-‐roadmap/
15. Sprint
Backlog
• User
Stories
selected
by
The
Team
• Will
be
built
in
next
Sprint
• Fully
EsImated
• Divided
into
Tasks
21. As
a
frequent
flyer,
I
want
to
be
able
to
view
current
offers
in
terms
of
mileage
points
so
that
I
can
redeem
them.
22. Acceptance
Criteria
22
Given <System State>
when <an event occurs>
then <an outcome happens>
23. The
Three
C’s
of
a
User
Story
• The
story
itself
• A
promise
to
have
a
conversaIon
at
the
appropriate
Ime
Card
• The
requirements
themselves
communicated
from
the
Product
Owner
to
the
Delivery
Team
via
a
conversaIon
• Write
down
what
is
agreed
upon
ConversaIon
• The
Acceptance
Criteria
for
the
story
• How
the
Delivery
Team
will
know
they
have
completed
the
story
ConfirmaIon
24. What
makes
a
good
User
Story?
Independent
of
all
others
NegoIable
not
a
specific
contract
for
features
Valuable
or
ver2cal
EsImable
to
a
good
approxima2on
Small
so
as
to
fit
within
an
itera2on
Testable
in
principle,
even
if
there
isn’t
a
test
for
it
yet
h0p://guide.agilealliance.org/guide/invest.html
25. Scenarios,
User
Case,
User
Story
Use
Case:
Customer
walks
to
the
restaurant
Customer
enters
the
restaurant
Customer
finds
a
seat
at
the
bar
Customer
scans
the
menu
Customer
selects
a
beer
Customer
orders
selected
beer
Bartender
takes
order
Bartender
pours
beer
Bartender
delivers
beer
User
drinks
beer
User
pays
for
beer
User
Story:
A
user
wants
to
find
a
bar,
to
drink
a
beer.
h0p://www.cloudforestdesign.com/2011/04/25/introducIon-‐user-‐stories-‐user-‐personas-‐use-‐cases-‐whats-‐the-‐difference/
Scenario:
Josh
is
a
30
something
mid-‐level
manager
for
an
ad
agency,
metro-‐sexual
and
beer
aficionado.
He
likes
to
try
new
and
exoIc
beers
in
trendy
locaIons.
He
also
enjoys
using
a
variety
of
social
apps
on
his
smart
phone.
He
reads
a
review
on
Yelp
of
a
new
burger
&
beer
joint
downtown
with
over
100
beers
on
tap,
and
decides
to
go
walk
over
a8er
work
and
check
it
out.
27. Themes
• We
could
put
a
rubber
band
around
that
group
of
stories
I
wrote
about
monthly
repor2ng
and
we'd
call
that
a
“theme.”
Some2mes
it's
helpful
to
think
about
a
group
of
stories
so
we
have
a
term
for
that.
S2cking
with
the
movie
analogy
above,
in
my
DVD
rack
I
have
filed
the
James
Bond
movies
together.
They
are
a
theme
or
grouping.
h0p://www.mountaingoatso8ware.com/blog/stories-‐epics-‐and-‐themes
29. Epics
• A
Scrum
epic
is
a
large
user
story.
There's
no
magic
threshold
at
which
we
call
a
parIcular
story
an
epic.
It
just
means
“big
user
story.”
I
like
to
think
of
this
in
relaIon
to
movies.
If
I
tell
you
a
parIcular
movie
was
an
“acIon-‐adventure
movie”
that
tells
you
something
about
the
movie.
There's
probably
some
car
chases,
probably
some
shooIng,
and
so
on.
It
tells
you
this
even
though
there
is
no
universal
definiIon
that
we've
agreed
to
follow,
and
that
an
acIon-‐adventure
movie
must
contain
at
least
three
car
chases,
at
least
45
bullets
must
be
shot,
and
….
• So,
“epic”
is
just
a
label
we
apply
to
a
large
story.
Calling
a
story
an
epic
can
someImes
convey
addiIonal
meaning.
Suppose
you
ask
me
if
I
had
Ime
yesterday
to
write
the
user
stories
about
the
monthly
reporIng
part
of
the
system.
“Yes,”
I
reply,
“but
they
are
mostly
epics.”
That
tells
you
that
while
I
did
write
them,
I
didn't
get
the
chance
to
break
most
of
them
down
into
stories
that
are
probably
small
enough
to
implement
directly.
h0p://www.mountaingoatso8ware.com/blog/stories-‐epics-‐and-‐themes
30. User
Stories
• A
user
story
is
simply
something
a
user
wants.
User
stories
are
more
than
just
text
wri0en
on
an
index
card
but
for
our
purposes
here,
just
think
of
user
story
as
a
bit
of
text
saying
something
like,
“Paginate
the
monthly
sales
report”
or,
“Change
tax
calculaIons
on
invoices.”
• Many
teams
have
learned
the
benefits
of
wriIng
user
stories
in
the
form
of:
– As
a
<type
of
user>
– I
<want/can/am
able
to/need
to/etc.>
– so
that
<some
reason>.
• But
it
is
not
necessary
that
a
user
story
be
wri0en
that
way.
h0p://www.mountaingoatso8ware.com/blog/stories-‐epics-‐and-‐themes
33. Minimal
Marketable
Feature
• A
Minimal
Marketable
Feature
(MMF)
is
a
feature
that
is
minimal,
because
if
it
was
any
smaller,
it
would
not
be
marketable.
A
MMF
is
marketable,
because
when
it
is
released
as
part
of
a
product,
people
would
use
(or
buy)
the
feature.
• An
MMF
is
different
than
a
typical
User
Story
in
Scrum
or
Extreme
Programming.
Where
mulIple
User
Stories
might
be
coalesced
to
form
a
single
marketable
feature,
MMFs
are
a
li0le
bit
bigger.
O8en,
there
is
a
release
a8er
each
MMF
is
complete.
• An
MMF
doesn’t
decompose
down
into
smaller
sub-‐feature,
but
it
is
big
enough
to
launch
on
its
own.
• A
MMF
can
be
represented
as
a
User
Story
—
a
short,
one-‐sentence
descripIon.
35. MoSCoW
• M
-‐
MUST:
Describes
a
requirement
that
must
be
saIsfied
in
the
final
soluIon
for
the
soluIon
to
be
considered
a
success.
• S
-‐
SHOULD:
Represents
a
high-‐priority
item
that
should
be
included
in
the
soluIon
if
it
is
possible.
This
is
o8en
a
criIcal
requirement
but
one
which
can
be
saIsfied
in
other
ways
if
strictly
necessary.
• C
-‐
COULD:
Describes
a
requirement
which
is
considered
desirable
but
not
necessary.
This
will
be
included
if
Ime
and
resources
permit.
• W
-‐
WON'T:
Represents
a
requirement
that
stakeholders
have
agreed
will
not
be
implemented
in
a
given
release,
but
may
be
considered
for
the
future.
(note:
occasionally
the
word
"Won't"
is
subsItuted
for
"Would"
to
give
a
clearer
understanding
of
this
choice.
37. Spliung
User
Stories
h0p://gojko.net/2012/01/23/spliung-‐user-‐stories-‐the-‐hamburger-‐method/
49. Scenarios
• A
usage
scenario,
or
scenario
for
short,
describes
a
real-‐world
example
of
how
one
or
more
people
or
organizaIons
interact
with
a
system.
• They
describe
the
steps,
events,
and/or
acIons
which
occur
during
the
interacIon.
• Usage
scenarios
can
be
very
detailed,
indicaIng
exactly
how
someone
works
with
the
user
interface,
or
reasonably
high-‐level
describing
the
criIcal
business
acIons
but
not
the
indicaIng
how
they’re
performed.
53. Story
Points
• Agile
teams
generally
prefer
to
express
esImates
in
units
other
than
the
Ime-‐honored
"man-‐day"
or
"man-‐hour".
Possibly
the
most
widespread
unit
is
"story
points".
• One
of
the
chief
reasons
is
the
use
of
velocity
for
planning
purposes.
"Velocity",
in
the
sense
Agile
teams
use
the
term,
has
no
preferred
unit
of
measurement,
it
is
a
dimensionless
quanIty.
Velocity
allows
teams
to
compute
the
expected
remaining
duraIon
of
the
project,
as
a
number
of
iteraIons,
each
iteraIon
delivering
some
amount
of
features.
• Another
important
reason
has
to
do
with
the
social
and
psychological
aspects
of
esImaIon:
using
units
such
as
story
points,
emphasizing
relaIve
difficulty
over
absolute
duraIon,
relieves
some
of
the
tensions
that
o8en
arise
between
developers
and
managers
around
esImaIon:
for
instance,
asking
developers
for
an
esImate
then
holding
them
accountable
as
if
it
had
been
a
firm
commitment.
h0p://guide.agilealliance.org/guide/nuts.html
54. EsImaIon
Mainly
two
forms
of
esImaIon
– Analogous
EsImaIon
[T-‐Shirt
Sizing
-‐
S,M,L,XL]
• This
Story
is
like
another
Story
(maybe
a
li0le
more
difficult,
maybe
a
li0le
less)
• Give
this
Story
a
comparable
esImated
value.
• EsImate
against
mulIple
Stories
of
the
same
effort.
• Analogous
esImaIon
is
successful
due
to
our
inherent
ability
to
be0er
measure
relaIve
size
than
absolute
size.
– Planning
Poker
• Each
esImator
is
given
a
deck
of
cards,
each
card
contains
a
valid
esImate.
• Fib
––1,2,3,5,8,13,20,301,2,3,5,8,13,20,30
• Story
is
read
and
discussed
briefly
• Each
esImator
selects
a
card
that
reflects
their
esImate.
• Cards
are
turned
over
for
all
to
see.
• Discussion
takes
place
•
Re-‐esImate
to
try
to
get
convergence.
55. Affinity
EsImaIng
Guidelines
Break
up
into
small
teams
of
2-‐4
Discuss
2-‐3
stories
so
there
is
a
sense
of
them
Find
an
iniNal
comparaNve
story
• If
team
is
already
SprinIng,
find
a
small-‐ish
one
already
completed
that
was
a
really
good
esImate;
use
that
esImate
• Or
find
a
fully
understandable
story
and
fully
task
it
out;
call
it
either
a
2
or
a
3
Without
conversaNon,
the
enNre
team
puts
all
the
stories
on
a
big
wall
• Smallest
at
the
right
and
largest
on
the
le8
compared
to
iniIal
story
• Anyone
can
move
anyone
else’s
story
posiIon
As
acNvity
subsides,
put
a
scaled
number
line
up
SeQle
on
esNmates
for
boundary
stories
and
epics