Mais conteúdo relacionado Semelhante a Agile Project Management and Scrum Introduction (20) Agile Project Management and Scrum Introduction1. Eric
Krock
Principal
Consultant
and
Trainer,
280
Group
©
2011-‐2012
Eric
Krock
Marketing
Services
Inc.
All
rights
reserved.
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
©
2011-‐2012
Eric
Krock
Marketing
Services
Inc.
All
rights
reserved.
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
©
2011-‐2012
Eric
Krock
Marketing
Services
Inc.
All
rights
reserved.
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
©
2011-‐2012
Eric
Krock
Marketing
Services
Inc.
All
rights
reserved.
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
©
2011-‐2012
Eric
Krock
Marketing
Services
Inc.
All
rights
reserved.
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”
©
2011-‐2012
Eric
Krock
Marketing
Services
Inc.
All
rights
reserved.
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
©
2011-‐2012
Eric
Krock
Marketing
Services
Inc.
All
rights
reserved.
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
©
2011-‐2012
Eric
Krock
Marketing
Services
Inc.
All
rights
reserved.
9. Development
Concepts
Test
driven
design*
Depth-‐first
development
* Source: Kent Beck, XP Explained
©
2011-‐2012
Eric
Krock
Marketing
Services
Inc.
All
rights
reserved.
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
©
2011-‐2012
Eric
Krock
Marketing
Services
Inc.
All
rights
reserved.
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
©
2011-‐2012
Eric
Krock
Marketing
Services
Inc.
All
rights
reserved.
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
©
2011-‐2012
Eric
Krock
Marketing
Services
Inc.
All
rights
reserved.
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
©
2011-‐2012
Eric
Krock
Marketing
Services
Inc.
All
rights
reserved.
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
©
2011-‐2012
Eric
Krock
Marketing
Services
Inc.
All
rights
reserved.
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
©
2011-‐2012
Eric
Krock
Marketing
Services
Inc.
All
rights
reserved.
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
even
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
©
2011-‐2012
Eric
Krock
Marketing
Services
Inc.
All
rights
reserved.
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
©
2011-‐2012
Eric
Krock
Marketing
Services
Inc.
All
rights
reserved.
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
©
2011-‐2012
Eric
Krock
Marketing
Services
Inc.
All
rights
reserved.
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
©
2011-‐2012
Eric
Krock
Marketing
Services
Inc.
All
rights
reserved.
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/
©
2011-‐2012
Eric
Krock
Marketing
Services
Inc.
All
rights
reserved.
21. Stay
in
Touch!
http://www.linkedin.com/in/krock
http://www.slideshare.net/ekrock/
My
email
list:
http://eepurl.com/jon-‐f
ericweb@mail.com
©
2011-‐2012
Eric
Krock
Marketing
Services
Inc.
All
rights
reserved.