SCRUM

1
Presentations

Est: 1 Pri: 1

2
Our environment

3
 Agenda
•Presentation

•Agile History and Manifesto

•Scrum

•Overview
•Roles
•Starting a project
•Managing requirements
•Estimating and planning
•Iteration life cycle
•Looking back

•Projectscalability
•Questions/Answers

4
 About you

•Who are you?

•What is your role?
•What do you know about agility?
•What are your expectations?

5
Questions
?

6
Reasons for
change

Est: 3 Pri: 2

"A company needs to be agile like a school of fish, acting

and reacting quickly, simultaneously and precisely."
Jean-Pierre Chardon, CEO Schneider France - 2006
7
 Projects…

•For you, what are the main

factors in project success and failure?

8
 Reasons for change: Facts
Successful
Project Project that failed on
32% one of the points
44%

Project cancelled
24%

Design
27%

Requirements
56%
Code
7%

Other
7%
9
Reasons for change:
Detailed specifications
Often
13%
Sometimes
16% Always
7%

Rarely
19%

Never used
45%

J.Johnson, Keynote speech, XP 2002 Italie

10
 Reasons for change:
According
to experts
Consolidated results

Methodology
22%

Managing the Human factors

requirement 50%
28%

The CHAOS report 2009, VersionOne June 08

11
 departments
Which are the most important factors in
developing your projects?

Cost control
59%

Others
9%

Flexibility
32%

•On average, a project costs 186% of its initial price

•66% of projects exceed the initial budget ("Empiral Software Engineering"

by Molokken 2003)
•84% of projects overrun the initial time schedule (Standish Group 2009)

12
 challenges

•Offering flexibility
•Considering change as an opportunity and not as a mistake
(requirement, method…)
•In cost management
•"You don't build software like you build a house"

•Replacing people and communication at the heart of the

project
•Breaking down barriers between project’s actors

•Guaranteeing software quality

•Time-to-market, globalization, competition, growing complexity…

•The need to deliver applications faster and more often
13
 Agile
History
and
Manifesto
Est: 2 Pr i: 2

"A matter of common sense"

Mike Cohn
14
Fifty years in the making

15
Agility: A state of mind

February 2001, Snowbird, Utah, USA 16

 Agile principles

•Welcome changing requirements, even late in development. Agile

processes harness change for the customer's competitive advantage.

•Simplicity--the art of maximizing the amount of work not done--is

essential.

•Continuous attention to technical excellence and good design

enhances agility.

17
 Collaboration principles

•Business people and developers must work together daily

throughout the project.

•The most efficient and effective method of conveying information to

and within a development team is face-to-face conversation.

18
 Delivery principles

•Our highest priority is to satisfy the customer

through early and continuous delivery of valuable software.

•Working software is the primary measure of progress.

•Deliver working software frequently, from a

couple of weeks to a couple of months, with a preference to the
shorter timescale.

19
 Team principles
•Build projects around motivated individuals. Give them the environment
and support they need, and trust them to get the job done.

•Agile processes promote sustainable development.

The sponsors, developers, and users should be able to maintain a
constant pace indefinitely.

•The best architectures, requirements, and designs emerge from self-

organizing teams.

•At regular intervals, the team reflects on how to become more effective,
then tunes and adjusts its behavior accordingly.
20
Questions
?

21
 Scrum
Overview

Est: 8 Pri: 1

"People love chopping wood.

In this activity one immediately sees results."
Albert Einstein
22
 Human values

• Modesty
• Courage
• Transparency
• Communication

23
 Process values

• Simplicity
• Visibility
• Feedback
• Adaptation

24
 Deming cycle
Iteration:
Defined sequence of activities carried out for several weeks according to a
plan and in accordance with evaluation criteria, resulting in the delivery
of a coherent, integrated and tested subset (software, documentation…).

1.Plan

2.Do

3.Check

4.Act
Repeat…

25
Scrum – the life cycle

24 hours

2 – 4 weeks

Adaptatio
n

26
 Roles
•Product Owner
•Guards the perimeter
•Validates deliveries
•“Co-Pilot” the Team

•Scrum Master
•Maintains the process
•Facilitator
•“Pilot” the Team

•Team
•Analyses and costs
•Produces the system
•Self-organized
•Cross-functional
27
 Role dynamics
