AgileItera+ons: Planning&Repor+ng MovingFromUserStories - PowerPoint PPT Presentation

Agile
Itera+ons:
 Planning
&
Repor+ng
 Moving
From
User
Stories
 To
Story
Points
&
Release
Plans


Agile
Planning
 • Agile
Development
implementa+ons
can
vary
from
organiza+on
to
organiza+on.


 • Essen+ally
it
is
a
way
of

 – breaking
down
development
into
successively
smaller
chunks

 – to
tease
out
concrete
func+ons

 and
development
targets

 – and
then
trying
to
address
these
by
focused
development
cycles
we
call
itera+ons.
 – • Some
specific
Agile
Development
Principles
we
strive
for:
 – The
80/20
rule
 • This
focuses
on
the
most
achievable
and
beneficial
features
right
up
front.
 – Iterate
a
problem
with
frequent
small
releases
 This
keeps
usable
soNware
in
planners
hands
that
can
be
tested
and
available
for
feedback
as
the
applica+on
 • comes
together.
 Engage
the
Users/Planners
 – • With
small
frequent
releases
we
can
go
back
to
the
planner
or
user
to
test
and
get
feedback
for
upcoming
 itera+ons.
 Adjust
Planning
as
you
go

 – With
a
focus
on
itera+ons
we
can
adjust
our
development
to
align
with
tes+ng
results
 • • Most
of
these
are
summed
up
rather
well
in
the
Agile
Manifesto:
 Individuals
and
interac/ons 
over
processes
and
tools
 – Working
so4ware 
over
comprehensive
documenta+on
 – Customer
collabora/on
 over
contract
nego+a+on
 – – Responding
to
change
 over
following
a
plan
 CS‐5484/Emory
University
 2


Sample
User
Story
“#001”
 The
need :
The
finding
aids
database
is
the
primary
search
and
discovery
tool
 for
the
manuscript
and
archives
collec9ons
held
in
MARBL.

The
same
 database
is
also
used
for
the
Irish
Literature
website,
a
mul9‐ins9tu9onal
 union
database
of
finding
aids
for
Irish
Literary
collec9ons.

The
website
is
 currently
slow
for
certain
tasks,
and
does
not
allow
proximity
searching,
user
 selected
Boolean
searching,
or
fielded
searching.
These
features
are
needed
 for
the
types
of
precise
searching
desired
by
scholarly
users.
Users
tell
MARBL
 that
because
the
database
is
slow
and
doesn't
allow
the
searches
they
need
to
 do,
they
call
MARBL
directly
and
ask
them
to
find
things
for
the
user.
In
 addi9on,
the
2009
MARBL
user
survey
shows
that
users
want
links
from
 subject
terms
in
a
finding
aid
to
other
finding
aids
with
those
subject
terms.
 ‐
From
the
MARBL
Finding
Aids
project
 CS‐5484/Emory
University
 3


Story
Points
from
#001:

 Isolate
the
Requirements
 • The
website
is
currently
slow
 – for
certain
tasks,
 • does
not
allow
proximity
searching,

 • user
selected
Boolean
searching,
 • fielded
searching.

 • You
might
need
more
informa+on:
 – Get
more
details
from
the
user
about
specific
implementa+on
 examples
 – See
slide
6
for
what
this
user
provided
the
team
 CS‐5484/Emory
University
 4


Story
Points
from
#001:

 Es+mate
Complexity,
Priority
 1. The
website
is
currently
slow
for
certain
 1. System
tuning:

 tasks,
 1. very
complex
(9?);

 2. does
not
allow
proximity
searching,

 2. Priority:
last
(may
change
aNer
fixes
to
 code)
 3. user
selected
Boolean
searching,
 2. Proximity
searching:
 4. fielded
searching.
 
 1. Needs
search
engine
update;
semi‐ complex
(5?)
 2. May
need
to
have
search
engine
 customized
for
content
(7?:
need
to
 learn
that
API)
 3. Priority:
2 nd 
 3. Boolean
searching:
 1. Mid‐complexity
(4?)
 2. May
be
impacted
by
new
search
 engine
 3. Priority
=
1
(easiest
to
start
from)
 4. Fielded
