Agile Scrum Foundation Training PDF

Agile Scrum Foundation training
Agile Scrum
Foundation Training
Erik Philippus
IMPROVEMENT BV
erik.philippus@improvement-services.nl
©IMPROVEMENT BV
www.improvement-services.nl
Planning Board
To Be Done In Progress Done

Backlog
The Es Welcome
senc & Introduction
of Agil e
e
2
12
SCRU
M
basics
22 Burn-down chart
70 70
68
Unplanned
Work 60
Story Points
Break
4
8
50
40
Agile
Contracting 30
3 20
Agile 10
Project
Planning
Questi
on
Wrap-u s
0
p
17
2 0 1 2 3 4 5 6 7 8
IMPROVEMENT BV ©2016
www.improvement-services.nl 1
Nice To Meet You!

Erik Philippus (1951)
IMPROVEMENT BV
35 years of experience in industrial automation

Foxboro, ESA, Philips, Assembléon, Vanderlande,
Vitatron, ASMI, Agilent, ASML, Imtech, NXP, …
Agile Development
•  Training, Certification & Workshops

•  Agile Architecting
•  Agile Implementation
www.improvement-services.nl
Archive login: ImprovemenT/Wachtw00rd
Planning Board

Backlog The Es
senc
Welcome
of Agil e & Introduction
e
2
12
SCRU
M
basics
22 Burn-down chart
70 70
68
Unplanned
Work 60 56
Story Points
Break
4
8
50
40
Agile
Contracting 30
3 20
Agile 10
Project
Planning
Questi
on
Wrap-u s
0
p
17
2 0 1 2 3 4 5 6 7 8
What is Agile?
Agility
•  English phrase:
in Dutch: ‘beweeglijk’, ‘wendbaar’, ‘gezwind’
•  Italian musical espression:

fast, trills, embellishments
•  Project Management:
the flexible and fast response of organizations
to unpredictable changes and customer demands
Agile:
The Art of Dealing with Uncertainty
I thought I was
interested in
uncertainty, but
now I’m not so
sure …
The Era of Predictability
The Horizon of Predictability
The Ghost of Uncertainty
The Agile Paradigm embraces

change, unpredictability and
unforeseen complexity
as inescapable constants
in all product development.
Uncertainty is part of every innovative

and creative development process.
The Waterfall Approach

Requirements
Design
Development
Testing
& Validation
Deployment
& Maintenance
lacking (customer)
feedback loops
-
loss of information at
transition moments
Managing The Development of Large Software Systems
Tangible Deliverables
The Primary Measure of progress
Traditional Agile
Requirements Requirements
50%
done Design Design
Development Development
Testing Testing
& Validation & Validation
50%
done
A Paradigm Shift
Predictive Adaptive
Traditional Agile
•  Customer knows what he wants •  Customer discovers what he wants

•  Engineers knows how to build it •  Engineer discovers how to build it
•  Nothing changes along the way •  Things change along the way
Mindsets
Fixed Mindset Agile Mindset
Ability Static Can Grow

Goal To look good To learn
Challenge Avoid Embrace
Failure Defines your identity Provides information
Effort For those without talent Path to mastery
Misfortune Helplessness Resilience
ImprovemenT Blog: Agile Mindset
Virtual Cattle-Grid
Response to Unpredictability
Predictive Adaptive
Decide early Decide late
Deliver slow Deliver fast
Waterfall Spiral Model Agile
value
value
value
Plan-Driven Incremental Value-Driven

Heavy-weight Light-weight
resilience
Historical Roots of Agile Methods
Agile Manifesto
Core Agile Values
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools

Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right,

we value the items on the left more.
Agile methods are people-oriented

rather then process-oriented
The Agile Alliance
Utah, Februari 2001
Agile Principles
•  Our highest priority is to satisfy the customer through early and
frequent delivery of high-quality software.
•  Welcome changing requirements, even late in development.

•  Business people and developers must work together daily
throughout the project.
•  Build projects around motivated individuals. Give them the

environment and support they need, and trust them to get the
job done.
•  The most efficient and effective method of conveying information
to and within a development team is face-to-face conversation.
•  At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly.
•  Agile processes promote sustainable development by

maintaining a constant pace.
Agile Myths
Popular Misconceptions
Agile is
Agile is Agile is
anti-planning
anti-documentation undisciplined
Agile
doesn’t scale Agile requires
a lot of rework Agile is
anti-architecture
Agile is only for

Agile is a software development
silver bullet
AG
IL
E
The Agile Family
•  Extreme Programming (XP)

•  Crystal Family
•  Dynamic Systems Development Method (DSDM Atern)
•  Test-driven Development (TDD)
•  Essential Unified Process
•  Agile Unified Process
•  Scrum
•  Kanban
Incremental Delivery:
don’t bite off more than you can chew
Visual Management
You Can’t Manage What You Can’t See
Communication by using visual signals

instead of texts or other written instructions.
information radiators
Time-Boxed Activities
Tasks are broken down

into small increments (2-4 weeks),
in which the team works through
a full development lifecycle
Creation of
a rhythm
•  Planning is more realistic with frequent releases

•  Allows project to adapt to changes quickly
Minimizes the overall project risk
Tangible Deliverables
Early and relevant

feedback is a vital
element of Agile!
Tolerance for Change
BDUF Big Design Up Front

BPUF Big Planning Up Front
Collaboration
Every Agile Team has

collective ownership
with respect to
challenges as well
as victories!
Agile = Teamwork
Continuous Learning
Step outside your comfort zone

to find new or better ways to
improve what it is you’re doing
Creativity
F.A.I.L = First Attempt In Learning
Empowered Teams
Analyst
Coder One of the aims of traditional

methodologies is to develop a
Tester
process where the people involved
Designer are replaceable parts (resources)
ability to work
Agile Teams are outside the core area
Small (6 ± 3),
Cross-functional & deep skills in
Self-Organizing a functional area
How Cross-Functional should my team be?
Focus on Customer & End-User

