You are on page 1of 60

SCRUM

Andreas Bach-Laursen
abla@iba.dk

Agenda
Project development
Agil vs. Sequential

SCRUM
Overview

SCRUM framework
Artefacts
Roles
Ceremonies

Me
Andreas Bach-Laursen
Underviser p Multimediadesign

Master it - IT, Communication and Organisation


B.Sc. Medialogy
Multimedia designe
Projektleder 3 r it- og reklamebranchen
NKT Cables, Tetra Pak, Bo Concept, ECCO, Lilly
It-konsulent 2 r
A.P. Mller - Mrsk, B&O, Danfoss, Grundfos, Visit
Denmark, Danish Parlament, NATO

Project
development

Project development
Agil vs. Sequential

Seqeuential

Project development
Sequential development (Waterfall)

Plan the project before starting

Complete one step before moving on to next


level

Never go back

Project development
Bennefits of waterfall

Approach is simple
It is more disciplined
Is well structured
the model itself progresses linearly through
discrete, easily understandable and explainable
phases

Provides easily markable milestones in the


development process.

Project development
Waterfall works when

Software projects that are stable


Unchanging requirements
Where it is possible that designers will be able to
fully predict problems

Where it is possible that designers produce a


correct design

Project development
Waterfall: Fail-late lifecycle

Project development
What does it mean?

A bug found in the early stages is


cheaper in money, effort, and time, to fix than
the same bug found later on in the process.

An early defect that is left undetected until


development or maintenance is estimated to
cost 50 to 200 times as much to fix as it would
have cost to fix at requirements time

Project development
Problems with Waterfall
Doesnt handle change very well
Requirements specifications are an abstraction

and can be interpreted differently


Business engagement is high at the start of the
project but then tapers off
Insufficient testing during development
Late integration
QA is trailer-hitched, so quality isnt baked in and
testing gets crunched at the end
Progress measured by task % complete
Often dont know until its too late
Whole project planned up-front

Agile

Project development
Agil development

Active user involvement


The team is empowered to make decisions
Requirements evolve but the timescale is fixed
Focus on frequent delivery of products
Testing is integrated throughout the projects
lifecycle

Project development
Agile Approach

Adaptive, empirical process


Small repeating cycles
Short-term planning with constant feedback,
inspection and adaptation

Fail-early lifecycle

Project development
Reasons to use Agile methods

Breaks complex projects down into


simpler mini-projects

Accommodates change easily


Improves ROI
Increased business involvement and satisfaction

Project development
Increased visibility
Lower development risk, higher quality, less
defects

Produce incremental product quickly


Progress measured by running tested software
Early and regular process improvement

Project development

SCRUM

www.youtube.com/watch?v=vmGMpME_phg

SCRUM overview
What is SCRUM?
A framework for developing and sustaining
complex products.

SCRUM overview
Focus on delivering the highest business value in
the shortest time

Allows us to rapidly and repeatedly inspect actual


working software (every two weeks to one
month)

The business sets the priorities


Teams self-organize to determine the best way to
deliver the highest priority features

Every two weeks to a month anyone can see real


working software and decide to release it as is or
continue to enhance it for another sprint

SCRUM overview
Why use SCRUM?
You don't know all requirements from the
beginning of a project/process

Requirement can change in the process


The process becomes unpredictable when new
technologies and tools are used

It is extremely effective!!!

SCRUM overview

Sprints
Scrum projects make progress in a series of
sprints

Typical duration is 24 weeks or a calendar


month at most

Sprints
Plan sprint durations around how long you
can commit to keeping change out of the sprint

A constant duration leads to a better rhythm


Product is designed, coded, and tested during
the sprint

NO CHANGES DURING A SPRINT!!!

SCRUM
framework

Scrum framework
Roles

Product owner
Scrum Master Ceremonie
Team
s Sprint planning

Sprint review
Sprint retrospective
Daily scrum
meeting

Artifacts

Product backlog
Sprint backlog
Burndown charts

Scrum framework
Roles

Product owner
Scrum Master Ceremonie
Team
s Sprint planning

Sprint review
Sprint retrospective
Daily scrum
meeting

Artifacts

Product backlog
Sprint backlog
Burndown charts

Product owner
Define the features of the product
Decide on release date and content
Beresponsible for the profitability of the product
(ROI)

Prioritize features according to market value


Adjustfeatures and priority every iteration, as
needed

Accept or reject work results


1 person!

The ScrumMaster
Responsible for enacting Scrum values and practices
Remove obstacles
Ensure that the team is fully functional and productive
Enable close cooperation across all roles and functions
Shield the team from external interferences

NOT A PROJECT MANAGER!!!!

The team
Typically 7 +/ 2 people
Cross-functional:
Programmers, testers, user experience
designers, etc.

Members should be full-time


May be exceptions (e.g., database administrator)

The team
Teams are self-organizing
Ideally, no titles but rarely a possibility
Membership should change only between sprints

Exercise: 60 steps in 60 seconds

Pair up 2 and 2: one person will be the manager,


one will be the worker

Goal: Produce 60 steps in 60 seconds


Instructions from manager:

Walk
Turn left
Turn right
Stop

Managers count the number of steps

The team
Self-organisation requires trust

Trust is only possible when team members feel


safe.

The team
Self Organizing Teams
Tightly Managed Teams

Self Organizing Teams

Take directions

Take initiative

Seek individual reward

Focus on team contribution

Focus on low-level objectives

Concentrate on solutions

Compete

Co-operate

Stop at pre-set goals

