1. Agile
Project
Life
Cycle
Shaun
Smith
This
document
contains
the
proposed
project
life
cycle
2.
Table
of
Contents
Why
Agile
Project
Management
Works…………………………………………………………….………………………………………………………4
Product
Owner…………………………………………….………………………………………………………………………………………….……………….4
Planning
Levels…………………………………..…………………………………………………………………………………………………………………….4
Create
a
SharePoint
2010
Project
Management
Information
System
Template…………………………………………………………5
Stand-‐Up
Meetings……………………………………………………………………………………………………………………………………………………6
Implement
Version
Control
through
SharePoint
2010……………………………………………………………………………………………….6
Project
Budget………………………………………………………………………………………………………………………………………………………….6
Estimating
Size
and
Effort…………………………………………………………………………………………………………………………………………6
Key
Points
When
Estimating
in
Story
Points………………..…………………………………..……………………………………………………….7
Planning
Poker
for
Release
Planning…………………………..…………………………………………………………………………………………….7
Velocity
Equalizer………………………………………………………….………………………………………………………………………………………….8
Planning……………….…………………………………………………………………………………………………………………………………………………..8
Planning
for
Value……………..……………………………………………………………………………………………………………………………………..8
Prioritization…………………………………………..…………………………………………………………
……………………………………………………..9
Knowledge………………………………………………………………………………………………………………………………………………………………..9
Risk……………………………………………………………………………………………………………………………………………………………………………9
When
to
Split
a
User
Story……………………………………………………………………………………………………………………………………...10
Scheduling……………………………………………………………………………………………………………………………………………………………….10
4.
AGILE
PROJECT
LIFE
CYCLE
Why
Agile
Project
Management
Works
Table
of
Contents
1. A
plan
does
not
guarantee
an
exact
set
of
features
on
an
exact
date
at
a
specified
cost.
A
plan
does,
however,
communicate
and
establish
a
set
of
baseline
expectations.
2. A
plan
should
be
updated
regularly
throughout
the
course
of
the
project,
so
that
something
like
a
one-‐
month
late
delivery
will
not
be
a
last-‐minute
surprise
to
anyone.
3. Agile
planning
balances
the
effort
and
investment
in
planning
with
the
knowledge
that
we
will
revise
the
plan
through
the
course
of
the
project.
4. An
agile
plan
is
one
that
we
are
not
only
willing,
but
eager
to
change.
5. The
planning
becomes
more
important
than
the
plan.
6. You
do
not
have
to
change
the
dates,
you
can
drop
a
feature,
reduce
the
scope
of
a
feature,
add
people
to
the
project.
7. Completed
features
are
the
unit
of
customer
value,
not
completed
activities.
8. The
estimates
we
give
should
reflect
our
uncertainty.
The
way
to
do
this
is
by
expressing
the
end
date
as
a
range.
9. The
best
way
to
deal
with
uncertainty
is
to
iterate/sprints.
10. Frequent
re-‐planning
after
each
sprint.
11. For
a
plan
to
be
useful,
it
must
be
accurate,
but
agile
accepts
that
early
plans
will
be
imprecise
and
will
need
to
be
re-‐planned
to
remove
the
imprecision.
12. Agile
estimating
and
planning
succeed
because
estimates
of
size
and
duration
are
separated.
We
start
by
estimating
the
size
of
a
project
through
user
story
points.
Then
estimate
a
rate
of
progress
called
velocity.
The
estimate
of
size
and
velocity
are
then
combined
to
arrive
at
an
estimate
of
duration.
13. Agile
acknowledges
the
importance
of
learning.
Product
Owner
Table
of
Contents
1. Make
sure
all
team
members
are
pursuing
a
common
vision
for
the
project.
2. Establish
priorities
so
highest-‐valued
functionality
is
always
being
worked
on.
3. Set
and
obtain
sign-‐off
criteria.
Planning
Levels
Table
of
Contents
1. Day
2. Iteration
3. Release
4. Product
5. Portfolio
6. Strategy
5.
The
goal
of
Product
Backlog
planning
is
to
determine
an
appropriate
answer
to
the
questions
of
scope,
schedule,
and
resources
for
a
project.
A
good
release
plan
is
updated
throughout
the
project
at
the
start
of
each
sprint,
and
should
be
based
on
work
accomplished
in
the
just
finished
sprint,
identified
high-‐priority
work
the
team
should
address
in
the
new
sprint.
Create
a
SharePoint
2010
Project
Management
Information
System
Template
Table
of
Contents
Template
will
include:
a. Libraries:
i. Project
Documents
1. Milestones
Doc
a. Chart
Web
Part
–
Milestone
Dashboard
b. Lists:
i. Project
Announcements
1. Title,
Modified
ii. Project
Calendar
1. Connect
to
Outlook
iii. Project
Contacts
1. Last
Name,
First
Name,
Company,
Business
Phone,
Home
Phone,
E-‐mail
Address
iv. Project
Risks
1. Issue
ID,
Title,
Assigned
To,
Issue
Status,
Priority,
Due
Date
v. Agile
Product
Backlog
1. Task
Name,
User
Need,
Story
Points,
Start,
Finish,
Predecessors,
Duration,
State,
Sprint
vi. Project
Resources
1. Resource
Name,
Cost
(per
hour),
Notes,
Role
vii. Change
Request
1. CR
Tile,
Description
of
Change,
Affected
Task,
CR
Status,
Due
Date,
Change
Request
viii. Project
Milestone
1. Title,
ID
Number,
State
=
Not
Started,
State
=
In
Progress,
State
=
Complete
c. Discussions:
i. Discussion
Board
1. Subject,
Created
By,
Replies,
Last
Updated
6.
Stand-‐Up
Meetings
Table
of
Contents
Most
agile
teams
use
some
form
of
daily
stand-‐up
meeting
to
coordinate
work
and
synchronize
daily
efforts.
Teams
definitely
make,
assess,
and
revise
their
plans
during
these
meetings.
They
focus
on
the
planning
of
tasks
and
on
coordinating
the
individual
activities
that
lead
up
to
the
completion
of
a
task.
Implement
Version
Control,
Through
SharePoint,
Table
of
Contents
Control
and
track
the
current
version
of
the
document
by
using
the
“check-‐in”
and
“check-‐out”
feature.
This
will
ensure
that
only
one
team
member
is
working
on
a
deliverable
at
any
one
point
in
time.
The”
Check
In”
feature
will
assign
a
version
number
and
capture
comments
describing
the
type
of
update.
This
will
create
the
version
history.
Project
Budget:
Table
of
Contents
If
budget
management
is
required
for
a
project,
it
will
be
conducted
through
MS
Project
2010.
The
two
general
budget
categories
that
will
be
created
are
as
follows:
a. Fixed
Budget
Costs
e.g.
Hardware,
Software,
Travel
etc.
b. Computed
Budget
Costs
for
Budget
Work
Resources
based
on
Cost
Rates
Estimating
Size
and
Effort
Table
of
Contents
A
story-‐point
estimate
is
an
amalgamation
of
the
amount
of
effort
involved
in
developing
the
feature.
This
consists
of
the
complexity
of
developing
the
feature,
and
the
risk
inherent
in
its
development.
Story
points
are
a
unit
of
measure
for
expressing
the
overall
size
of
a
user
story,
feature,
or
other
piece
of
work.
The
raw
values
we
assign
are
unimportant.
What
matters
are
the
relative
values
assigned
to
each
feature
or
story.
For
instance
a
feature
that
is
assigned
a
two
should
be
twice
as
much
as
a
story
that
is
assigned
a
one.
There
are
two
common
ways
to
start
estimating
features
or
stories
by
Analogy
or
Triangulation.
The
first
approach
is
to
select
a
story
that
you
expect
to
be
one
of
the
smallest
stories
you’ll
work
with
and
say
that
story
is
estimated
at
one
story
point.
The
second
approach
is
to
instead
select
a
story
that
seems
somewhat
medium
and
give
it
a
number
somewhere
in
the
middle
of
the
range
you
expect
to
use.
After
you
arbitrarily
assign
a
story-‐point
value
to
the
first
story,
each
additional
story
is
estimated
by
comparing
it
with
the
first
story
or
with
any
others
that
have
been
estimated.
One
way
to
do
this
is
to
assign
a
dog
point
as
representing
the
height
of
a
dog
at
the
shoulder.
Assign
dog
points
to
each
breed
below:
• Labrador
retriever
=
5
• Terrier
=
3
• Great
Dane
=
10
• Poodle
=
3
• Dachshund
=
1
• German
shepherd
=
5
• Saint
Bernard
=
9
• Bulldog
=
3
7.
When
you
give
a
loosely
defined
user
story,
you
make
some
assumptions,
take
a
guess,
and
move
on.
It
is
not
uncommon
to
begin
a
sprint
with
incompletely
specified
requirements,
the
details
of
which
will
be
discovered
during
the
sprint.
Two
developers
of
different
skill
or
experience
can
agree
on
the
size
of
something
while
disagreeing
about
how
long
it
will
take
to
do.
Ideal
time
is
the
amount
of
time
that
something
takes
when
stripped
of
all
peripheral
activities
including
overall
size
and
complexity
of
the
feature
being
implemented.
Elapsed
time
is
the
amount
of
time
that
passes
on
a
clock
or
calendar.
When
considerations
of
organizational
overhead
are
ignored,
ideal
days
can
be
thought
of
as
another
estimate
of
size,
just
as
story
points
are.
Estimate
ideal
days
by
associating
a
single
estimate
with
each
user
story,
rather
than
estimating
that
a
user
story
will
take
four
programmer
days,
two
tester
days,
and
three
product
owner
days,
it
is
better
to
sum
those
days
and
say
the
story
as
a
whole
will
take
nine
ideal
days.
Agile
teams
do
not
rely
on
a
single
expert
to
estimate.
Estimates
are
derived
collaboratively
by
the
team,
which
includes
those
who
will
do
the
work.
Studies
show
that
people
are
best
at
estimating
things
that
fall
within
one
order
of
magnitude.
Two
estimation
scales
that
can
be
used
are
the
Fibonacci
numbers:
1,2,3,5,
and
8,
or
1,
2,
4,
and
8.
A
large
user
story
is
called
an
epic.
A
set
of
user
stories
is
referred
to
as
a
Theme.
An
epic
can
be
a
theme
on
its
own.
Estimates
of
themes
and
epics
will
be
more
uncertain
than
estimates
of
more
specific,
smaller
user
stories.
User
stories
need
to
be
small
enough
that
they
can
be
completed
in
a
single
sprint.
Disaggregation
refers
to
splitting
a
story
or
feature
into
smaller,
easier-‐to-‐estimate
pieces.
Key
Points
When
Estimating
In
Story
Points:
Table
of
Contents
o Story
points
help
drive
cross-‐functional
behavior
because
they
are
estimated
as
a
group.
o Story
point
estimates
do
not
decay
because
the
story
will
always
be
the
same
size
but
the
time
it
takes
to
complete
will
change.
o Story
points
are
a
pure
measure
of
size
if
we
estimate
by
analogy
only
(this
is
like
that).
o Estimating
in
story
points
typically
is
faster.
o My
ideal
days
are
not
your
ideal
days
because
everybody
will
need
to
take
as
long
as
THEY
need
to
complete
a
task.
Planning
Poker
for
Release
Planning
Table
of
Contents
Planning
poker,
each
estimator
is
given
a
deck
of
cards
with
written
estimates
of
0,
1,
2,
3,
5,
8,
13,
20,
40,
and
100
on
each
of
them.
The
moderator
reads
the
description.
The
moderator
is
usually
the
product
owner
or
an
analyst.
Everyone
is
asked
to
remain
aware
of
the
effort/accuracy
curve.
The
goal
is
to
be
somewhere
well
on
the
left
of
the
effort
line,
where
a
valuable
estimate
can
be
arrived
at
cheaply.
After
all
questions
are
answered,
each
estimator
privately
selects
a
card
representing
his
or
her
estimate.
Cards
are
not
shown
until
each
estimator
has
made
a
selection
at
that
time,
all
cards
are
simultaneously
turned
over
and
shown
so
that
all
participants
can
see
each
estimate.
If
estimates
differ,
the
high
and
low
estimators
explain
their
estimates.
The
moderator
can
take
any
notes
she
thinks
will
be
helpful
when
this
story
is
being
programmed
and
tested.
After
the
discussion,
each
estimator
re-‐estimates
by
selecting
a
card.
Cards
are
once
again
kept
in
private
until
everyone
has
estimated,
at
which
point
they
are
turned
over
at
same
time.
Continue
the
process
as
long
as
estimates
are
moving
closer
together.
Use
a
timer
in
the
middle
of
the
table
and
allow
two
minutes
for
each
hand
of
poker.
Estimating
an
initial
set
of
user
stories
may
take
a
team
two
or
three
meetings
of
from
one
to
three
hours
each.
8.
Planning
poker
works,
first,
because
it
brings
together
multiple
expert
opinions
to
do
the
estimating.
These
experts
form
a
cross-‐functional
team
from
all
disciplines
on
a
software
project.
Second,
a
lively
dialogue
ensues
during
planning
poker,
and
estimators
are
called
upon
by
their
peers
to
justify
their
estimates.
Third,
averaging
individual
estimates
leads
to
better
results.
Velocity
Equalizer
Table
of
Contents
Velocity
is
the
great
equalizer,
because
the
estimate
for
each
feature
is
made
relative
to
the
estimates
for
other
features,
it
does
not
matter
if
our
estimates
are
correct,
a
little
incorrect,
or
a
lot
incorrect.
What
matters
is
that
they
are
consistent.
As
long
as
we
are
consistent
with
our
estimates,
measuring
velocity
over
the
first
few
sprints
will
allow
us
to
hone
in
on
reliable
schedule.
Re-‐estimate
only
when
a
story’s
relative
size
has
changed,
or
when
the
team
finishes
only
a
portion
of
a
story
is
finished
during
a
sprint.
If
everything
is
done
all
points
are
captured,
if
anything
is
missing
no
points
are
captured.
Re-‐estimate
as
few
stories
as
possible
to
bring
the
relative
estimates
back
in
line.
Use
re-‐estimating
as
a
learning
experience
for
estimating
future
user
stories.
A
team
only
counts
points
toward
velocity
for
stories
or
features
that
are
complete
at
the
end
of
a
sprint.
Counting
partially
finished
work,
giving
partial
credit,
makes
it
impossible
to
know
exactly
where
we
are
in
the
project,
and
leads
to
a
buildup
of
work
in
process.
The
more
work
in
process,
the
longer
it
will
take
new
features
to
be
transformed
from
raw
ideas
into
functioning
product.
Large
amounts
of
work
in
process
will
take
longer
for
the
team
to
get
feedback
on
what
was
completed.
Planning
Table
of
Contents
Before
planning
a
project,
we
must
consider
what
it
is
that
our
users
need.
Individual
user
stories
or
features
are
aggregated
into
themes.
Stories
and
themes
are
then
prioritized
relative
to
one
another
for
the
purpose
of
creating
a
release
plan,
such
that
themes
should
be
selected
so
each
defines
a
discrete
set
of
user-‐or-‐customer-‐valued
functionality.
Release
planning
is
the
process
of
creating
a
very
high-‐level
plan
that
covers
a
period
longer
than
an
sprint.
A
typical
release
will
cover
perhaps
three
to
six
months
and
maybe
three
to
twelve
or
more
sprints.
Planning
for
Value
Table
of
Contents
The
whole
team
is
responsible
for
estimating.
It
is
difficult
to
estimate
the
value
of
small
units.
User
stories
or
features
are
aggregated
into
themes.
Stories
and
themes
are
prioritized
relative
to
one
another
to
create
a
release
plan.
Each
theme
defines
a
discrete
set
of
user
valued
functionality.
Prioritization
Table
of
Contents
Four
factors
must
be
considered
when
prioritizing
themes.
1. The
financial
value
of
having
the
features.
Estimate
its
financial
impact
over
a
period
of
time.
New
sales,
new
donations…etc.
9.
2. The
cost
of
developing
(and
perhaps
supporting)
the
new
features.
3. The
amount
and
significance
of
learning
and
new
knowledge
created
by
developing
the
features.
4. The
amount
of
risk
removed
by
developing
the
features.
The
themes
with
a
high
value-‐to-‐cost
ratio
are
those
that
should
be
done
first.
When
possible,
try
to
combine
related
stories
as
that
will
make
it
easier
to
prioritize
them.
Determine
the
priority
of
a
theme
by
asking
questions
such
as
“How
would
the
user
feel
if
the
feature
were
present”,
and
then
ask
“How
would
the
user
feel
if
the
feature
were
not
present”.
Use
the
following
answers:
1. I
like
it
that
way
2. I
expect
it
to
be
that
way
3. I
am
neutral
4. I
can
live
with
it
that
way
5. I
dislike
it
that
way
Dynamic
Systems
Development
Method
(DSDM)
is
another
way
of
determining
priority.
Requirements
are
sorted
into
four
categories:
Must
Have,
Should
Have,
Could
Have,
and
Won’t
Have.
No
more
than
70%
of
the
planned
effort
for
a
project
can
be
targeted
at
Must
Have
requirements.
In
this
way
DSDM
projects
create
a
feature
buffer
equivalent
to
30%
of
the
duration
of
the
project.
Knowledge
Table
of
Contents
At
the
start
of
a
project,
we
never
know
everything
that
we
will
need
to
know
by
the
end
of
the
project.
There
is
two
types
of
knowledge
that
a
team
develops:
o Knowledge
about
the
product,
(what
will
be
developed).
o Knowledge
about
the
project,
(how
will
it
be
developed).
Risk
Table
of
Contents
A
risk
is
anything
that
has
not
yet
happened
but
might
and
that
would
jeopardize
or
limit
the
success
of
the
project.
The
types
of
risks
are:
o Schedule
risk
(“We
might
not
be
done
by
October”)
o Cost
risk
(“We
might
not
be
able
to
buy
hardware
for
the
right
price”)
o Functionality
risk
(“We
might
not
be
able
to
get
that
to
work”)
o Technological
risk
o Business
risk
When
to
Split
a
User
Story
Table
of
Contents
A
user
story
should
be
split
when
it
is
too
large
to
fit
within
a
single
sprint.
It
won’t
fit
within
the
sprint
being
planned
because
there
isn’t
enough
room
left.
Split
story
by
the
type
of
data
that
the
user
could
enter.
10.
Split
a
story
along
the
boundaries
of
the
common
CRUD
operations
Create,
Read,
Update,
Security,
Error-‐Handling,
Delete,
and
Logging.
Deliver
a
partial
user
interface,
a
partial
middle
tier,
and
a
partial
database.
Delivering
a
cohesive
subset
of
all
layers
of
a
feature
is
almost
always
better
than
delivering
all
of
one
layer.
Scheduling
Table
of
Contents
In
some
cases
we
start
with
a
finish
date
and
see
how
much
we
can
finished
by
that
date.
In
other
cases
we
start
with
a
set
of
user
stories
and
see
how
long
it
will
take
to
develop
them.
Multiply
the
planned
number
of
sprints
by
either
the
expected
or
known
sprint
velocity
of
the
team
gives
the
total
amount
of
work
that
can
be
performed.
If
feature
driven
project,
sum
the
estimates
of
all
needed
features
and
divide
by
the
velocity.
This
will
give
us
the
number
of
sprints
necessary
to
complete
the
desired
functionality.
If
date-‐driven
project,
we
can
determine
the
number
of
sprints
by
looking
at
a
calendar.
Multiply
the
number
of
sprints
by
the
expected
velocity
will
tell
us
how
many
story
points
or
ideal
days
will
fit
in
the
release.
The
product
owner
selects
the
top
priority
items
that
will
fit
in
the
first
sprint.
Cards
are
stacked
or
arranged
to
indicate
which
stories
comprise
each
sprint.
Each
story
card
is
annotated
with
an
estimate,
it
is
possible
to
look
down
each
column
of
an
arrangement
and
verify
that
each
sprint
holds
the
right
amount
of
work.
Release
Planning
Table
of
Contents
Agile
planning
becomes
a
two-‐stage
process,
release
plan
and
iteration
plan.
The
first
stage
is
the
release
plan,
with
its
rough
edges
and
general
uncertainties.
Release
planning
is
the
process
of
creating
a
very
high-‐level
plan
that
covers
a
period
longer
than
a
iteration.
A
typical
release
is
three
to
six
months
and
maybe
three
to
twelve
iterations.
A
release
plan
does
the
following
three
things:
o Helps
the
product
owner
and
team
decide
how
much
must
be
done
and
how
long
it
will
take.
o Conveys
expectations
about
what
is
likely
to
be
developed
and
in
what
timeframe.
o Serves
as
a
guidepost
for
progress.
o Either
starts
with
an
end
date
and
see
how
much
can
be
finished,
or
start
with
a
set
of
user
stories
and
see
how
long
it
will
take
to
develop
them.
o Multiply
the
planned
number
of
iterations
by
either
the
expected
or
know
velocity
of
the
team
gives
us
the
total
amount
of
work
that
can
be
performed,
(Number
of
Iterations
x
Velocity
=
Amount
of
Work
Performed).
o Sum
the
estimates
of
all
needed
features
and
divide
by
the
expected
velocity
will
give
the
number
of
iterations
necessary
to
complete
the
desired
functionality,
(Features
/
Velocity
=
Number
of
Iterations
to
Complete).
o Decisions
about
who
works
on
what
and
the
sequence
of
activities
are
best
left
to
the
individuals
working
on
those
tasks
and
best
deferred
as
long
as
possible.
o Include
additional
information
in
the
release,
such
as
assumptions
like
who
is
on
the
team
,
first
iteration
start
date,
and
finish
date.
o Place
specific
work
into
the
first
one
to
three
iterations,
rest
of
the
release
plan
is
product
backlog.
Sprint
Planning
Table
of
Contents
A
release
plan
provides
only
the
high
level
view
of
the
product
being
built.
With
iteration
plan,
a
team
takes
a
more
focused,
detailed
look
at
what
will
be
necessary
to
implement
completely
only
those
user
stories
selected
for
the
new
11.
iteration.
An
iteration
plan
is
created
in
an
iteration
planning
meeting.
Anyone
involved
in
taking
a
raw
idea
and
turning
it
into
a
functioning
product
should
be
present.
It
can
be
as
simple
as
a
spreadsheet,
a
set
of
note
cards
with
one
task
handwritten
on
each
card,
or
eboard
on
SharePoint
.
Tasks
are
not
allocated
to
specific
individuals.
The
sprint
plan
looks
ahead
only
the
length
of
one
sprint,
usually
one
to
two
weeks.
The
sprints
should
be
staggered
with
a
one
week
sprint
and
then
a
two
week
sprint
and
then
a
one
week
sprint.
The
user
stories
of
the
release
plan
are
decomposed
into
tasks
on
the
iteration
plan.
Tasks
on
the
iteration
plan
are
estimated
in
ideal
hours.
An
iteration
review
meeting
is
held
after
the
iteration
is
finished,
and
will
take
thirty
to
sixty
minutes.
A
prioritization
meeting
is
held
two
days
before
the
end
of
the
iteration,
and
involves
anyone
that
can
contribute
to
a
discussion
of
the
project’s
priorities.
Two
ways
to
plan
a
sprint,
one
is
called
velocity-‐driven
and
the
other
is
commitment-‐driven.
Velocity-‐Driven
is
done
by
the
following:
Table
of
Contents
1. Collaboratively
adjust
priorities.
2. Id
the
target
velocity
for
the
coming
iteration.
3. Selects
a
sprint
goal,
what
they
wish
to
accomplish.
A
unifying
statement
about
what
will
be
accomplished
during
the
iteration.
It
does
not
have
to
be
very
specific.
4. Select
the
top-‐priority
user
stories
that
support
goal,
enough
to
sum
up
ideal-‐day
or
story-‐point
estimates
to
equal
target
velocity.
5. The
best
way
to
predict
velocity
is
to
observe
velocity,
this
should
always
be
your
default
approach.
6. Selected
stories
are
split
into
tasks,
and
each
task
is
estimated.
All
tasks
necessary
to
go
from
a
user
story
to
a
functioning,
finished
product
should
be
identified.
Only
include
tasks
that
add
immediate
value
to
the
current
project.
Include
tasks
for
meetings
and
any
time
spent
preparing
for
the
meeting.
Put
stories
in
their
natural
order
which
is
the
order
the
team
assumed
when
they
estimated
the
stories.
A
spike
task
included
in
an
iteration
plan
that
is
being
undertaken
specifically
to
gain
knowledge
or
answer
a
question.
The
spike
would
help
the
team
learn
how
they’d
approach
the
other
task,
which
would
allow
them
to
estimate
it.
A
task
should
be
able
to
be
completed
within
one
day.
Commitment-‐Driven
is
done
by
the
following:
Table
of
Contents
1. The
team
adds
stories
to
the
iteration
one
by
one
until
they
can’t
commit
to
any
more.
2. Adjust
priorities
and
identify
an
iteration
goal.
3. Estimate
the
number
of
hours
that
each
person
will
be
available
to
work
on
the
project
each
day.
4. Determine
the
total
number
of
hours
that
will
be
spent
on
the
project
during
the
sprint.
5. The
product
owner
and
team
select
the
highest-‐priority
story.
6. Stories
are
selected
and
decomposed
into
tasks.
7. Tasks
are
estimated
one
story
at
a
time
and
converted
into
ideal
hours.
8. Select
tasks
until
you
have
identified
enough
tasks
to
fill
the
number
of
hours
in
the
sprint.
Schedule
the
prioritization
meeting
for
two
days
before
the
end
of
the
iteration.
The
product
owner
conducts
the
prioritization
meeting
and
involves
anyone
she
thinks
can
contribute
to
a
discussion
of
the
project’s
priorities.
Sum
up
the
estimates
and
see
if
the
sum
represents
a
reasonable
amount
of
work.
12.
If
a
new
task
is
discovered
during
the
iteration
(and
they
almost
certainly
will
be),
a
team
that
is
committed
to
delivering
the
functionality
described
by
a
user
story
will
try
to
complete
the
new
tasks
as
well.
The
key
is
that
everyone
on
the
team
is
accountable
for
contributing
whatever
is
within
their
capabilities,
regardless
of
whether
it
is
their
specialty.
Burndown
Charts
Table
of
Contents
Shows
the
number
of
story
points
or
ideal
days
remaining
in
a
project.
User
Stories
Table
of
Contents
Example:
Front
As
a
<>
I
want
to
<>
so
that
I
can
<>.
Priority:
(DSDM)
–
Must
Have,
Should
Have,
Could
Have,
Won’t
Have
Story
points:
1,2,3,5,8,13,21,34
Back
Confirmations
or
acceptance
criteria,
sketches,
flow
charts,
UML