Always
Often 7%
13%
t have
If you don’
customer
the actual
in vo lv ed , you’re
Sometimes essing
just gu
16% ents
at requirem
Never
Rarely
45%
19%
Source: Standish Group Study Report
Hearing the voice of

customers and end-users
is fundamental for Agile
Prioritization
Don’t waste time working

on things that do not add
immediate value.
Work on the most important items first.

These are the things that add the most business value.
Prioritizing is more important

than time planning!
Communication
face-to-face
2 people communicating through:

Communication Effectiviness
whiteboard
telephone
email
paper
Richness of Communication
Increasing communication temperature is an

important goal of the Agile approach
Communication
Alignment Golden Rule:
“Try to understand before
you want to be understood”
Source: Steven Covey - The Habits of Highly Successfull People
Agile Manager:
Servant Leadership
•  Shared Vision
Distilling the customer’s grand vision into a meaningful plan
for everyone involved in the project
Layout a common set of understandings from which e
Don’t confus ip’
emergence, adaptation and collaboration can occur Leadersh ‘Servant
with
•  Environment ship’
‘No Leader
Enhancing team productivity by doing whatever possible
to minimize obstacles and optimization of the environment
Battling organizational dysfunctionality
•  Politics
Using the various agile mechanisms to minimize
politics and keep everything visible and obvious
•  Continuous Improvement
Promotion of an organizational culture
of continuous learning (from mistakes)
Agility:
Creating Value in an Unpredictable World
•  Productivity
•  Effectiveness
•  Product Quality
•  Reponse Times
•  Time-to-market
•  Customer Satisfaction
•  Employee Motivation
•  Continuous Learning
Agility is about staying successful in

complex, dynamic and
unpredictable environments
Agile Adoption
The Crucial Role of Management
Transformation impediments
are in most cases
management level related
Team level impediments, if any,

will dominate in the short run,
while management level impediments
dominate in the long run.
Paragraph on Agile Adoption
Agile Adoption
Common Obstacles
26%
52%
Project
complexity 26% Ability to change
organizational
22% Customer
culture
collaboration 41%
Confidence
in ability
General
to scale
31% resistance
to change
14%
Management
Perceived support
time to 35%
13% transition 33%
Trying to fit
14% Availability Agile elements
None of personal into a non-agile
Budget with the environment
constraints right skills
Agile Adoption
Success Rate
Traditional Agile
9%
29%
49% Challenged
57% 42% Success
14%
Failed
Source: The CHAOS Manifesto, Standish Group 2012
Agile System Development

‘the return of common sense’
Agile is an iterative and adaptive approach

to system development,
performed in a highly collaborative manner

by self-organizing teams,
with just enough ceremony that produces

high quality systems in a cost effective
and timely manner,
which meets the changing needs

of its stakeholders.
Planning Board

Backlog SC R U
M Welcome The Es
senc
basics & Introduction of Agil e
e
22 2
12
Burn-down chart
70 70
68
Unplanned
Work 60 56
Story Points
Break
4
8
50
40
Agile 34
Contracting 30
3 20
Agile 10
Project
Planning
Questi
on
Wrap-u s
0
p
17
2 0 1 2 3 4 5 6 7 8
Agile Scrum Essentials
Paragraph on Agile Scrum Topics
What is Scrum?
Scrum is a Framework
For Agile Project
Management
•  is a empirical process framework for developing and

maintaining complex products
•  delivers products of the highest possible business value
•  is simple to understand, but very challenging to master
•  has a history of success on a wide variety of projects
•  makes clear the relative efficacy of product management
and development practices
•  will surface (organizational) issues quickly, offering
possibilities for significant improvement
•  is not a silver bullet
Scrum and XP From the Trenches
Scrum Basics
scrum
master
product
owner
development
team
Scrum facilitates an incremental, feature-driven

& time-boxed product realisation process
Scrum in a Nutshell
2-4 week
Software Requirements
Problem with IEEE-830 style
software requirements:
•  Tedious to read, so readers skim or skip sections

•  Multi-interpretable, error-prone
•  Assumes everything is knowable in advance
If detailed requirements The user will get

are written down then
what he/she wants
You built what I At best, the user will

asked for, but it’s get what was written
not what I need
Requirements Specification
the formal way
1. The product shall have a gas engine

2. The product shall have four wheels
2.1 The product shall have a rubber tire
mounted to each wheel
3. The product shall have a steering wheel

4. The product shall have a steel body
Agile Requirements Specification

where the formal meets the informal
Define Motivations,
As a u
s Don’t Define Implementations
to be er, I want
comfo
while rtable
m
my la owing
wn.
As a u
s
to mo er, I want
w my
quick la
ly and wn
easy
What is a User Story ?
A user story is one or more sentences in understandable

language that captures what the user wants to achieve.
General Format:
As a [user role] I want [goal], so that I can achieve [value]
WHO WHAT WHY
Understanding the why facilitates

creative and original ways to solve the problem.
What is a User Story ?

exercise
Als een deelnemer aan deze training, wil ik ……..
Job Stories
alternative for/addition to User Stories
User Story
Persona Action Rationale
As a regular customer, when I purchase more than € 10.000

in goods, I become a preferred customer so that I will
receive a 10% discount on all prices.
Job Story
Expected
Situation Motivation
Outcome
When a customer purchases more than € 10.000 in goods,
he becomes a preferred customer so that he will receive
a 10% discount on all prices.
Why User Stories ?

•  User stories bring the customer perspective
into the project, providing a concise ‘hook’ for
business goals and user expectations
•  User stories are a medium for discussion and

prioritization of requirements with
(non-technical) stakeholders
•  User stories promote participatory design

and supports cross-functionality in the team
•  User stories will make clear what the users

actually need (instead of what they want)
•  User stories facilitate realistic project

monitoring and reliable release planning 51
Sample Product Backlog

Project Backlog: Landscape Exam Tool
Publicly
Visible
ID User Stories Estimation

(Story Points)
As a GIS administrator I want to restrict editing of

13
the State Forest Layer to only users in the Editor's role 5
so that this layer isn't accidently edited
11 As an Editor I want features in the State Forest Layer