searching:
 1. Etc……
 CS‐5484/Emory
University
 5


Story
Points
from
#001:

 Convert
to
Story
Points
(Dev
Points)
 The
website
is
currently
slow
for
certain
tasks,
does
not
allow
proximity
searching,
user
selected
Boolean
searching,
fielded
 • searching
 These
were
in
fact
amended
by
the
user
with
addi9onal
informa9on
and
user
details/stories:
 Users
can
access
advanced
search
page.
 • Users
can
find
search
help
on
the
advanced
search
page.
 • Users
can
search
mul+‐word
phrases
with
Boolean
and
proximity
search.
 • • Users
can
select
proximity
different
than
the
default
[Stakeholders
select
the
default].
 • Users
can
search
exact
phrase.
 Users
can
search
for
phrase
words
in
any
order.
 • User
searches
return
a
list
of
finding
aids
with
match
frequency,
in
descending
frequency
order.
 • Users
can
select
a
finding
aid
to
view
from
the
list.
 • • Users
can
search
within
a
single
finding
aid.
 • Users
can
see
the
number
of
matches
in
each
sec+on
of
the
finding
aid.
 Users
can
easily
find
search
results
because
they
are
highlighted.
 • Users
can
retrieve
an
alphabe+cal
browse
list
in
less
than
5
seconds,
based
on
the
first
leler
of
a
stakeholder
specified
field.
 • Users
can
search
on
specified
EAD
fields
(field
list
from
stakeholder).
 • • Users
can
access
a
Table
of
Contents
for
the
site
in
a
side
column
of
the
web
page.
 • Users
can
receive
a
PDF
of
a
finding
aid
in
less
than
20
seconds.
 • Users
can
click
on
a
subject
heading
in
a
single
finding
aid
to
discover
other
finding
aids
with
the
same
subject
heading.
 Users
can
search
a
single
repository
(MARBL,
Pils,
University
Archives).
 • CS‐5484/Emory
University
 6


Grouping
&
Es+ma+ng
 • Grouping
can
be
by:
 – Code
similarity
among
story
points
 – Shared
API
components
(same
Libs,
e.g.)
 – Quick
&
simple,
easy
to
aggregate
 – Some
other
scheme
that
makes
sense
to
you,
the
developers
 • Es+ma+ng:
 – Accurate
es+mates
takes
years
of
prac+ce
 – Make
your
best
guess
for
each
story
point
 – UPDATE 
with
the
 actual 
when
you
are
done
 • This
should
be
egoless
 • You
are
building
a
es/ma/ng
history
to
improve
team
reliability
 CS‐5484/Emory
University
 7


Develop
A
Release
Plan
 • Which
parts
of
the
requirements
 must 
be
tested
together?
 • Which
parts
can
stand
on
their
own
(at
least
at
first)?
 • Are
there
parts
which
 must 
be
developed
first?
 • Are
there
parts
which
can
be
developed
in
parallel?
 • Add
+me
es+mates,
shake
well
and
produce
a
draN
Release
Plan.
 For
example:
 – Beta
1:
Has
story
points
1,
3,4,
7
  
put
these
into
a
release
0.1‐B
 – Beta
2:
Has
story
points
2,8
  
into
release
0.2‐B
 – Final
Beta:
has
story
points
5
&
6
(plus
all
the
others)
into
release
1.0‐Beta
 (or
0.9
pre‐beta
for
tes+ng)
 • Recommenda/on: 
 – Create
a
matrix
of
story
points
and
releases
that
you
can
“check
off”
as
 you
reach
comple+on
 CS‐5484/Emory
University
 8


Release
Plans
(cont’d)
 • Release
plans
may
be
impacted
by
customer‐imposed
delivery
 deadlines
 • Here’s
the
real
date‐requirements
for
this
project:
 1. Site
with
advanced
search
page
with
fielded
searching
is
available
to
 users.
Milestone:
February
2010
 2. Improved
browse
list
performance
is
available
to
site
users.

 Milestone:
March
2010
 3. Search
and
browse
pages
are
implemented
for
Drupal
site.
 Milestone:
May
2010
 4. Search
and
browse
for
single
repository
 Milestone:
August
2010
 CS‐5484/Emory
University
 9