Continuosly improve

React to emergencies

Take steps to prevent


emergencies

Scrum values
Commitment, be willing to commit to the goal
Focus, do you job, dont worry about anything
else

Openness, everything is visible to everyone


Respect, respect the different people who make
the team

Courage, have courage to commit, to act, to be


open and expect respect

Scrum framework
Roles

Product owner
Scrum Master Ceremonie
Team
s Sprint planning

Sprint review
Sprint retrospective
Daily scrum
meeting

Artifacts

Product backlog
Sprint backlog
Burndown charts

Scrum framework
Roles

Product owner
Scrum Master Ceremonie
Team
s Sprint planning

Sprint review
Sprint retrospective
Daily scrum
meeting

Artifacts

Product backlog
Sprint backlog
Burndown charts

Product backlog
The requirements
A list of all desired work

This
This is
is the
the
product
product
backlog
backlog

on the project
Ideally expressed such
that each item has value
to the users or customers
of the product
Prioritized by the product
owner
Reprioritized at the start
of each sprint

A sample product
backlog
Backlog item

Estimate

Allow a guest to make a reservation

As a guest, I want to cancel a reservation.

As a guest, I want to change the dates of a


reservation.

As a hotel employee, I can run RevPAR reports


(revenue-per-available-room)

Improve exception handling

...

30

...

50

The sprint goal


A short statement of what the work will be
focused on during the sprint
Life Sciences
Database
Application
Make the application run on
SQL Server in addition to
Oracle.

Support features necessary for


population genetics studies.

Financial services
Support more technical
indicators than company ABC
with real-time, streaming data.

Managing the sprint


backlog
Individuals sign up for work of their own
choosing

Work is never assigned


Estimated work remaining is updated daily

Managing the sprint


backlog
Any team member can add, delete or change
the sprint backlog

Work for the sprint emerges


If work is unclear, define a sprint backlog item

with a larger amount of time and break it down


later

Update work remaining as more becomes


known

A sprint backlog
Tasks
Tasks

Code the user


interface
Code the middle tier
Test the middle tier
Write online help
Write the foo class
Add error logging

Mon
Mon Tues
Tues Wed
Wed Thur
Thur Fri
Fri
8

16

12

10

16

16

11

12
8

Hours

A sprint burndown chart

Tasks
Tasks

Mon
Mon Tues
Tues Wed
Wed Thur
Thur Fri
Fri

Code the user interface


Code the middle tier
Test the middle tier
Write online help

16

12

10

16

16

11

12

50
40
30
Hours

20
10
0

Mon

Tue

Wed

Thu

Fri

Scrum framework
Roles

Product owner
Scrum Master Ceremonie
Team
s Sprint planning

Sprint review
Sprint retrospective
Daily scrum
meeting

Artifacts

Product backlog
Sprint backlog
Burndown charts

Scrum framework
Roles

Product owner
Scrum Master Ceremonie
Team
s Sprint planning

Sprint review
Sprint retrospective
Daily scrum
meeting

Artifacts

Product backlog
Sprint backlog
Burndown charts

Team
Team
capacity
capacity
Product
Product
backlog
backlog
Business
Business
conditions
conditions

Sprint planning
meeting

Sprint
Analyze and evaluate product
prioritization

backlog
Select sprint goal

Sprint
Sprint goal
goal

Sprint
planning

Decide how to achieve sprint


Current
Current
product
product
Technolog
Technolog
yy

goal (design)
Create sprint backlog (tasks)
from product backlog items
(user stories / features)
Estimate sprint backlog in
hours

Sprint
Sprint
backlog
backlog

Sprint planning
Team selects items from the product backlog they
can commit to completing
Sprint backlog is created
Tasks are identified and each is estimated (1-16
hours)
Collaboratively, not done alone by the
ScrumMaster
High-level design is considered
As
Asaavacation
vacationplanner,
planner,IIwant
want
to
tosee
seephotos
photosof
ofthe
thehotels.
hotels.

Code the middle tier (8


hours)
Code the user interface (4)
Write test fixtures (4)
Code the foo class (6)
Update performance tests (4)

The daily scrum


Parameters
Daily
15-minutes
Stand-up

Not for problem solving


Whole world is invited
Only team members, ScrumMaster, product owner,
can talk

The daily scrum


Everyone answers 3 questions

What
What did
did you
you do
do yesterday?
yesterday?
What
What will
will you
you do
do today?
today?
Is
Is anything
anything in
in your
your way?
way?

1
2
3

These are not status for the ScrumMaster


They are commitments in front of peers

The sprint review


Team presents what it accomplished during the
sprint

Typically takes the form of a demo of new


features or underlying architecture

Informal
2-hour prep time rule
No slides

Whole team participates


Invite the world

Sprint retrospective

Periodically take a look at what is and is not working


Typically 1530 minutes
Done after every sprint
Whole team participates
ScrumMaster
Product owner
Team
Possibly customers and others

Scalability
Typical individual team is 7 2 people
Scalability comes from teams of teams
Factors in scaling
Type of application
Team size
Team dispersion
Project duration
Scrum has been used on multiple 500+
person projects

Scaling through the


Scrum of scrums

Summary
SCRUM is a framework for developing and sustaining
complex products.

Roles:
Product owner setting the scene of the project
Scrum Master facilitator
Team self organizing

Summary
Ceremonies:

Sprint planning - preplanning


Sprint review presentation of sprint results
Sprint retrospective - evaluation
Daily scrum meeting short daily meeting:

You might also like