The document summarizes key concepts of agile software development methodologies like Scrum and Kanban. It discusses problems with traditional waterfall methods and why user stories, short sprints, and continuous feedback are better approaches. Key points covered include writing short user stories to represent features, estimating story efforts in relative points, committing to stories per sprint, daily standups, and using burn down charts to track progress.
Introduction to Agile Project Management and Scrum
1. Eric
Krock
Co-‐Founder,
Voximate
http://twitter.com/#!/voximate
http://www.voximate.com/blog/
2. Why
Waterfall
Usually
Sucks
Problem
Consequences
Serialized
process:
MRD
Longer
time
to
market;
developers
isolated
from
–
PRD
–
Design
customer
needs
Document
–
Dev
-‐
QA
Planning
far
in
advance
Plans
no
longer
match
reality
by
the
time
they’re
implemented
Lack
of
visibility
into
Teams
don’t
realize
they’re
behind
schedule
until
too
rate
of
progress
late
Features
slashed
very
late
to
compensate,
wasting
effort
and
leading
to
Swiss-‐cheese
products
(e.g.
MS
Kin)
Long
time
to
project
Customers
get
access
to
new
features
infrequently
completion
and
after
long
delay
Customers
can
only
provide
feedback
“too
late”
Process
doesn’t
allow
for
rapid
incremental
learning
Projects
fall
behind
Projects
miss
market
window
or
are
killed
before
schedule
launch
3. Why
PRDs
Usually
Suck
Long
Monolithic
Unreadable
and
unread
Often
disconnected
from
actual
customer
needs
Lack
of
clarity
about
what
features
are
for
which
customers
4. User
Stories
Express
a
customer
need
as
a
story
about
a
real
or
composite
user
in
the
language
of
the
customer
As
a
[USER
ROLE],
I
[must
/
want
/
wish
to]
[need]
so
that
[user
goal]
Short:
can
fit
on
an
index
card
Example:
“As
a
project
manager,
I
must
track
each
task’s
delivery
deadline
so
that
I
can
make
sure
tasks
are
completed
on
team.”
Small
amount
of
work:
can
fit
within
a
day
or
a
sprint
Should
include
notes
for
needed
acceptance
test
Source: Mike Cohn, User Stories Applied
5. Es7mate
Effort
for
Story
in
Points
“Story
point”
=
abstract,
RELATIVE
estimate
of
amount
of
work
to
complete
a
story
Optional:
Using
Fibbonacci
sequence
forces
clear
distinctions
in
difficulty:
1,
2,
3,
5,
8,
13,
21
…
Teams
must
agree
on
estimate
for
each
story
Tracking
velocity
(points
completed
per
sprint)
will
measure
team’s
true
capacity
Issues:
measure
with
points,
or
not?
Source: Mike Cohn, Agile Estimating and Planning
6. Release
Plan
Combines
multiple
sprints
to
achieve
larger
goal
Capacity
=
number
of
sprints
*
expected
velocity
Choose
list
of
stories
with
total
story
points
no
greater
than
capacity
Source: Mike Cohn, Agile Estimating and Planning, Chapter 13, “Release Planning”
7. Divide
Workload
Into
Short
Sprints
Sprint
=
short,
fixed-‐length
interval
for
development
Usually
1-‐2
weeks
Key:
Must
return
product
to
potentially
shippable
state
at
end
of
sprint!
Reduces
accumulation
of
technical
debt
Keeps
assessment
of
project
progress
realistic
8. Key
Concepts
in
Scrum
Product
Owner:
voice
of
the
customer,
facilitates
writing
of
user
stories
ScrumMaster:
manages
the
sprints
Team:
do
the
work!
Collective
ownership
Daily
standup:
did
yesterday,
doing
today,
stuck
on
…
Source: Mike Cohn, User Stories Applied, Chapter 15
9. Development
Concepts
Test
driven
design*
Depth-‐first
development
* Source: Kent Beck, XP Explained
10. Sprint
Commit
Mee7ng
At
start
of
each
sprint,
team
meets
and
commits
which
stories
they
will
do
for
the
sprint.
Make
decision
based
on
tasks
for
each
story
and
estimated
hours
for
all
tasks,
not
based
on
points.
Key:
After
sprint
commit
meeting,
no
new
stories
can
be
added
to
that
sprint.
For
true
emergencies,
must
remove
equal
amount
of
work
if
add
something
in
after
sprint
commit.
Source: Mike Cohn, User Stories Applied
11. User
Stories
Conversa7ons
User
story
is
basis
for
a
conversation
with
developer
Conversation
(not
the
user
story)
is
basis
for
actual
development
Goals:
Get
engineering
talking
to
product
owner,
customers,
etc.
Get
deeper
mutual
understanding
of
the
story
by
talking
about
it
Increase
odds
that
features
developed
will
actually
satisfy
customer’s
needs
Source: Mike Cohn, User Stories Applied
13. Sprint
Review
Mee7ng
At
end
of
sprint,
review
what
work
actually
got
done.
Velocity
=
total
points
for
all
user
stories
completed
during
sprint.
No
partial
credit
for
partially-‐complete
stories!
Estimated
time
to
project
completion
=
total
story
points
for
all
stories
in
project
/
moving
average
of
velocity
Moving
average
=
average
velocity
of
last
three
sprints
Team’s
accuracy
estimating
doable
work
per
sprint
should
improve
over
time
Source: Mike Cohn, Agile Estimating and Planning
15. Backlog:
Per-‐Project,
or
Per-‐Release?
Backlog
is
list
of
all
stories
not
yet
assigned
to
a
sprint
Simple
project,
single
release:
single
backlog
Benefit:
simplicity
Long-‐lived
project
with
multiple
releases:
may
have
one
backlog
per
release
Benefit:
do
initial
division
of
work
by
release,
then
divide
each
release’s
work
into
sprints
during
development;
product
owner
needn’t
review
ALL
stories
at
every
sprint
16. Agile
Best
Prac7ces
Best
Practice
Benefit
Don’t
write
stories
too
far
in
advance
of
Avoid
wasted
effort
on
stories
that
are
development.*
not
implemented.
Use
best,
most-‐current
information
when
writing
story.
Don’t
event
tentatively
schedule
stories
Avoid
wasted
effort
of
moving
stories
more
than
2-‐3
sprints
in
advance.
when
priorities
change.
Have
customers
write
and
prioritize
Let
customers
express
their
needs.
user
stories.*
Avoid
“telephone
game”
problem.
Force
customers
to
make
tradeoffs.
* Source: Mike Cohn, User Stories Applied
17. Key
Agile
Values
Communication
Transparency
Honesty
Incremental
effort
Incremental
learning
feedback
For fuller list of Agile / XP values, see Kent Beck, XP Explained, Chapters 3-5
18. Agile
Versus
Tradi7onal
Waterfall
Metric
Waterfall
Agile
Planning
scale
Long-‐term
Short-‐term
Distance
between
Long
Short
customer
and
developer
Time
between
Long
Short
specification
and
implementation
Time
to
discover
Long
Short
problems
Project
schedule
risk
High
Low
Ability
to
respond
Low
High
quickly
to
change
19. Addi7onal
Reading
Book
Author
Notes
User
Stories
Applied
Mike
Cohn
Intro
to
Agile
and
use
of
user
stories
for
expressing
requirements.
Agile
Estimating
and
Mike
Cohn
Deep
dive
on
Agile
metrics,
Planning
estimating,
and
project
planning.
Succeeding
with
Agile
Mike
Cohn
Tips
on
rolling
out
Agile
in
a
larger
organization.
Extreme
Programming
Kent
Beck
&
Introduction
to
XP
Explained
Cynthia
Andres
20. Addi7onal
Resources
http://www.mountaingoatsoftware.com/
Mike
Cohn’s
site
with
blog,
presentations,
more
http://agilemanifesto.org/
http://www.agilealliance.org/
http://www.scrumalliance.org/