Product Owner

Scrum Master

Facilitation

Product
Backlog

Facilitation
Application

Scrum Team

28
Committed or involved?

29
 Product Backlog
•A set of prioritized business requirements
•Requirements expressed as a User Story

•May evolve during Sprints

•Under the Product Owner's responsibility

30
 Sprint Backlog
•List of jobs to do for a Sprint
•Breaking down business requirements into costed tasks

•Under the team's responsibility

31
 Burndown Chart
•Monitoring what remains to be done during the
current Sprint
•Updated daily

•Under the Scrum Master's responsibility

Burndown Chart Sprint 10

Hours

Days 32
 Ceremonies
Scrum Meeting

TIMEBOX

Retrospectives

•Sprint
planning meeting
•Scrum meeting

•Demonstration

•Sprint review
•Sprint retrospective

33
Questions
?

34
 Starting
the project

Est: 3 Pri: 1

"Every project starts with a vision."

Bill Gates

35
 Where to start?

•You are about to start an agile project

•What do you do before kicking off the first

development Sprint?

36
 Sprint #0
ITERATION 0
• Vision
• Perimeter
• Participants, stakeholder, team member
• Roadmap

• Formalized vision
• Initial Product Backlog
• Roadmap and Release Plan
• Risk

37
The importance of Vision
No Vision With Vision
We want to be here

?
? ?

38
 Initial project perimeter
•Identify the main themes and requirements
•Discuss them until they are understood

Width

D
e
P
t
h

Perimeter

39
 Participants

Scrum
Team

Stakeholders
Experts

Manager Participant Informed

Contributor party
40
Initial Release Plan
Product Owner
roadmap and
major milestones

Release Plan
Timeboxed!

3 months 5 months
Release Plan 41
 Summary
•Vision
•Approach
•Perimeter: Initial Product Backlog
•Release Plan
•Participants
•Risk base initialization

•Prepare the development environment

•Work on the architecture
•…

42
Questions
?

43
 User
Stories

Est: 8 Pri: 1

“These days we do not program software module by module;

we program software feature by feature.”
Mary Poppendieck

44
 User Story: Definition
•A short description of a feature that is a source of value for
the product user or customer
•User Stories are found at the general specifications level

Place a job offer

As a recruiter I can place job offers

to hire new staff

Est: 5 Pri: 1
45
 User Story: Description format
•A unit of result not effort
•Written from a business point of view
•Very often based on an action

<Title>

As <role>,
I want <something>
to <achieve a goal>

Estimate Business priority

46
User Story: Jeffries' "3C"s
• Card
• The story is a short one (written on a 13×8 cm
card)
• Conversation
• Story details are discussed by the teams with
the business 1
• Confirmation Card
• The story is confirmed by acceptance tests
written at the same time as the story (on the
back of the card)

3 2
Confirmation Conversation

47
 User Story: Identification
•Who?
•User Stories are written by the Product Owner, possibly with help from the
Team

•When?
•When setting out the Product Backlog (User Story Workshop)

•During the end of Sprint

demonstration
•After a conversation with the Product
Owner that brings out a new User
Story

48
 criteria
•Conditions to be met so that the Product Owner will accept the User Story
at the end of the Sprint.
•Do this before the estimates!
•Every User Story must have one or more acceptance criteria.

View the file

on a book

As a web sur
fer, I can
look for a bo Acceptance crit
ok by specify eria
author, the t ing the 1 – At least one
itle or the IS book found mat
BN ches
the requested a
number. uthor and/or tit
le
2 – No book is f
ound for the
requested autho
r
3 – A single boo
k is found for a
given
ISBN number

49
User Story: The INVEST model
•The six Quality criteria for User Stories

Independent of other User Stories

Independent and of technology
Later discussion on details
Negotiable (second "C", Conversation)
A source of value for the product
Valuable user or end user

An ability to estimate the complexity of the

Estimable User Story by the implementation team

Size appropriately The ability to implement in one

iteration
Validated by the acceptance criteria
Testable (third "C", Confirmation)

50
 User Story: Epic
•A "Big" User Story awaiting breakdown into smaller User Stories

As a job se
eker,
I can look
for job
offers on m
Epic y own
terms
As a job se
eker,
I can look
for job
offers As a job se
eker,
I can view
details of
job offers
that match
my criteria
51
User Story and business priority
•Prioritization is seeking to optimize value for the business

