1. Scrum
Essen+als
Presented
by
Riad
Bacchus
Riad_bacchus@hotmail.com
LinkedIn/Riad
Bacchus

2. Overview
• Scrum
Overview
How
does
it
all
work?
• Scrum
Planning
How
do
we
plan
the
project?
• Scrum
Roles
Who’s
responsible?
• Scrum
Ar+facts
What
documents
are
needed?
• Scrum
Mee+ngs
What
mee9ngs
drive
Scrum?

3. Scrum
Overview
• Developed
in
1993
• Scrum
is
one
of
several
Agile
Methodologies
• Scrum
is
part
of
the
Agile
Alliance
• Has
been
used
on
thousands
of
projects
• Used
internally
by
various
MicrosoN
teams
• Can
manage
projects
of
2
-­‐
3000
team
members

4. Scrum
Cycles
Program
2-n months
Project
2-n months
Release
2-6 months
Sprint
30 days
Daily Scrum
daily

5. Project
Success
Decline
Over
Time
This
graph
indicates
the
sharp
decline
in
project
success
the
longer
a
project
runs
without
shipping
a
release.
1-­‐6
months
seems
to
be
the
sweet
spot.

6. Working
vs.
Released
SoNware
Sprint
1
Sprint
2
Sprint
3
Sprint
4
(Normal)
(Normal)
(Normal)
(Release)
Sprint
5
Sprint
6
Sprint
7
Sprint
8
(Normal)
(Release)
(Normal)
(Release)
• During
normal
sprints,
working
soNware
is
“DONE”
but
might
not
be
“released”.
• During
release
sprints,
working
soNware
is
deployed.

7. Scrum
Planning
• A
Scrum
project
is
planned
up
front
&
as
we
go.
• Up
front?
– Set
expecta+ons
based
on
“ini+al”
scope.
– Develop
a
priori+zed
product
backlog.
– Assign
“order
of
magnitude”
es+mates.
(+75%/-­‐25%)
– Define
desired
+ming
for
produc+on
releases.
– Es+mate
resources
needed.
– Es+mate
sprint
count
• As
we
go!
– At
the
start
of
each
sprint,
plan
30
days
of
scope.
– Refine
es+mates,
priori+es
and
product
backlog.

8. Scrum
Roles
ScrumMaster
Product
Owner
• Establish
vision
• Teach
/
Coach
Scrum
• Set
Sprint
Goals
• Manage
Process
• Set
Priori+es
• Protect
Team
• Owns
the
Product
Backlog
• Enforce
Rules
• Remove
Blocks
• Facilitate
Mee+ngs
Stakeholder
Team
• Observe
• Organize
work
• Advise
• Develop
product
• Communicate
issues
&
progress

9. Scrum
Ar+facts
Sprint
Backlog
•
Product
Backlog
List
of
requirements
• Decomposed
task
list
• Owned
by
Product
Owner
• Driven
by
a
por+on
of
Product
• Anybody
can
add
to
it
Backlog
• Owned
by
Team
• Priori+zed
by
business
value
• Only
Team
modifies
it
• Can
change
without
affec+ng
the
ac+ve
Sprint
Sprint
Goal
Blocks
List
• One
sentence
summary
• List
of
blocks
&
pending
• Defined
by
Product
Owner
decisions
• Accepted
by
Team
• Owned
by
ScrumMaster
• Blocks
stay
on
list
un+l
resolved
Increment
• Version of the product
• Potentially shippable
• Working functionality
• Tested & documented
according to project
definition of “DONE”

10. Sample
Product
Backlog
• The
scope
list
• A,
B,
C
feature
dis+nc+on
• Priori+zed
by
• Rough
es+mates
help
size
the
business
value
sprints

11. Sample
Sprint
Backlog
• Granular
tasks
(2-­‐40
hours
each)
• Assigned
to
team
members
• Es+mates
adjusted
daily
by
team
• Managed
by
the
team

12. Sample
Burndown
Chart
• Provides
candid
transparency
• Printed
daily
• Posted
publicly
• May
be
bumpy

