The document discusses the drawbacks of the waterfall method in software development, highlighting issues such as delayed market deliveries, poor communication between teams, and unresponsiveness to customer feedback. It advocates for agile methodologies and user stories, emphasizing the importance of incremental development, shorter sprints, and collaboration among team members to better align with customer needs. Key concepts include sprint planning, velocity tracking, and the utilization of user stories to stimulate conversations that enhance project outcomes.

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

12. Sprint
Burndown
Chart
Sprint
Hours
of
Work
Remaining
70
60
50
40
30
20
10
0
3/27/11
3/28/11
3/29/11
3/30/11
3/31/11
4/1/11

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

14. Project
Burndown
Chart
400
350
300
250
Points
Closed
200
Points
Added
150
Points
Remaining
100
50
0
1/7/11
1/14/11
1/21/11
1/28/11
2/4/11
2/11/11
2/18/11
2/25/11
3/4/11

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/