Agile-Scrum Methodology-An Introduction

Introduction to Agile with Scrum

Agenda

•  Short
introduc,on
to
Agile

•  Scrum

– Overview

– How
it
works

2

Tradi4onal
So7ware
Project
Failures

•  Nearly
2
/
3
of
the
projects
are

signiﬁcantly
over
budget

•  64%
of
the
features
in
a
product
are

rarely
used

•  An
average
project
exceeds
its
schedule

by
100%

3

Main
Causes

•  Planning
for
comple4on
of
ac4vi4es
rather
than

features.

•  Progress
not
transparent
to
customers,
and
focus
on

ac4vi4es
leading
to
missing-‐forgoRen
features.

•  Specializa4on
leading
to
island
culture
and
reduced

involvement.

•  Do
not
work
on
the
basis
of
client
priority,
but
o7en

technical.
Team
starts
late
with
important
business

needs

•  Ignore
uncertainty
(changing
insights
/
requests?)

Limita4ons
of
Waterfall

"Waterfall"
project
approach
is
only
possible
if

•  Problem
is
clear;

•  Solu4on
is
known;

•  Technique
familiar;

•  Problem
has
not
changed;

•  A
suﬃcient
knowledge;

•  Priori4es
constant.

Suppor4ng
Agile
“Sentences”

1.  Our
highest
priority
is
to
sa4sfy
the
customer
through
early

and
frequent
delivery
of
valuable
so7ware.

2.  Deliver
working
so7ware
frequently,
from
a
couple
of

weeks
to
a
couple
of
months,
with
a
preference
for
the

shorter
4me
scale.

3.  Working
so7ware/product
is
the
primary
measure
of

progress.

4.  Welcome
changing
requirements,
even
late
in
development

5.  Business
people
and
developers
work
together
daily

throughout
the
project.

6.  Build
projects
around
mo4vated
individuals.

Give
them
the

environment
and
support
they
need,
and
trust
them
to
get

the
job
done.

Agile
Methodologies

•  Extreme
Programming
(XP)

•  Scrum

•  Feature-‐Driven
Development
(FDD)

•  Adap4ve
So7ware
Process

•  Crystal
Light
Methodologies

•  Dynamic
Systems
Development
Method

(DSDM)

•  Lean
Development

Scrum

A scrum is a term from rugby.

Scrum is a way of re-start
after minor violation, where a
group of players tries to push
the ball obtain control.

Sprints

•  Scrum
projects
consist
of
a
series
of
"sprints"

•  Typically
2-‐4
weeks
in
length.

•  A
ﬁxed
constant
length
gives
a
beRer
work
rate.

•  Features
are
designed,
built
and
tested
during
a

sprint.

•  Customer
can
not
change
job
during
a
sprint.

•  Have
a
sprint
goal.
A
brief
statement
about
the
focus

of
the
work
of
the

upcoming
sprint.

Product
Owner

•  Is
the
voice
of
the
customer.

•  Deﬁnes
the
features
of
a
product.

•  Determines
the
release
date.

•  Responsible
for
the
proﬁtability
of
a
product.

•  Its
mandate
is
to
make
decisions.

•  Priori4zes
the
product
features
based
on
market

value

•  Change
features
and
priority
every
itera4on,
if

desired.

•  Accepts
or
approves
work
results.

Team

•  Complete
(all
skills)

•  Self
and
self-‐learning

•  No
permanent
jobs

•  5
to
9
people

•  Work
together,
not
individually.

•  Involved

•  Produc4ve
and
fun

•  Preferably,
cross-‐func4onal.

Scrum
Master

•  Is
not
a
project
manager!
Facilitates
the
team.

•  Responsible
for
the
importa4on
and
compliance
with
Scrum

values
and
prac4ces.

•  Solves
problems
for
the
progress
of
projects
iden4ﬁed
by
the

team,
so
that
the
goal
of
Sprint
and
the
deliverables
are
met.

•  Ensures
that
the
team
is
fully
focused,
opera4onal
and

produc4ve.

•  Ensures
that
all
roles
and
func4ons
work
together.

•  Shields
the
team
from
external
disturbances
during
the
sprint.

Daily
Scrum

•  Daily,
15
minutes,
standing.

•  Not
meant
to
solve
problems.

•  Anyone
outside
the
team
may
be
present,
only
team

members
are
ac4ve

part
(speaking).

•  Helps
to
avoid
unnecessary
mee4ngs
(e
g
weekly
progress

mee4ng)

•  Are
not
intended
to
state
the
progress
or
management.

–  What
did
you
do
yesterday?
–  What
you
are
going
do
today?
–  Are
there
any
restric4ons
that
the
comple4on
of
the
sprint

at
risk?

Sprint
Review(Demo)

•  The
team
presents
the
results
of
the
last

sprint
through
a
demonstra4on
of
the

func4onality
built.

•  Informal,
no
slides,
max
2
hours.

•  The
whole
team
takes
part
in
the

demonstra4on.

•  Stakeholders
and
managers
are
welcome
to

aRend.

Sprint
Retrospec4ve

•  Is
held
a7er
each
sprint

•  Consider
what
works
and
what
does
not
work.

•  Priori4za4on
of
the
improvement.

•  Ac4on
items
are
deﬁned
to
ensure
that
real

improvements

takes
place
in
the
next
sprint
(s).

•  The
whole
team
takes
part
(Scrum
Master,
Product

Owner,
Team).

•  Dura4on
vary
depending
on
the
retrospec4ve

approach,
team
size,
length
sprint.
•  Usually
30-‐60
minutes

Product
Backlog

•  The
requirements

•  To
Do
list
of
all
the
work
required
in
the
project.

•  Expressed
from
the
user
/
client.

•  Not
how
but
why.

•  By
priority
(by
product
owner.)

•  Itera4ve
(changes
ok,
for
each
sprint).

•  Visible.

•  Items
es4mated
eﬀort
required
(by
team).

•  User story format: As <type of user> I want<some goal> so
that <some business reason>.

Sprint
Backlog

•  List
of
work
done
in
the
next
sprint.

•  Breakdown
of
features
into
tasks
(1-‐16
hours).

•  Tasks
are
not
assigned
to
team
members.
(More

variety
and
crea4vity.
No
knowledge
islands)

•  Tasks
are
es4mated
by
the
team
with
Planning

Poker.

•  Tasks
are
picked
based
on
the
right
priori4es
and
the

skills
of
team
member.

•  Is
usually
visualized
by
a
Scrum
board

Itera4on
Burn-‐down
Chart

Release
Burn-‐down
Chart

Deﬁni4on
of
Done

•  Is
determined
by
the
team

•  Completed
work
must
meet
this
deﬁni4on

•  Elements
to
consider
include:

–  Coding style
–  Code comment
–  Peer review
–  Units tests
–  Document
–  Manual
–  ???

Summary

•  Scrum
is
(almost)
'Magic':

– Timely
feedback.
– Focus
on
working
product.
– Priori4ze
on
added
value.
– Not
plan
ahead
in
detail.
– Self-‐management
and
responsibility.
– Clear
roles
and
responsibili4es.

Agile-Scrum Methodology-An Introduction

Agile-Scrum Methodology-An Introduction

More Related Content

What's hot (20)

Similar to Agile-Scrum Methodology-An Introduction (20)

More from XBOSoft (20)

Recently uploaded (20)

Agile-Scrum Methodology-An Introduction