13. Scrum
Mee+ngs
Sprint
Planning
-­‐
A
Daily
Scrum
• Time-­‐boxed:
<
4
hours
• Time-­‐boxed:
<
15
minutes
• Run
by
ScrumMaster
• Run
by
ScrumMaster
• Declare
Sprint
Goal
• Aoended
by
all
• Top
of
Product
Backlog
presented
• Stakeholders
do
not
speak
by
P.O.
• Same
+me/place
daily
• Team
asks
ques+ons
&
selects
• Answer
3
ques+ons:
topmost
features
1)
What
I
did
yesterday
Sprint
Planning
-­‐
B
2)
What
I’ll
do
today
• Time-­‐boxed:
<
4
hours
3)
What’s
in
my
way
• Run
by
ScrumMaster
• Sprint
Backlog
updated
• Team
decomposes
features
into
a
• ScrumMaster
updates
blocks
Sprint
Backlog
• Team
adjusts
+/-­‐
features
by
task
es+mates
against
sprint
capacity
Sprint
Retrospec+ve
Sprint
Review
• Time-­‐boxed:
1-­‐2
hours
• Time-­‐boxed:
<
4
hours
• Run
by
ScrumMaster
• Run
by
ScrumMaster
• Aoended
by
Team
and
P.O.
• Aoended
by
all
• Discuss
process
improvements,
• Team
demonstrates
increment
wins
and
losses
• All
discuss
• Adjust
process

14. Scrum
on
a
Page

15. Review
• Scrum
Overview
How
does
it
all
work?
• Scrum
Planning
How
do
we
plan
the
project?
• Scrum
Roles
Who’s
responsible?
• Scrum
Ar+facts
What
documents
are
needed?
• Scrum
Mee+ngs
What
mee9ngs
drive
Scrum?

16. Roles
Q&A
• What
if
the
client
doesn’t
know
how
to
be
a
Product
Owner?
– It
is
common
for
a
client
to
be
willing,
but
inexperienced
as
a
P.O.
In
this
case,
the
ScrumMaster
must
lead
the
client
through
the
tasks
of
building
a
Product
backlog,
priori+zing
and
elabora+ng
features.
Remember,
teaching
is
part
of
the
duty
of
a
ScrumMaster.
Leading
the
P.O.
through
the
mo+ons
ini+ally
is
a
great
way
to
teach.
– The
ScrumMaster
needs
to
set
expecta+ons
with
the
client
as
to
their
role
in
the
success
of
the
project.
– Regardless
of
Agile
or
Tradi+onal
project
methods,
a
project
that
doesn’t
have
strong
support
and
par+cipa+on
from
the
key
stakeholders
is
very
likely
to
fail.
– If
the
client
refuses
to
accept
some
or
all
of
the
du+es
of
Scrum’s
version
of
a
P.O.,
the
ScrumMaster
may
proxy
for
the
Product
Owner.
However,
this
adds
risk,
and
fails
to
truly
empower
the
client.
• What
if
the
client
or
a
team
member
keeps
breaking
the
rules?
– The
ScrumMaster’s
primary
duty
is
to
protect
the
team’s
+me
and
focus
to
achieve
stated
project
goals.
The
ScrumMaster
must
seriously
address
any
disregard
for
the
process.

17. Product
Backlog
Q&A
• What
does
Neudesic
use
to
manage
a
Product
Backlog
– TFS
– (OR)
A
spreadsheet
Product
Backlog
(posted
to
SharePoint)
• Can
Neudesic
create
the
Product
Backlog
for
the
client?
– Preferably
not.
But
in
many
cases,
we’ll
need
to
help
teach
the
client
how
to
maintain
a
backlog.
– In
the
absence
of
a
strong
client
leader
who
can
be
assigned
the
clear
“Product
Owner”
role,
we
have
no
choice
but
to
serve
as
the
Product
Owner.
• What
should
the
Product
Backlog
contain?
– Item
Name
– Priority
(according
to
business
value)
– User
Story
(1-­‐2
paragraphs
descrip9on)
– Status
(New,
Approved,
In
Progress,
Completed,
Cancelled)
– Sprint
Number
• When
can
the
Product
Backlog
change?
– Any
+me
(except
for
sprint
planning
day).
– Refine
es+mates,
priori+es
and
product
backlog.