•The Product Owner must identify the line of prioritization

•Financial gain (ROI)
•Development cost
•Knowledge acquired (Innovation)
•Risk management
•User satisfaction (Kano model)
•…

Every Story must be weighted with a business priority

52
 Managing User Stories
•All of the User Stories and Epics form the Product Backlog

Information radiator: Viewing the work to be done

53
Information radiator

54
Questions
?

55
 Agile
Estimates

Est: 13 Pri: 1

"It is a capital mistake to theorize before one

has data."
Sherlock Holmes

56
 Effort allocated to estimates

P
r
e
c
i High effort
s low gain of precision
i
o
n

Effort

A Pareto distribution
57
We need to know each other

How long does it take to cover the distance?

58
 Relative size and duration

Product Backlog Estimate in Extrapolation of the

with User Stories Story Points duration (planning)

59
 Story Points
Story Points represent a measurement of the effort
required by a team to implement a Story.

A Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, …)

T-shirt sizes (XS, S, M, L, XL)

Estimates use relative values!

60
 Velocity
Velocity is a production capacity measurement (for
implementing Stories) linked to a single team in the specific
context of a project.

Product Backlog Estimate in Extrapolation of the

with User Story Story Points duration with velocity
(planning)

61
 Pumpkin example
How long will it take to pick all of the pumpkins in the
field?

62
 Pumpkin example
After a walk through the field, we estimate
pumpkins in ‘Pumpkin points’ in relative value
terms.

5 Pumpkin points 21 Pumpkin points

3 Pumpkin points
63
 Pumpkin example
We are looking at a 1,000 Pumpkin point field.

64
 Pumpkin example
A trip is made with a full wheelbarrow.
We measure our velocity – 17 Pumpkin Points per Sprint.

65
 Pumpkin example
Our initial estimate is 60 Sprints.

66
 Best practice: Planning Poker
The entire team takes part: Multiple expert opinions

Individual vote: No influence

Guarantees dialog between players

Improves project awareness

Planning Poker works because it's fun

How many
points ?

67
 Slicing up a User Story
•Why?
•The Story is too big to fit into the iteration
•There isn't enough room left in the iteration to completely implement the Story
•The Team has trouble assessing the Story
•Slice an Epic into a Story

•How?
•In line with the Story's natural boundaries
•By reducing the scope
•By reducing the complexity
•By separating functional from non-functional aspects
•Slice up a Story if the descendents have different priorities

68
 Re-estimate User Stories
•Ask the question at the end of each Sprint

•Don'tre-estimate the entire Product Backlog but only the Stories that
experience leads you think that they will need adjusting

Velocity is the adjustment factor!

Iteration Lower Higher

multiplying multiplying

Estimation precision
69
Summary

Planning Poker Iteration Velocity

Story Points Calcuate effort Planification

estimation and duration

70
Questions
?

71
Agile Planning

Est: 8 Pri: 1

"No plan survives contact with the enemy."

Field Marshal Helmuth Graf von Moltke

72
 Agile planning
•Activities (planning, requirement, quality…) are thin down over the time
•No activities can be forgotten (plan and check in each iteration)
•Stuff to be done is adapted after each iteration to take into account the reality
•Changes (requirement or processes) are naturally supported by the process
•High visibility and driving ability for the customer

Iteration 1

Iteration 2

Iteration 3

Iteration 4

Predictable Uncertain Unpredictable

73
 Five planning levels
•Visibility over the entire project
•A number of levels of precision depending on distance

74
 Five planning levels

Roadmap

5 months 5 months

Requirements

4 weeks 4 weeks 4 weeks 4 weeks 4 weeks

75
 Production capacity
•Productioncapacity is the time available for creating value
(implementing Stories) over a period.

•To define the production capacity, remove from the total time available for
period:
•Planned activities (Scrum meeting, retrospectives, meetings…)
•All technical actions (installing software, machines, framework…)
▪Technical Story
•Time required to correct defects found during previous Sprints
▪Defect Story
•Time spent for the process (meeting…)
•Everything that does not directly create acquired value but that must be done as part of the project

Technical Story Defect Process

Production Capacity

76
 Planning the project