to be automatically clipped by the Forest District Features 8
so that correct topology relationships are maintained
As a GIS administrator I want the system to block standard

5 deletions from the State Forest Layer, so that Users am
4
forced to formally dispose of the feature
Prioritised
Asby
an value
Editor Iand
want risk Includes
features in the State Forest to be
16 rough
automatically checked so that no features estimates
overlap 3
within the same layer
Sample Product Backlog

Project Backlog: Landscape Exam Tool
ID User Stories Estimation

(Story Points)
Are product features
As a GIS administrator I want to described within
restrict editing of the context
13 ofinthe customer/end-user
the State Forest Layer to only users the Editor's role 5
so that this layer isn't accidently edited
Have conditions of
As an Editor I want features in the State Forest Layer
11 satisfaction which can 8
to be automatically clipped by the Forest District Features
be tested
so that correct topology relationships at review/delivery
are maintained
As a GIS administrator I want the system to block standard

5 deletions from the State ForestHave
Layer, no or minimal
so that Users am dependency
on other user stories 4
forced to formally dispose of the feature
As an Editor I want features in the State Forest to be

May contain
automatically checked so that no features overlap a reference 3
16
within the same layer to detailed specifications
Fits into a single sprint

to keep the work flowing
The Product Backlog Pyramid
user
Sprint
stories
days
Release epic priority
weeks Refinement
(Grooming)
theme
months
Product Backlog Refinement

An ongoing, parallel activity
Continuous Sprint
increment
Refinement Development
The Product Backlog Pyramid

As a team member, I can specify files As a team member , I can indicate folders not
or folders to backup based on file size, to backup, so that my backup drive isn’t
date created and date modified, filled up with things I don’t need to save
Sprint
in order to facilitate an fast and
effective backup process.
days
As a project leader, I want to
provide my team with a tool that
enables them to easily backup
essential data, so that previous versions
Release
of project information can be retrieved priority
epic
weeks
As department manager,
I want to have the guarantee
that project data never get lost, theme
in order to guarantee an
uninterrupted workflow
months
Refinement
Toward Bit-Sized Chunks
Spike
Upfront Investigation & Dealing with Epics
Sometimes the scope and content of
user stories or epics can be understood
only after targeted analysis
A spike is a special type of story

for activities such as:
exploration, research, analysis, design,
proof of concept, prototyping, etc.
Gain knowledge necessary to:

•  Underline architectural trade-off decisions
•  Reduce risk of a certain technical approach
•  Better understanding of critical requirements
•  Increase reliability of high-level estimations
•  Disaggregate large user stories into constituent stories
Blog: Architecture Spikes

Spikes.pdf
Spike
Example
Epic:
As a consumer, I want to see my

daily energy use in a histogram
so that I can quickly understand
my past, current and projected
energy consumption
Technical Spike:
Research how long it takes to update a customer display
to current usage, determining communication requirements,
bandwidth, and whether to push or pull the data.
Functional Spike:
Prototype a histogram in the web portal and get some user feedback
on presentation size, style and charting
The Product Backlog:

shields the team from interference
high
priority
Each iteration implements Team
the highest priority
work items
Modifications
New work items are
prioritized and
Defects added to the stack
Patches
Work items may be
reprioritized
Customer
at any time
Requests
Market Work items may be

Demands removed
at any time
… low
priority
Dealing with high urgency items
high
priority
Each iteration implements Team
the highest priority
Add very urgent item to sprint backlog
work items
Modifications
New work items are
Remove prioritized and size from
item of similar
Defects sprint
added backlog
to the stack
Patches
Work items may be
reprioritized
Customer
at any time
Requests
Market Work items may be

Demands removed
at any time
… low
priority
Role of the Product Owner

responsible for product success
The Product Owner:
•  Owner of the Product Backlog

•  Understands the customer's needs and
carries the product vision to the team
•  Defines the features of the product
by writing (or authoring) user stories
•  Cares about user needs and is responsible for
maximizing the business value of the product
•  Collaborates with the team as the
customer representative
•  Priorizes features (user stories & epics)
•  Can change user stories and priorities
for upcoming sprint(s)
•  Accepts or rejects sprint results
Role of the Product Owner

A difficult and comprehensive role
The Product Owner is essential

for the overall succes of Scrum
Critical Factors:
•  Company-wide mandate
•  Product Backlog management
•  Availability
•  Team involvement
Prioritizing Requirements
Guidelines for prioritizing

user stories or epics:
•  The financial value of having the feature

•  The cost of developing / supporting the new feature
•  The amount and significance of learning and new knowledge
created by developing the feature
•  The amount of risk removed by developing the feature
•  The business impact of not (yet) having the feature
•  …
Relative Penalty
Prioritisation of user stories
Look at features from the perspective of how

users will be affected by the presence as well
as by the absence of the feature
Golden Rule:
Incorporate the relative penalty
in your prioritization
for absence or late delivery
of a feature
MoSCoW Method
Evaluation of requirements
minimal viable
product
M Must Have
O
S Should Have
C Could Have
O
W Won’t have
priority
If everything is top-priority,
you don’t have priority
Role of the Team

The Development Team:
•  Understands the details of
the (upper part of the) Product Backlog
•  Determines the relative effort needed to
realize the items on the Product Backlog
•  Decides how much productive time
it has available during the sprint
•  Decides how many product backlog items
it can commit to complete during the sprint
•  Delivers a ‘potentially shippable product’
at the end of every sprint
•  Organizes itself and its work
•  Demos work results to the Product Owner
Development Team
The Heart of Scrum
Critical Factors:
•  Significantly increased responsibility

•  Communication is key
•  Openness with respect to activities
•  Pro-active attitude
•  Team interest first
Definition of Done
Upfront Transparancy
The Development Team will start the work

only when the Definition of Done is crystal clear!
Single-Project Teams
team focus on one project
Each project Each team works

has its own on a single project
Product Backlog during the sprint
70
Capability Teams
team focus on field of expertise
Each team works on