18. Product
Backlog
Q&A
cont’d
• Does
the
Product
Backlog
ever
contain
items
other
than
product
features?
– Yes.
ONen,
major
tasks
(40
hours+)
are
priori+zed
in
the
backlog
even
if
they
do
not
strictly
represent
features.
System
Stories
are
used
to
capture
security,
performance
and
infrastructure
requirements.
– Examples:
Integrate
SharePoint
with
MIIS,
User
Training
Guide.
• Don’t
changes
to
the
backlog
affect
project
scope?
– Yes.
In
some
cases
the
changes
represent
a
small
impact
to
overall
project
outcome.
In
others,
the
changes
will
require
a
revisit
of
the
program/project/
release
planning
constraints
and
es+mates.
– If
the
Product
Owner
makes
significant
changes
(addi+ons)
to
the
Product
Backlog,
this
should
force
a
conversa+on
between
the
ScrumMaster
and
the
Product
Owner
resesng
expecta+ons.
– However,
this
should
be
done
in
the
spirit
of
“harnessing
change”
vs.
“preven+ng
change”.

19. Sprint
Backlog
Q&A
• When
is
the
Sprint
Backlog
created?
– During
the
sprint
planning
mee+ng
(day
1
of
each
sprint).
• How
is
the
Sprint
Backlog
different
from
the
Product
Backlog?
– It
contains
“tasks”,
whereas
the
Product
Backlog
primarily
contains
priori+zed
features
and
major
efforts.
– The
tasks
it
contains
are
usually
“decomposed”
down
to
8-­‐40
hour
efforts.
– The
Team
creates
and
maintains
the
Sprint
Backlog.
Only
they
are
allowed
to
add
or
remove
tasks.
• How
does
the
team
know
enough
on
day
1
of
the
Sprint
to
accurately
es+mate
tasks
in
the
Sprint
Backlog?
– They
might
not.
But,
their
job
in
the
sprint
planning
mee+ng
is
to
find
out
(and
write
down)
enough
clarifying
details
to
be
accurate
enough
in
their
es+ma+ons
for
the
purposes
of
a
30-­‐day
planning
window.
– Depending
on
how
well
defined
the
sprint
features
are,
the
team
may
choose
not
to
“fill
up
the
sprint”
en+rely,
allowing
some
+me
do
deal
with
the
unknown.“

20. Sprint
Backlog
Q&A
cont’d
• Can
the
Team
add
items
to
the
Sprint
Backlog
during
the
Sprint?
– Yes,
the
team
is
free
to
add
tasks
to
the
Sprint
Backlog
throughout
the
Sprint,
so
long
as
they
are
directly
associated
with
mee+ng
the
stated
sprint
goal
and
the
specific
features
that
were
selected
from
the
Product
Backlog.
– No,
the
team
is
not
free
to
silently
select
addi+onal
features
from
the
product
backlog
during
the
Sprint.
They
are
encouraged
to
ask
the
Product
Owner
for
addi+onal
features
if
they
feel
there
is
room
for
more.
• Who
assigns
team
members
to
tasks?
– The
Team
works
out
its
own
assignments
during
Sprint
Planning.
– The
Team
can
at
any
+me
adjust
assignments
to
op+mize
outcomes.
• How
detailed
must
Sprint
Backlog
items
be?
– They
should
be
broken
down
into
tasks
discrete
enough
for
the
team
to
see
how
they’ll
accomplish
the
selected
Sprint
scope.
– A
good
rule
of
thumb
is:
tasks
of
8-­‐24
hour
dura+on.
– Key
mee+ngs
should
be
included
(e.g.
design
workshops
2+
hours,
integra+on
work
sessions
2+
hours)
as
they
tend
to
add
up
when
all
team
members
are
present.

21. Further
Reading
• Agile
SoNware
Development
with
Scrum
2002,
Pren+ce
Hall,
Ken
Schwaber,
Mike
Beedle.
(#1
read
for
anyone
serious
about
Scrum)
• Agile
Project
Management
with
Scrum
2004,
MicrosoN
Press,
Ken
Schwaber.
(A
bit
more
fluffy,
but
has
a
lot
of
case
studies)
• Agile
&
Itera+ve
Development
2004,
Pearson
Educa+on,
Craig
Larman.
(#1
read
to
introduce
and
compare
Agile
methods)
• Agile
SoNware
Development
2002,
Pearson
Educa+on,
Alistair
Cockburn
.
(Provides
the
science
and
the
“why’s”
of
Agile
methods)