•With Velocity and Production Capacity, estimate the number of points that can be
achieved during each period (Release, Sprint, project)

•With the number of Product Backlog Story Points and the Velocity, estimate the
project workload (i.e. cost, duration…)

•During Sprint#0 the initial planning is done by estimating the Velocity (an expert
assessment)

77
 Release Backlog
•The Release Backlog is filled in using the Story Points and the Velocity
•Velocity and Story Points are a planning tool

•The Release Backlog may be refined after each Sprint

78
Questions
?

79
 Sprint

Est: 8 Pri: 1
"It’s amazing what you can accomplish if you do not care who
gets the credit."
Harry S. Truman

80
Anatomy of a Sprint

81
 Planning Meeting
•Product Owner and Team members area agree about the definition of “Done”

•The Team has estimated the User Stories

•The Team has stated its production capacity

•The Product Owner has reprioritized Stories where necessary

•The Product Owner may have adjusted the Release Plan
•Depending on velocity, demonstrations and new Stories
•The Product Owner has chosen Stories for the Sprint
•Depending on priorities and velocity
•The Product Owner has defined Story acceptance criteria
•All of the candidate Stories must have acceptance criteria

•The Scrum Master makes sure that everything is ready for the Sprint Planning Meeting

82
 Sprint Planning Meeting
•First part: Definition
•Product Owner and Team exchange on Stories
•Acceptance criteria are refined where necessary
•Stories included in the Sprint are selected
▪Depending on the Product Owner's priorities, technical constraints and risks involved

•Second part: Planning and organization

•The Team slices the Stories into tasks and estimates them (in hours)
▪All of the tasks needed to fully implement the Story
•The Team defines a strategy for implementing tasks
▪Who does what, dependencies, critical path…
•The Team validates the Sprint work backlog

83
 Task size
•Define the time-boxing rule: Ideal or real hours

•An "ideal hour" is an hour of productive work without any

interruption or distraction to affect production
•Abacus : Out of working time, 65% is used for production and some 35%
on something else (discussion, mail, coffee…)

Conn
ectio
•The task size should allow monitoring and n Sc
Crea reen
viewing progress tion
Grap o
hical f the
•Best practice: The size must be between 2 • HT inter
ML face
• Ja
and 16 hours va
• Te Script
st J
avas
cript
5h

84
 Writing tasks
•Tasksmust be written to validate the SMART model
•INVEST User Stories and SMART tasks

Specific Everyone has to understand the work to be

done
Is it possible to determine when the task is
Measurable finished?
Can the task owner finish the
Achievable task
during the Sprint?
Relevant Remain focused on the User
Story

Time-boxed The task needs to be numbered

85
 Spikes
•If the Team is having difficulty in slicing into tasks or in putting figures on
tasks, then time may be allocated to demystify the work to be done
•Spikes are considered to be tasks in their own right

86
 Strategies of detailed specifications

Product Owner Team

87
 Meeting
•The Sprint Backlog comprises all of the work that the Team plans to do
during the Sprint:
•Technical Stories (installation, framework, architecture, Spike…)
•Defect Stories
•User Stories to implement

88
Example Task board

89
Example Task board

90
Questions
?

91
 Scrum
Meeting

Est: 3 Pri: 1

"Everybody’s got a plan… Until they get hit."

Mike Tyson

92
 Scrum meeting
•A daily 15 minute progress meeting
✓What did I work on yesterday?
✓What am I going to work on today?
✓Did I hit any problems?
✓What's left to do by task

•Same place, same time,

everyday

•No Broken Windows!

“No good or bad news, just transparency”

Ken Schwaber
93 93
Scrum Meeting: Who does what?
Team:
•Stays concentrated on the Sprint contract
•Speaks only of Sprint tasks
•Handle's the day's work and assignments
•Coordinates and organizes work
•Assigns the rest to be done

Scrum Master:
•Leads the Team to avoid digressing onto other
subjects
•Challenges the Team to finish tasks in the correct
order 94
•Handles blocking or standby tasks
 Scrum Meeting benefits
Hour
•Progress is measured every day s

•Problems are identified early on

•Project knowledge is shared
•Lets you stay focused on the goal
•Ensures visibility for those involved
Time
(day)

95
Questions
?

96
Closing the
Sprint

Est: 5 Pri: 1

“How do I listen to others? As if everyone were my master