multiple projects during the sprint
in line with their field of expertise
71
Single-Project Teams
Working on a single project in parallel
Single Project
Each team working
represented by a single
on the same
Product Backlog
Product Backlog
during the sprint
72
Multi-Project Team
working on several projects in parallel
One team, working

on multiple projects
during the sprint
73
Multi-Project Teams
The True Cost of Context Switching
Adding a single project to your workload

will drop productivity by 20%
Source: Gerald Weinberg on Quality Software Management : Systems Thinking
Multi-Project Teams
project A
multi
tasking project B
single
tasking project C
context switching
0 1 2 3 4 5 6 7
multi
tasking
single
tasking
0 1 2 3 4 5 6 7 8 9 10 11 12
Multi-Project Teams
Avoid Superfluous Project Context Switching
Multi-Project Teams
Prevent Overload and Excessive Multi-tasking!
itching
Context Sw
id er able,
is a cons
nd ofte n hidden)
(a
aste
source of w
How to organize individuals into Scrum teams
Scrum of Scrums
scaling Agile & synchronizing teams
system/platform architect
’System
Backlog’ 'meta' scrum team product manager
integration & test engineer
delegate team A
delegate team B
delegate team C
Backlog Backlog Backlog
scrum team A scrum team B scrum team C
Paragraph on Scaling Agile
Role of the Scrum Master

The Scrum Master:
•  Is the servant-leader of the Scrum team

•  Is the moderator for Scrum meetings
•  Takes care that the Agile/Scrum principles
are understood and enacted
•  Shields the Development Team from
external interferences
•  Removes obstacles that impede
team members
•  Enables close co-operation between
all Scrum roles and functions
•  Facilitates everybody the organization in
their understanding & adoption of Scrum
Scrum Master
Partner & Supporter of the Scrum Team
Capable to:
Foster an environment that enables the

team grow toward high-performance
•  Empower and encourage

the team to make decisions
•  Remove barriers and develop
a high level of trust
•  Resolving conflicts
Desirable Attributes
of a Good Scrum Master
Scrum Master
Promotion of Self-Empowerment
Team Formation
Every Scrum team will go through the steps of

forming, storming, norming and performing
Bruce Tuckman’s
Team Formation Model
Ideal Sprint Length
•  How often can stakeholders provide

feedback and guidance
•  Scrum familiarity in the organization
•  Level of experience and maturity within the team
•  Required co-ordination with other teams
•  Technical capabilities (e.g. automated acceptance testing)
•  Ability to decompose work
•  …
Sprint Length & Team Size
Sprint
Length
Team Size
Sprint Zero
Focus on team’s environment
•  setting up computers
•  creating team room
•  development environment
•  tooling
•  …
Preparation for first sprint
•  make high-level architecture overview

•  produce project charter
•  gather all relevant features
•  produce first version of product backlog
•  define ‘minimal viable product’
•  agree on default definition of done
•  …
Release Sprint
Hardening Sprint:
•  Performing time-consuming regression testing

•  Deploying the code from the Sandbox to Production Environment
•  Production data population
•  Setting up operational systems and processes
•  Training and handover for support staff
Not a dumping ground for sloppy work!
potentially shippable
shippable
Sprint Planning Meeting

WHAT - What is the goal of the next sprint?
•  Product Owner presents updated Product Backlog
•  Product Owner describes features to be realized
•  Product Owner indicates associated priorities
•  Development Team presents total number of available hours for the next sprint
•  Scrum Team agrees upon the Sprint Goal
HOW - How will the chosen work get done?

•  Product Owner clarifies Product Backlog items if needed
•  Team decides how to build the selected functionality into a product increment
•  Team breaks Product Backlog items (features) into tasks
•  Team may invite other people to provide technical or domain advice
•  Team presents a concise plan for realizing the Sprint Goal: the Sprint Backlog
Estimation of Productive Time
Team member A: 40 hours Rule of thumb:

Team member B: 20 hours
Team member C: 30 hours 6 effective hours per
Team member D: 10 hours 8-hour working day
No contingency planning!
Available: 100 hours
88
Task Breakdown
6 10
36h
4
5
7 5 8
3
4 9 4 10 8 27h
12 6 7
5
6 37h
7 5
user stories tasks 100 h

89
Bi-directional Commitment
The team forecasts the functionality

it will deliver in the upcoming Sprint
Management trusts the team and commits

to leave priorities alone during the sprint
Daily Scrum
visible communication
stand-up
task board =
no more meeting
'information radiator'
'submarine behavior' while standing up,
people are
more creative and
less individualistic
Each team member answers

the following 3 questions:
•  What did you do yesterday?

•  What will you do today?
•  What is in your way?
Commitment and timeboxed: 15 minutes!

understanding between peers,
not a management status meeting!
Scrum Task Board
Story To Do In Progress Done

8
Hours
As a design code doc test
user, I …. doc prep
12 4 6 8
6 8 12
Minimize WIP
As a test design
(work
prep
in progress)
user, I ….
Story points 11
3 doc code
4
6 8
As a test code doc code doc

user, I …. test design
3 5 7 test
3 5
8 4
12
code 4
Scrum Task Board

Identify Type of Work
Story To Do In Progress Done

8
As a design
doc code doc test
user, I …. prep
12 6 4 6 8
6 12
As a test design
prep
user, I ….
doc code
3 6 11 8
4
As a
test code design
doc code doc test
user, I …. test
3 3
5 5 7 12
4
8
4
code
4
Scrum Task Board

Visualizing Tasks On Hold
To Do In Progress
Story Done Impediments
8
As a design code test
user, I …. doc doc doc prep waiting
12 4 8 for spec
6 8 1 6 12
6 1
tool not
As a
available
test design prep
user, I …. 2
3 doc 11 code
4
6 8
As a test code doc doc

user, I …. test
3 5 7 test
3
8 4
code code
4
4 2 5
Sprint Burndown Chart
100
sappointing
80 Tackle a di
hours work remaining
burn do w n chart by
th e scope.
adjusting
60 ng fo r ex tra time
Goi idea,
is no t a go od
ly ev er a
and is hard
40 ai na bl e solution
sust
20
0
day 4
day 5
day 6
day 7
day 8
day 9
day 12
day 1
day 2
day 3
day 10
day 11

Daily Actualized Status
In Progress
Story To Do Done
8
As a design code doc test
user, I …. doc prep
12 6 4 6 8
6 8 12
As a test design prep

user, I ….
3 doc 4 11 code
4
6 8
As a test code doc code doc

user, I …. test design
3 5 7 test
3 5
8 4
12
code 4
total number of hours =

new point on burndown chart

example
Monitoring Progress
velocity
Sprint Burndown Chart Release Burndown Chart
Burn down charts promote:
•  Transparancy: visibility of time spent on not-agreed upon work

•  Alignment: absence of last-minute surprises
•  Adaptivity: facilitate timely corrective actions
•  Co-Creation: tracking is at the team-level, no blame-game
Burndown Chart Template
Scrum Review
Sprint Review Meeting:
•  The Team demonstrates what is accomplished

•  Product Owner accepts or rejects the
delivered product increment
•  Anyone can attend
•  Attendees collaborate on the next things that could be done
•  All the feedback is gathered
Sprint Review
The Issue of Quality
Demoing ‘Working Software’ is important,

but not enough
Requested Quality:
Part of the ‘Definition of Done’
Quality
‘Better than
requested’
y
is the enem
of ‘Don e’
Time Money
Devil’s Triangle ?
Quality Costs More Quality Saves
relevant product quality requirements must be

part of the ‘definition of done’ of selected tasks.
“What is Working Software?” – www.improvement-services.nl/blog/?p=344
Agile Testing
towards an integrated test process
•  Testing is not a distinct phase

Testing should be a continuous activity of any Agile team
Testing activities are integrated with the development process
•  Testing is not an exclusive activity

All team members must be prepared to perform test activities
Testing is not the sole responsibility of the designated tester
•  Testing when possible

Early testing, starting in phases of gathering requirements and
design, is highly recommended.
•  Test tools are indispensible

Advanced test tools and test automation are needed
•  Testing is part of the ‘definition of done’

A release or iteration is done when it is fully tested,
test results are processed, and problems are resolved
paragraph on Agile Testing
Test-driven Development
rapid cycle of testing, coding, and refactoring
a test will drive the code

to the next increment.
Test-driven Development.pdf
Retrospective
Continuous Learning
•  What is going well?

•  Where do we have a challenge?
•  What will we improve the next sprint?
Sprint Retrospective:
•  The Team inspects itself:

people, relationships, process and tools
•  The Team identifies the major items that went well
•  The Team identifies the potential improvements
•  The Team creates a strategy for implementing improvements
Starfish Retrospective
The Retrospective Starfish
Circles & Soup
Circles & Soup
ScrumBut
attempt to make a dysfunction invisible
syntax: [ScrumBut][Reason][Workaround]
Examples:
“[We use Scrum, but] [having a Daily Scrum every day is too much
overhead,] [so we only have one per week.]"
“[We use Scrum, but] [Retrospectives are a waste of time,]

[so we don't do them.]"
“[We use Scrum, but] [we can't build a piece of functionality in a

month,] [so our Sprints are 6 weeks long.]"
“[We use Scrum, but] [sometimes our managers give us special tasks,]
[so we don't always have time to meet our definition of done]"
Beware of Dogmatism
ImprovemenT Blog:
‘Beware of the Scrum Police!’
Scrum under Siege

insufficient
elaborated
resistance & User Stories Change of
lack of Team Composition
co-operation
Stretching
‘definition
of done’
Change of
Scope
Ineffective
handling of Interference &
Impediments Unplanned Work
Scrum Health Checks
Contra-indications for Scrum

•  Company
management is not committed or works against Agile principles
no understanding of Agile and Scrum
matrix numerous people into numerous projects
fixed time, fixed scope and fixed budget projects
•  Product Owner
there is not product owner at all
product owner is not available
product owner has no mandate of the organization
product owner has no access to real users or stakeholders
user stories not available or not suitable/ready for implementation
•  Development Team
team composition changes all the time
no cross-functionality possible due to missing expertise
daily interference and context switching
massive stream of unplanned work
no project focus: most team members are not dedicated
•  Product
full predictability/no innovation: all requirements are known upfront
work cannot be divided into smaller chunks
Agility & OTAP
Sprint planning
Ontwikkeling
Stand-up
Test
scrum Sprint review
Acceptatie
Release
Productie
Scrum in een OTAP omgeving
Continuous Integration
is a development practice that requires developers

to integrate their code into a shared respository
or mainline at least once a day.
Continuous
Delivery & Deployment
Continuous Delivery
is a series of practices designed to ensure that code
can be rapidly and safely deployed to production
by delivering every change to a production-like environment
Continuous Deployment
every change goes through the deployment pipeline
and is automatically deployed to production,
thereby ensuring business applications and services
function as expected through rigorous automated testing.
Continuous Deployment
Maximizing Reliability and Customer Resonsiveness
Every change automatically gets put into production,

resulting in many production deployments every day:
Company Deployment Deployment

Frequency Lead Time
Amazon 23.000/day minutes

Google 5.500/day minutes
Netflix 500/day minutes
Facebook 1/day hours
Twitter 3/week hours
Typical Enterprise once every 9 months months or quarters
Source: The Phoenix Project, Gene Kim et. al.
DevOps
Bridging Change and Stability
promotion of a set of processes and methods for thinking about
evOps
Dcommunication and collaboration between departments
es
small releas
ASL 2 BiSL
• 
al ov er head
minim
•  dardization
pipeline stan
LEAN
• 
pact & PRINCE 2
reduced im
DevOps ITIL
s
• 
ncey of incident
freque tMAP
OTAP SCRUM
Service & Maintenance:

We want to guarantee
high availability
Development: and stability!
We want to make
new features and
launch new versions! Paragraph on DevOps
Scrum & Prince 2

Prince 2 Agile Scrum
•  transactional •  collaborative
•  predict as precisely as feasible •  work with the business to

what is needed and what will happen capture as much value as possible
in a given time & budget
•  fixed scope, time & budget •  fixed time & budget

scope: evaluate, prioritise
& decide during the project
•  change must be controlled tightly •  change happens always,

we deal with it, anyway
Stage = Sprint
Senior User = Product Owner
Senior Supplier = Scrum Master
Paragraph on Prince2
Scrum Tooling
www.atlassian.com/software/jira
Planning Board

Backlog Welcome The Es
senc
Unplanned & Introduction of Agil e
Work e
2
4 12
SC R U
M
basics
22
Burn-down chart
70 70
68 Break
60 56 8
Story Points
50
40
Agile 34
Contracting 30 26
3 20 22
Agile 10
Project
Planning
Questi
on
Wrap-u s
0
p
17
2 0 1 2 3 4 5 6 7 8
High-Urgent Tasks
High-urgent, unplanned tasks

jeopardize the Sprint Planning
Dealing with Unplanned Work
Part of the team is busy with bug fixing,

instead of working toward the common sprint goal
How to effectively deal with

structural unplanned work ?
Lean:
Optimalization & Improvement
Kanban: work-flow optimalization
•  Visualization of the Work-Flow

•  Limitation of the Work in Progress (WIP)
•  Measurement of the Lead Time of Work-Items
•  Identification of Bottlenecks in the Process visual card/board
Work In Progress
Scrum Board Kanban Board
To do Ongoing Done To do Ongoing Done

2
A A
B B
C C
D D
FLOW FLOW
Scrum limits Kanban limits WIP

WIP per sprint per workflow state
Response Time
Scrum Board Kanban Board

2 2
A C A C D
E E
B D B
Wait until next sprint

Wait until work-item(s)
Average Response Time = move to next phase
(Sprint Duration)/2
Lifecycle
Scrum Board : From start to finish Kanban Board: At any time

2 2
A A A
B B B
C C C
D D D
Iterative Constant Flow
Scrum board is cleared Kanban board

after finishing the sprint is never reset
Tracking
Scrum: Team Velocity Kanban : Cycle Time

2 2
A A A A
B B B B
C C C
D D D
Team Velocity Cycle Time
Performance is Performance is
measured per sprint measured per work-item
Status Transparency
Scrum: In Progress Kanban : Tailor-made stages
To do Ongoing Ongoing Done

To do Ongoing Done Phase A Phase B
2 3 2
A B A
B
C
C
D
D E
Single ‘In Progress’ subdivided

‘In Progress’ Column into several stages
Monitoring Waiting Time

Scrum: No Waiting Tasks Kanban : Signalling Waiting Time
To do Ongoing Ongoing Done

To do Ongoing Done Phase A Phase B
2 3 2
ready
A A
B E D B
C F C
D
Stages without Stages subdivided into

‘Waiting’ state ‘in progress’ and ‘ready’
Scrum + Kanban
‘Dealing with urgent tasks using Scrumban.pdf’
Planning Board

Backlog Welcome The Es
senc
Agile & Introduction of Agil e
Contracting e
2
12
3
SC R U
M
basics
22
Burn-down chart
70 70
68 Break
Unplanned
60 56 8 Work
Story Points
50 4
40
34
30 26
20 22
19
Agile 10
Project
Planning
Questi
on
Wrap-u s
0
p
17
2 0 1 2 3 4 5 6 7 8
Traditional Contracting
Scope
Time
Cost
Quality
Fixed Time, Cost & Scope Contracts

•  Burned out programmers
•  No learning or discovery on the way
•  Rigorous change control increases cost
and proliferates non-value added work
•  Sacrifice of quality in case of problems
Recipe for death-march projects
Contract Types
making cooperation difficult
and hinder progress
increase the chance of

success for both parties
Which contract forms are best for

agile software development projects
and at the same time
commercially competitive?
Agile Contracting:
Evolutionary delivery in close co-operation with the customer
Variable Scope
•  Customers can change their minds
•  Suppliers aren't encouraged to sacrifice quality
•  Customer's and Supplier's interests are aligned
Incorporate customer
responsibility
Customers have what they want

at the project end, after they've learned,
instead of getting what they wanted
at the project start.
Variable Scope Contract:

Reversing the ‘Iron Triangle’
Plan-driven Value-driven
Subject to cost, time & quality risks Risk declines as project progresses
fixed functionality time resources

Plan-driven Fixed Fixed
approach time cost
creates cost/time Fixed
estimates scope Quality
Estimated
Quality scope Value-driven
approach
Estimated Estimated creates feature
cost time estimates
flexible resources time functionality
Variable Scope
Accumulated Business Value
the customer can swap

items not yet done
for an item of equal size
Time
Variable Scope
Dump this
one!
Accumulated Business Value
the customer can replace

items not yet done for
Need this a new item of equal size
one too!
Time
Agile Contracting
Reduction of the Probability of Mismatch
in-depth possible
waterfall
analysis, quotation, mismatch

detailed contract analysis design build test bug product
customer fixed time fixing delivery
demands, fixed budget
project fixed scope
plan
time
analysis& analysis& analysis& analysis& analysis&
design design design design design
product
backlog quotation, realization
agile
realization realization realization realization

with epics, contract
fixed time
agile test, test, test, test, test,
fixed budget
estimation bugfixing bugfixing bugfixing bugfixing bugfixing
variable
& planning scope
product product product product product possible
increment increment increment increment release mismatch
Variable Scope:
Share the Pain and the Gain
It takes two to tango
ient in
look your cl
the ey e an d say:
ide
‘I may prov
ib le sc ope, but
flex
s deliver
I will allway
lu e fo r m oney’.
va
Paragraph on Agile Contracting
Planning Board

Backlog Agile
Welcome The Es
senc
& Introduction of Agil e
Project e
Planning
2
17 12
SC R U
M
basics
22
Burn-down chart
70 70
68 Break
Unplanned
60 56 8 Work
Story Points
50 4
40 Agile
34
30 26
Contracting
20 22
19 3
10
Questi
on
Wrap-u s
0 2
2 0 1 2 3 4 5 6 7 8
Traditional Planning
A Joyless Track Record
Much work remains to be done before

we can announce our failure to make progress
Traditional Planning
Causes of Planning Failure
•  Planning is by activity rather than feature

- Parkinson's Law
•  Lateness is passed down the schedule

- Pattern: Anti-gravity Module
•  Multitasking causes further delays

- assigning work to individuals rather than to groups
- focus on high level of utilization of all individuals
•  Features are not developed by priority

- dropped features may be of greater value
than those that are delivered
•  Uncertainty is not acknowledged

- product specifications are generally imperfect or incomplete
- assignment of precise estimates to imprecise work
- estimates become commitments (or even deadlines)
Parkinson’s Law
Task-based planning
Work expands so as to fill

the time available for its completion.
Between 1935 and 1954 the staff

of the Colonial office increased
from 372 to 1661, over 400% -
while the responsibility of the
Colonial Office was declining.
By the time of the end of the

British Empire, the Department had
Colonial Office, London
its highest number of staff ever.
Activity Planning
A common pitfall
A critical problem with traditional planning

is that they focus on the completion of activities
rather than on the delivery of features.
Activity-based planning doesn’t guarantee

that customers get value from the completion of activities.
Features are the unit of customer value.
Planning should be at the level of features, not activities.
Anti-Gravity Module
Risky components are scheduled
to be completed last.
“The launch module is 98% built -

all we need is the antigravity module.”
Anti-Gravity Module
Risky components are scheduled
to be completed last.
high
avoid do first
risk
do last do second
“The
low launch module is 98% built -
all we need
low is thevalue
antigravity module.”
high
Agile Planning
Dealing with Uncertainty
response to
changing business
conditions adaptation
strict
conformance anticipation
to original plans
Agile Planning Principle #1:
Apply Multiple Levels of Planning
Product Vision 2 - 3 months 2 - 4 weeks 1 day
Roadmap
release iteration day
Release
Iteration
(sub-)system features tasks

Daily
Planning
focus of agile team

Use a Relative Measure of Size
traditional agile
absolute measure relative measure

of size of size
function points
lines of code
lead time story points
….
Absolute Measure of Size
?
?
?
? ?
?
?
Relative Measure of Size
?
10 ?
?
? ?
?
?
Story Points
A relative measure of size

requires a unit-less coefficient
Story Point
A Story Point is a unit of measure

for expressing the overall size of a
piece of work using relative values
What are Story Points?
2 Story Points
Assignment of Story Points

exercise
Assign s'
l Point
‘Anima owing
foll
to the :
br eds
e
Assignment of Story Points

exercise
Breed Animal Points
Lion
Kangaroo
Rhinocerus
Bear
Giraffe
Gorilla
Hippopotamus
Tiger
Country Points
Assign s'
y Point
‘Countr pian
to Euro s
countrie
Country Points
T-Shirt Sizes
Country Inhabitants
XL
Germany
Denmark
Estland L
United Kingdom
Belgium M
Spain
Poland S
Netherlands M
Cyprus
XS
Finland
Why Story Points?

•  Forces the use of relative estimating
studies have shown that we're better at relative estimating
(over one order of magnitude) rather than absolute estimating
•  Focuses us on the size, not the duration

story points are independent of the time needed for realization,
therefore, estimating in story points is typically faster
•  Puts estimates in units we can add together

time-based estimates are in most cases not additive,
(and may require obscure correction factors)
Story Points are a more usefull measure

for project velocity and release schedule
than using hours and days.
Sizing versus Work
Velocity
Velocity is a measure of a
team's rate of progress
Velocity is calculated by summing the number of

story points assigned to the user stories that
a team completed during one iteration
158
Velocity Example
= 2 story points
Project: Pile of Sand

Total amount of effort: 100 story points
Iteration length: 30 minutes
Team A : velocity = 25
Team B : velocity = 16
Team C : velocity = 2
Team D : velocity = 100
Velocity is a team-bound characteristic
Velocity
examples
How long will it take …
•  to read the latest Harry Potter book?
•  to drive from Amsterdam to Maastricht ?
Velocity Example
Project: Pile of Sand
= 2 story points = 4 story points
Estimation: 80 story points Estimation: 160 story points

4 sprints 4 sprints
Observed velocity: 20 Observed velocity: 40
Velocity depends on the applied estimation scale

Apply Consistent Scale for Estimations
The absolute value of estimates isn't crucial

What matters is that a consistent scale is used
Velocities can only be compared

when the same estimation scale
is applied during estimations
Dedicated estimation team ?

Use Actual Team Performance
Velocity always measures

the actual team performance.
A stable velocity incorporates all relevant

(positive and negative) factors that
influence the team output (including risk)
Velocity is an empirical attribute

of a Scrum team

Velocity is ‘the great rectifier’
Known velocity will prevent

overloading the team
Velocity will automatically compensate

the size of the work package proposed by the
Product Owner and accepted by
the Development Team at Sprint Planning
Velocity & Definition of Done
The team will earn storypoints only for

100% completed user stories!
Estimate Size, Derive Duration
ESTIMATION OF
1 week 2 weeks
RELATIVE SIZE
Story Points
+
Velocity
Stop arguing about

how long it will take ESTIMATION OF
DURATION
Agile Estimation in Practice
•  Utilize collaborate relative estimates

•  Prefer estimations by those who will do the work
•  Use an appropriate estimation scale
•  Remove all (political) bias from the estimate
Planning Poker
1 All the team members

have a set of cards
2 Product Owner explains & clarifies
the backlog item
3 Everyone selects and
simultaneously shows cards
4 If estimates vary significantly,
high and low estimators briefly
explain their estimates
5 Repeat steps 3-4 until estimates
stop converging
6 Decide estimate for backlog item
7 Move to next backlog item
Planning Poker
Exercise
ID User Story Story

points
1 As selling car owner, I need to clean and wax
my car in order to get a good price for it.
2 As a car owner, I want to have the interior of my car
completely cleaned, in order to travel comfortably.
3 As a car owner, I have to purchase and tryout a set
of snow-chains, in order to be safe when on winter holiday.
4 As a car owner, I need to replace the headlight bulb, since
the dimmed light is not functioning anymore.
5 As a car seller, I want to make an 2-page advertisement
for all the second-hand cars in my shop, to attract new
customers.
6 As a lover of classic cars, I want to renovate the metalwork
of my 1952 Citroen Traction Avant, since the body is rusty.
Planning Poker
why it works
•  Combining individual estimates through

group discussion leads to better overall estimates
•  Emphasizes relative estimating, hence we

don’t waste time in meaningless arguments
•  Everyone's opinion is heard, thereby minimizing

estimation bias and anchoring
•  It's quick and fun
see www.planningpoker.com
for planning poker for distributed teams
Agile Release Planning

example
Start of project
Velocity: 50
500
400
Project
Storypoints
Product Backlog
Size = 500 Story Points 300 Burndown Chart
200
100
Release Plan:
10 sprints 0
Sprint duration: 2 weeks
Forecasted Lead time: 20 weeks 1 2 3 4 5 6 7 8 9 10
Sprint

example
After 4 sprints
Velocity: 50
500
400
Project
Storypoints
Product Backlog
300 Burndown Chart
Remaining: 200
350 Story Points
6 sprints 100
Measures: 0
•  1 sprint extra
•  reduce scope 1 2 3 4 5 6 7 8 9 10
•  increase velocity Sprint

budgeting example
Start of project
member 1 1.0 FTE

member 2 0.8 FTE
member 3 0.8 FTE
member 4 0.6 FTE
member 5 1.0 FTE
Product Backlog Member 6 0.8 FTE
Size = 500 Story Points
Team 5.0 FTE
Project Budget:
Forecasted Lead time: 20 weeks for realization of 500 Story Points
Estimated Overall Cost: 20 x 5 FTE à $ 600/week = $ 60.000
Average Cost per Story Point: $ 60.000/500 = circa $ 120
Multi-Product
Release Planning
Multi-Team
Release Planning

Utilize Estimations & Velocities
The only variables of interest for

Agile project Planning are:
estimations & velocities
Reliability of Release Planning
Estimated Observed Reliable

Product Backlogs Team Velocities Release Planning
/ =
# storypoints/project # storypoints/sprint # sprints
Pssst - Agile will make us more predictable…
Food for Thought
Als je loslaat
heb je meer grip
Resumé
Agile Certification
•  Agile Foundation Certificate
Agile Consortium
domain: IT | area: Benelux, UK, Danmark | cost: € 175
traditional class-room exam 1h
ImprovemenT sample examination | certification guide
•  Professional Scrum Master Certificate

•  Professional Scrum Product Owner Certificate
Scrum.org
domain: software product development | cost: $ 150/$ 200
area: worldwide | on-line multiple-choice exam 1h
ImprovemenT sample examination | certification guide
•  Agile Scrum Foundation Certificate

EXIN
domain: IT/Project Management | cost: € 165
class-room or on-line multiple-choice exam
part of Certified Integrator Programme

Agile Scrum Foundation Training PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Agile Scrum Foundation Training PDF

Uploaded by

Copyright:

Available Formats

Agile Scrum Foundation training

To Be Done In Progress Done

Nice To Meet You!

35 years of experience in industrial automation

• Training, Certification & Workshops

To Be Done In Progress Done

• Italian musical espression:

The Era of Predictability

The Horizon of Predictability

The Ghost of Uncertainty

The Agile Paradigm embraces

Uncertainty is part of every innovative

The Waterfall Approach

Managing The Development of Large Software Systems

• Customer knows what he wants • Customer discovers what he wants

Fixed Mindset Agile Mindset

Ability Static Can Grow

ImprovemenT Blog: Agile Mindset

Waterfall Spiral Model Agile

Plan-Driven Incremental Value-Driven

Individuals and interactions over processes and tools

That is, while there is value in the items on the right,

Agile methods are people-oriented

• Welcome changing requirements, even late in development.

• Build projects around motivated individuals. Give them the

• Agile processes promote sustainable development by

Agile is only for

• Extreme Programming (XP)

Communication by using visual signals

Tasks are broken down

• Planning is more realistic with frequent releases

Minimizes the overall project risk

Early and relevant

Tolerance for Change

BDUF Big Design Up Front

Every Agile Team has

Step outside your comfort zone

F.A.I.L = First Attempt In Learning

Coder One of the aims of traditional

Agile Teams are outside the core area

How Cross-Functional should my team be?

Focus on Customer & End-User

Hearing the voice of

Don’t waste time working

Work on the most important items first.

Prioritizing is more important

2 people communicating through:

Increasing communication temperature is an

Source: Steven Covey - The Habits of Highly Successfull People

Agility is about staying successful in

Team level impediments, if any,

Paragraph on Agile Adoption

Source: The CHAOS Manifesto, Standish Group 2012

Agile System Development

Agile is an iterative and adaptive approach

performed in a highly collaborative manner

with just enough ceremony that produces

which meets the changing needs

To Be Done In Progress Done

Agile Scrum Essentials

Paragraph on Agile Scrum Topics

• is a empirical process framework for developing and

Scrum and XP From the Trenches

•  Training, Certification & Workshops

•  Italian musical espression:

•  Customer knows what he wants •  Customer discovers what he wants

•  Welcome changing requirements, even late in development.

•  Build projects around motivated individuals. Give them the

•  Agile processes promote sustainable development by

•  Extreme Programming (XP)

•  Planning is more realistic with frequent releases

•  is a empirical process framework for developing and

•  Tedious to read, so readers skim or skip sections

•  User stories are a medium for discussion and

•  User stories promote participatory design

•  User stories will make clear what the users

•  User stories facilitate realistic project

•  Owner of the Product Backlog

•  The financial value of having the feature

•  Significantly increased responsibility

•  Is the servant-leader of the Scrum team

•  Empower and encourage

•  How often can stakeholders provide

•  Scrum familiarity in the organization

•  Level of experience and maturity within the team