Professional Documents
Culture Documents
Agrawalneelammahajanabhijit-Scrum Plan PDF
Agrawalneelammahajanabhijit-Scrum Plan PDF
Scrum
-‐Abhijit
Mahajan
-‐Neelam
Agrawal
an
agile
development
process
methodology
Introduction
ì A
typical
scrum
team
has
between
five
and
nine
people
ì but
Scrum
projects
can
easily
scale
into
the
hundreds
History
History
ì 1993-‐Jeff
Sutherland,
John
Scumniotales
and
Jeff
McKenna,
came
up
with
an
approach
at
Easel
Corpora>on
ì first
to
refer
it
using
the
single
word
Scrum.
ì 1998-‐
Ken,
Jeff,
et
al
came
up
with
“Scrum
a
pa[ern
language
for
hyperproduc>ve
so<ware
development”
ì In
2001,
Schwaber
worked
with
Mike
Beedle
to
describe
the
method
in
the
book
Agile
with
Scrum
SCRUM
Methodology
Scrum
&
Rugby
ì Pregame
ì Planning
ì System
Architecture/High
Level
Design
ì Game
ì Sprints
(Concurrent
Engineering)
ì Develop
(Analysis,Design,Develop)
ì Wrap
ì Review
ì Adjust
ì Postgame
ì Closure
SCRUM
Phases
(1)
ì Pregame
ì Planning
:
ì Defini>on
of
a
new
release
based
on
currently
known
backlog,
along
with
an
es>mate
of
its
schedule
and
cost.
ì If
a
new
system
is
being
developed,
this
phase
consists
of
both
conceptualiza>on
and
analysis.
ì If
an
exis>ng
system
is
being
enhanced,
this
phase
consists
of
limited
analysis.
ì Architecture
:
ì Design
how
the
backlog
items
will
be
implemented.
ì This
phase
includes
system
architecture
modifica>on
and
high
level
design.
SCRUM
Phases
(2)
ì Game
ì Development
Sprints
:
ì Development
of
new
release
func>onality,
with
constant
respect
to
the
variables
of
>me,
requirements,
quality,
cost,
and
compe>>on.
ì Interac>on
with
these
variables
defines
the
end
of
this
phase.
ì There
are
mul>ple,
itera>ve
development
sprints,
or
cycles,
that
are
used
to
evolve
the
system.
ì Postgame
ì Closure
:
ì Prepara>on
for
release,
including
final
documenta>on,
pre-‐release
staged
tes>ng,
and
release.
Planning
(1)
ì Defini>on
of
the
delivery
date
and
func>onality
of
one
or
more
releases.
ì Defini>on
of
project
team(s)
for
the
building
of
the
new
release.
Planning
(2)
ì The
group
then
determines
how
much
of
this
they
can
commit
to
complete
during
the
next
sprint
ì
and
records
this
in
the
sprint
backlog
ì During
a
sprint,
no
one
is
allowed
to
change
the
sprint
backlog
ì
which
means
that
the
requirements
are
frozen
for
that
sprint
ì
if
requirements
are
not
completed
for
any
reason
they
are
le<
out
and
returned
to
the
product
backlog
More
Game
phase(1)
ì Develop:
ì Defining
changes
needed
for
ì the
implementa>on
of
backlog
requirements
into
packets,
opening
the
packets,
performing
domain
analysis
ì designing,
developing,
implemen>ng,
tes>ng,
and
documen>ng
the
changes.
ì Development
consists
of
the
micro
process
of
discovery,
inven>on,
and
implementa>on.
ì Wrap:
ì Closing
the
packets,
crea>ng
an
executable
version
of
changes
and
how
they
implement
backlog
requirements.
More
Game
phase
(2)
ì Review:
ì All
teams
mee>ng
to
present
ì work
and
review
progress
ì raising
and
resolving
issues
and
problems
ì adding
new
backlog
items
ì Risk
is
reviewed
and
appropriate
responses
defined.
ì Adjust:
ì Consolida>ng
the
informa>on
gathered
from
the
review
mee>ng
into
affected
packets,
including
different
look
and
feel
and
new
proper>es.
Closure
ì The
ancillary
roles
in
Scrum
groups
are
those
with
no
formal
role
and
infrequent
involvement
in
the
Scrum
process
ì but
nonetheless,
must
be
taken
into
account.
ì Managers:
ì People
who
control
the
environment
Meetings
Overview
Meetings
ì These
mee>ngs
allow
clusters
of
groups
to
discuss
their
work,
focusing
especially
on
areas
of
overlap
and
integra>on.
ì The
agenda
will
be
the
same
as
the
Daily
Scrum,
plus
the
following
four
ques>ons:
ì What
has
your
group
done
since
we
last
met?
ì What
will
your
group
do
before
we
meet
again?
ì Is
anything
slowing
your
group
down
or
gemng
in
their
way?
ì Are
you
about
to
put
something
in
another
group’s
way?
Sprint
planning
meeting(1)
ì Takes
place
at
the
beginning
of
the
sprint
cycle
ì There
are
two
defined
ar>facts
resul>ng
from
this
mee>ng:
ì A
sprint
goal
ì A
sprint
backlog
ì A
sprint
goal
is
a
short,
one-‐
or
two-‐sentence,
descrip>on
of
what
the
team
plans
to
achieve
during
the
sprint.
ì It
is
wri[en
collabora>vely
by
the
team
and
the
product
owner
Sprint
planning
meeting(2)
ì The
team
asks
enough
ques>ons
so
that
they
can
turn
a
high-‐
level
user
story
of
the
product
backlog
into
the
more
detailed
tasks
of
the
sprint
backlog.
ì Sprint
Backlog
is
prepared
with
details
of
the
>me
it
will
take
to
do
a
par>cular
work
ì Iden>fy
and
communicate
how
much
of
the
work
is
likely
to
be
done
during
the
current
sprint
ì Eight
hour
>me
limit
ì (1st
four
hours)
Product
Owner
+
Group:
dialog
for
priori>zing
the
Product
Backlog
ì (2nd
four
hours)
Group
only:
hashing
out
a
plan
for
the
Sprint,
resul>ng
in
the
Sprint
Backlog
Sprint
review
meeting(1)
ì Held
at
the
end
of
each
sprint
during
which
the
Scrum
team
shows
what
they
accomplished
during
the
sprint.
ì Typically
this
takes
the
form
of
a
demo
of
the
new
features.
ì This
is
a
period
at
the
end
of
each
sprint
to
deliberately
reflect
on
how
the
team
is
doing
and
to
find
ways
to
improve.
ì Two
main
ques>ons
asked
in
the
sprint
retrospec>ve
are:
ì What
went
well
during
the
sprint?
ì What
could
be
improved
in
the
next
sprint?
Artifacts
ì The
values
in
product
backlog
are
o<en
stated
in
story
points
using
a
rounded
Fibonacci
sequence.
Product
Backlog(2)
ì It
is
the
list
of
work
the
Development
Team
must
address
during
the
next
sprint.
ì The
stories/features
are
broken
down
into
tasks
by
the
Development
Team
ì should
normally
be
between
four
and
sixteen
hours
of
work
ì O<en
an
accompanying
task
board
is
used
to
see
and
change
the
state
of
the
tasks
of
the
current
sprint,
ì like
“not
checked
out”,
“checked
out”
and
“done”.
Sprint
Backlog
Burndown
Charts
ì This
enables
organiza>ons
to
change
the
project
and
deliverables
at
any
point
in
>me,
delivering
the
most
appropriate
release.
ì The
SCRUM
methodology
frees
developers
to
devise
the
most
ingenious
solu>ons
throughout
the
project,
as
learning
occurs
and
the
environment
changes.
ì Small,
collabora>ve
teams
of
developers
are
able
to
share
tacit
knowledge
about
development
processes.
Advantages
(2)
ì h[p://en.wikipedia.org/wiki/Scrum_(development)
ì h[p://www.crisp.se/henrik.kniberg/presenta>ons/
Scrum-‐Intro-‐Brief-‐Henrik-‐Kniberg.pdf