speaking to me his cherished last words.”
Hafiz
97
Sprint end meetings
•Sprint review
•Product demonstration
▪Getting feedback on product status
•Sprint results
▪Objectively measuring project progress

•Retrospectives
•Session with the Product Owner
▪What works
▪What works less well
▪What next
•Team “inspect and adapt” session
▪Improving Team practice
▪Helping the team to work in better conditions

98
 Sprint Review Meeting
•Product demonstration
•Reminder of Sprint targets
•User Story presentation by the Team
▪Real life product demonstration
•Evaluation of results by the Product Owner

•Sprint results
•Have Sprint goals been achieved?
•What problems were found with the product?
•Status of corrective actions
•What do people like and what works well?

99
 Retrospective
•Reflections on the process itself
•What works well?
•What doesn't work or can be improved?

•Principles
1.Discovering what we did right
2.Understanding what didn't work out
3.Finding ways to improve things
4.Exchanging and communicating

100
Planning improvement actions
•Identifying, prioritizing and planning actual actions to be undertaken
during the next Sprint

101
Questions
?

102
 Scrum
Scalability

Est: 5 Pri: 3
"Scrum starts to work when people understand it well enough to
create a proper application of it, before coming up with their own
process." Tobias Mayer

103
 of Scrums
•Each Scrum works on a set of Stories, but only on one Product Backlog
•Scrums are regularly synchronized during meetings with all of the Scrum Masters:
the Scrum of Scrums

Scrum of Scrums

104
 A Product Owner
•Minimizing dependencies
between Teams
•Teams work on orthogonal
functions
•Planning synchronization
between Teams as early as
possible

•Best practice: A Team is SM

responsible for the entire

product:
•Integration
•Tests and acceptance
•Other actions to transform SM

developments into an operational

product

105
 Area Product Owners
•Breaking down the project into
work batches
•Each work batch may have a
number of Scrums
•Work batch synchronization
with every Sprint or Release

•Scrum of Scrums for each work

batch
•A Super Scrum Master for each
work batch
•A "Scrum of Scrum of Scrums"
with the Super Scrum Masters

•Area Product Owners too need

to synchronize

106
 Scrum of Scrums
•The Scrum of Scrums is intended to align and coordinate Teams

•Tools:
•An Task Board for the Scrum of Scrums
•Flat screen, Webcam, Skype, Smart Board (for Teams geographically spread out)

107
Scrums

108
Questions
?

109
ABCdaire Project

110
Workshop presentation

111
Sprint #0
Vision

112
 Presentation
•ABCdaire is a library established in 1950 at Saint-Marman
•800 works in circulation (mainly books)
•300 regular customers
•Managed by hand using cards

•Owned by the Town Hall

•One full-time librarian
•One summer job (for a student)

113
 Positioning
•From the Town Hall's point of view
•Turnover hardly grows
•Just breaks even for the Town Hall
•The librarian is overworked but it is impossible to create another job

•From the customer's point of view

•Too few works
•Not enough new books added every year
•It is hard to schedule borrowing
•Wish to be able to borrow other media (Cartoons, CDs, DVDs, partitions…)
•Attractive membership price
•Internet access should be added

•Competition
•Local bookshop with all the latest books
•Digital works

114
 Actions
•Expanding the library
•By joining with surrounding towns
•Agreements with local elementary schools and high schools

•Computerizing the library

•Library management software
•Opening the library onto the Internet
•Training the librarian on computer tools

115
 Roadmap
September December March May September

Data migration and training

116
Scope

117
 Taking charge of the project
•You are all Product Owners
•It's your project!

•List the main project themes

•Between 5 and 10 themes
•One theme per Post-It
•Example: Managing customers, managing lending…

20 minutes
118
 Main themes
•Managing customers theme
•Managing catalog references theme
•Viewing the catalog theme
•Managing subscriptions theme
•Managing lending theme
•Buying works theme
•Generating statistics theme
•Reserving works theme
•Back Office theme (system administration)
•…

•Constraints
•Non functional requirement
119
 User
Story

120
 User Story
•You are all Product Owners

•Write the main User Stories for the themes

•One User Story per Post-It (at least 15 Stories)
•You may create new themes or epics

•Assign a business priority to each Story

30 minutes
121
 User Story

Add reference

