Jira presentation.

1. Introduction to Agile with Scrum

2. Agenda
• Short
introduc,on
to
Agile
• Scrum
– Overview
– How
it
works
2

3. Tradi4onal
So7ware
Project
Failures
• Nearly
2
/
3
of
the
projects
are
significantly
over
budget
• 64%
of
the
features
in
a
product
are
rarely
used
• An
average
project
exceeds
its
schedule
by
100%
3

4. 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?)

5. Limita4ons
of
Waterfall
"Waterfall"
project
approach
is
only
possible
if
• Problem
is
clear;
• Solu4on
is
known;
• Technique
familiar;
• Problem
has
not
changed;
• A
sufficient
knowledge;
• Priori4es
constant.

6. Agile
Manifesto

7. 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.

8. Agile
Methodologies
• Extreme
Programming
(XP)
• Scrum
• Feature-­‐Driven
Development
(FDD)
• Adap4ve
So7ware
Process
• Crystal
Light
Methodologies
• Dynamic
Systems
Development
Method
(DSDM)
• Lean
Development

9. 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.

10. Scrum
Flow

11. Sprints
• Scrum
projects
consist
of
a
series
of
"sprints"
• Typically
2-­‐4
weeks
in
length.
• A
fixed
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.

12. Scrum
Framework

13. Product
Owner
• Is
the
voice
of
the
customer.
• Defines
the
features
of
a
product.
• Determines
the
release
date.
• Responsible
for
the
profitability
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.

14. 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.

15. 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
iden4fied
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.

16. Scrum
Framework

17. Sprint
Planning

18. Sprint
Planning

19. 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?

20. Daily
Scrum

21. 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.

22. Sprint
Retrospec4ve
• Is
held
a7er
each
sprint
• Consider
what
works
and
what
does
not
work.
• Priori4za4on
of
the
improvement.
• Ac4on
items
are
defined
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

23. Scrum
Framework

24. 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
effort
required
(by
team).
• User story format: As <type of user> I want<some goal> so
that <some business reason>.

25. Product
Backlog

26. 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

27. Planning
Poker

28. Scrum
Board

29. Scrum
Board

30. Itera4on
Burn-­‐down
Chart

31. Release
Burn-­‐down
Chart

32. Defini4on
of
Done
• Is
determined
by
the
team
• Completed
work
must
meet
this
defini4on
• Elements
to
consider
include:
– Coding style
– Code comment
– Peer review
– Units tests
– Document
– Manual
– ???

33. Scrum
Flow
Summary

34. 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.

35. To
be
con4nued…