As librarian, I can add the references of one or more

works (information on the work, ISBN code, number of
copies available, etc.) in the catalog.

Acceptation test:
1. Make sure that the librarian can add the reference of a work to the
catalog.
2. Make sure that the system handles multiple occurrences for a work.
3. Make sure that a new reference is added to the catalog only if all of
the data required for creating it has been entered.
Pri: 1

122
 User Story

Lost password

As a user, I must be able to recover my password.

This way I can keep my account active and continue to
borrow works.

Acceptation test:
1. Make sure that the user recovers their password after requesting it.

Pri: 3

123
 User Story: Epic

EPIC: Generating stats

As librarian, I can generate statistics on

customer borrowing.

124
 User Story: Constraints

Constraint

As a web user, I must be able to find a work in the

catalog, based on my criteria, in less than 90 seconds.

Acceptation test:
1. Make sure that the response time is less than 90s internally.
2. Make sure that the response time is less than 90s externally.

125
Story
Point

126
 Story Point
•Take turns at being Product Owners
•Choose the Stories you wish to use

•Estimate the Stories

•Use the Planning Poker games
•Exchanges between Team and Product Owner
•If necessary, refine the Stories and acceptance tests

35 minutes
127
 Story Point
Lost password
As a user, I must be able to recover my password.
This way I can keep my account active and continue to borrow
works. Planning Poker
Acceptance test:
1. Make sure that the user recovers their password after requesting it.

Lost password
As a user, I must be able to recover my password
by mail by entering my e-mail address (the one I gave when
creating my account).
This way I can keep my account active and continue to borrow
works.
Acceptance test:
1. Make sure that the user receives their password in their mailbox after requesting
it.

Est: 3
128
Planning

129
 Planning
•You are all Team Member
•Estimate your velocity
•Break down the Stories and determine how much time is needed
to fully implement them
•From this, deduce the estimated value of a Point

•Estimate the workload required to implement all of the Stories in the

Product Backlog as well as the Team size

•Estimate your production capacity (in Story Points)

•For the first Release
•For the first Sprints

35 minutes
130
Estimated value of a Story Point
Lost password
As a user, I must be able to recover my password by mail by
entering my e-mail address (the one I gave when creating my
account).
This way I can keep my account active and continue to borrow
works.
Acceptance test:
1. Make sure that the user receives their password in their mailbox after requesting
it.

Est: 3

To complete this User Story you need to:

- Write the detailed specifications : 0.75 days
- Develop the screen (Web MMI) : 1.00 day
- Develop the business classes : 1.75 days Estimated
- Pass the business tests : 0.50 days velocity
1 SP ≈ 1.3 days
4 days
131
 project

•Estimated Product Backlog: 650 Story Points

•Estimated velocity: 1 Story Point 1.3 days

•Tofinish the Product Backlog we need approx.: 650x1.3 ≈ 845 man days
•For technical actions (DB, servers, framework, architec…) ≈ 80 man days ≈ 1,100
•For meeting needed by the process (Scrum meeting…) ≈ 40 man days man/days
•Half-time Scrum Master workload: 170/2 ≈ 85 man days

•From September to May there are 170 working days

•Therefore a Team of (845+80+40)/170 ≈ 5 people (FTE) is needed to do the project

•Estimated Team velocity: 5 SP 1.3 days

132
 Sprint

•First Release (Sept -> Dec):

•This Release lasts for 80 working days
•This includes the equivalent of 7 days of ceremony (Sprint Meeting, Scrum Meeting,
Retrospectives)
•We estimate 4 days for technical meetings (architecture, framework…)
•We assume 50 man days of technical activity for the team, i.e. 50/5 = 10 days in delays
•Our estimated Velocity is 5SPs every 1.3 days or 1SP every 0.26 days
•We therefore project to create for (80-10-7-4)/0.26 ≈ 225 SP by the time of this Release

•First Sprint:
•A Sprint of 30 working day
•Production capacity ≈ 85 SP

133
 Sprint
meeting

134
 Sprint Meeting
•You are all Team members

•Break the Stories down into tasks and estimate tasks

•Work from the highest priority Stories
•Stop once the Sprint is full

•Prepare the Burndown chart

30 minutes
135
Burndown chart

136
 Daily
meeting

137
Burndown Charts?

138