Untitled

Bootcamp Certification Scrum Master (PSM I) & Product Owner (PSPO) © Skills4All.
com | 2
Skills4All : Transformation, agilité, excellence opérationnelle
Bootcamp Certification Scrum Master (PSM I) & Product Owner (PSPO) © Skills4All.com | 3
Bootcamp
Certifications
Scrum Master (PSM)®
+ Professional Product
Owner (PSPO)®
Objectifs du cours
Connaître la méthode Scrum du point de vue du

Scrum Master et du Product Owner
Etre le mieux possible préparé pour la certification
PSM I de Scrum.org (SCRUM Master niv. I)
Etre le mieux possible préparé pour la certification
PSPO I de Scrum.org (Professional Product Owner
niv. I)
Préparation à la certification (PSM I)®
Ce support est basé sur le SCRUM Guide révision

2017
Autres références
Autres références
Agile Product Management with Scrum: Creating
Products That Customers Love Roman Pichler - ISBN 13:
9780321605788 or ISBN 10: 0321605780 Addison-Wesley
Professional; (2010)'Reilly Media; 1 edition (April 01st ,
2010)
Succeeding with Agile: Software Development Using
Scrum Mike Cohn - ISBN-13: 9780321579362 or ISBN-10:
0321579364 Addison-Wesley Professional; 1 edition
(October 1st , 2009)
The Art of Business Value Mark Schwartz & Kim, Gene -
ISBN: 9781942788058 IT Revolution Press; I edition (April
1st, 2016)
Nexus guide™ Ken Schwaber Scrum.Org (2015)
Scaled Agile framework 4.5, Leffingwell 2017
Avertissements
Avertissement sur le support de cours

le support est en Français
le vocabulaire a été gardé en Anglais (examen
seulement en Anglais)
Certains concepts sont répétés plusieurs fois dans
le déroulé du cours : c’est voulu
Sommaire
1. Introduction aux méthodes agiles

2. Introduction à SCRUM
3. SCRUM Team
4. Product Backlog
5. Sprints
6. Sprint Planning
7. Sprint Execution
8. Sprint Review
9. Sprint Retrospective
10. Autres outils et techniques
11. Scaling SCRUM
1. Introduction aux
méthodes agiles
Agile in the world (9th Annual State of Agile

Development Survey, 2017)
Caractéristiques d'une méthode de gestion de

projet classique
Les difficultés liées à la gestion de projets classique
La réponse agile
Principle of Waterfall vs Agile
Source : SAFe Scaled Agile Framework

Exemple d’application/différence
Courbe d'acceptation de Kübler-Ross

Proposition de valeur des méthodes agiles

Agile in the world (9th Annual State of Agile

Development Survey, 2017)
XP (Extreme Programming) : Méthode agile axée

sur les meilleures pratiques de développement
logiciel
Pratiques courantes :
Test-Driven Development
Collective Ownership
Refactoring
Continuous Integration
Pair Programming
Lean Software Development

Adapté des principes Lean engagés dans la fabrication
(développé d'abord par Toyota).
Concentrez-vous sur l'élimination des gaspillages tout
en augmentant la valeur des livraisons.
Apportez des améliorations en vous concentrant sur la
chaîne de valeur.
Principles
Éliminer les gaspillages
Créer de la connaissance
Construire la qualité
Livrer rapidement
Respecter les gens
Améliorer le système
DevOps
est un processus de développement et de livraison
de logiciels qui met l'accent sur la communication et
la collaboration entre la gestion de produits, le
développement de logiciels et les professionnels
des opérations.
DevOps automatise et surveille les processus
d'intégration logicielle, de test, de déploiement et
de modification de l'infrastructure en établissant
une culture et un environnement permettant la
création, le test et la livraison de logiciels
rapidement, fréquemment et de manière plus
fiable.
Source : wikipedia
SCRUM : Un cadre dans lequel les personnes peuvent

résoudre des problèmes adaptatifs complexes, tout
en fournissant de manière productive et créative des
produits de la plus haute valeur possible.
SCRUM est:
Léger
Simple à comprendre
Difficile à maîtriser
Evaluation de la maturité agile : Agilometer
Source : PRINCE2 Agile ©AXELOS

Manifeste Agile
Les 4 valeurs
Individus et échanges plus que processus et outils
Produit fonctionnel plus que documentation
pléthorique
Collaboration du client plus que négociation du
contrat
Réactivité au changement plus que suivi d'un plan
Manifeste Agile
Les 12 principes du développement Agile (1/4)
Notre priorité première est de satisfaire le client
en livrant au plus tôt et de manière constante un
produit de qualité.
Tout changement, même tardif, des exigences
pendant le développement est bienvenu.
Livrer régulièrement un produit fonctionnel, toutes
les deux semaines à deux mois, en préférant la
plus petite périodicité.
Manifeste Agile
Maîtrise d'ouvrage et développeurs doivent
collaborer quotidiennement tout au long du
projet.
Bâtir le projet avec des personnes motivées. Leur
donner l'environnement et le soutien dont elles
ont besoin et croire en leur capacité à accomplir le
travail.
La plus efficace des méthodes pour transmettre
l'information au sein et à destination d'une équipe
est le face à face.
Manifeste Agile
Un produit qui fonctionne est le meilleur
indicateur de progrès.
Les méthodes Agiles favorisent un rythme de
développement soutenable. Commanditaires,
développeurs et utilisateurs devraient pouvoir
maintenir ce rythme indéfiniment.
Une attention constante à l'excellence technique
et à la qualité de la conception améliore l'agilité.
Manifeste Agile
La simplicité - l'art de maximiser la quantité de
travail à ne pas faire – est essentielle.
Les meilleures architectures, spécifications et
conceptions sont issues d'équipes auto-organisées.
À intervalle régulier, l'équipe réfléchit aux moyens
de devenir plus efficace, puis modifie et ajuste son
comportement dans ce sens.
Les rôles dans les méthodes agiles

Un équilibre délicat
Autres principes Agiles

Variabilité & incertitude
Prédiction & adaptation
Validation de l'expérience
Work in process (WIP)
Progression
Performance
Autres principes Agiles

S'appuie sur la variabilité
Utilise les principes du développement itératif et
incrémental
Favorise l'inspection, l'adaptation et la transparence
Réduit toutes les formes d'incertitude simultanément
Progression
Performance
Autres principes agiles

Garde toutes les options ouvertes
Accepte qu'il n'est pas possible d'avoir la
perfection immédiatement
Favorise l'adaptativité et l'approche exploratoire
Adresse le changement sous un angle pragmatique
Progression
Performance

Idée : vérifier les hypothèses, rapidement
Lancer plusieurs boucles d'amélioration en même
temps
Organise le travail pour des feedbacks rapides
If fail, fail fast
Progression
Performance

S'appuyer sur des lots de taille raisonnable
Focus on idle work, not idle workers.
Prends en compte le coût des délais
Progression
Performance

Progression
S'adapte aux informations en temps réel et réagit
Mesure la progression par les livrables
Se focalise sur la valeur délivrée
Performance

Progression
Performance
Aller vite, mais jamais dans l'urgence
Construit la qualité
Réduire au maximum les cérémonials
2. Introduction à
SCRUM
SCRUM
Théorie SCRUM
SCRUM est basé sur l’Empyrical Process Control
Theory qui stipule que la connaissance vient de
l’expérience ET de la prise de décision sur ce qui
est connu
3 piliers :
Transparence
– Langage commun, définitions partagées
Inspection
– Montrer les réalisations et obtenir des feedbacks
Adaptation
– Ajuster l’appropriation de la méthode et la
connaissance du produit
SCRUM
Avec la méthode agile, on commence par créer un
Product Backlog : une liste priorisée des
fonctionnalités et autres capabilités nécessaires
pour développer le produit
Le travail est réalisé pendant de courtes itérations
Time-Boxed (limitées dans le temps) : entre 1
semaine et un mois
Durant chaque itération, une équipe auto-
organisée, auto-suffisante effectue tout le travail
(conception, construction, tests) nécessaire pour
produire les fonctionnalités qui seront mises en
production
SCRUM
A la fin de l'itération, l'équipe revoit les
fonctionnalités livrées avec les parties prenantes
pour obtenir leur feedback
Basé sur ces feedbacks, le Product Owner et
l'équipe modifient ce qu'ils pensaient réaliser et
comment ils pensaient le réaliser
A la fin de chaque itération, l'équipe devrait avoir
un Potentially Shippable « Done » Product
Increment, qui sera mis en production si il est
raisonnable de le faire
Scrum est un framework pour organiser et gérer le

travail
Scrum est simple, centré sur les individus
Scrum est basé sur les valeurs d'honnêteté,
d'ouverture, de courage, de respect, de confiance, de
motivation et de collaboration
Scrum framework
Product backlog Sprint goal
Sprint backlog
PBIs Tasks
Daily
Scrum
Sprint Planning
refinement
Sprint
Execution
Potentially
Sprint Shippable of « Done »
Sprint
Retrospective product
Review increment
Questions
1. What does it mean to say that an event has a time-box?

A) The event must happen at a set time.
B) The event must happen by a given time.
C) The event must take at least a minimum amount of time.
D) The event can take no more than a maximum amount of time.
2. It is mandatory that the product increment be released to production at the end

of each Sprint.
A) True
B) False
3. An organization has decided to adopt Scrum, but management wants to change the
terminology to fit with terminology already used. What will likely happen if this is done?
A) Without a new vocabulary as a reminder of the change, very little change may actually
happen.
B) The organization may not understand what has changed with Scrum and the benefits of
Scrum may be lost.
C) Management may feel less anxious.
D) All answers apply.
Questions
4. The three pillars of empirical process control are:

A) Respect For People, Kaizen, Eliminating Waste
B) Planning, Demonstration, Retrospective
C) Inspection, Transparency, Adaptation
D) Planning, Inspection, Adaptation
E) Transparency, Eliminating Waste, Kaizen
5. Which statement best describes Scrum?

A) A complete methodology that defines how to develop software.
B) A cookbook that defines best practices for software development.
C) A framework within which complex products in complex environments are developed.
D) A defined and predictive process that conforms to the principles of Scientific
Management.
3. SCRUM Team
3. SCRUM Team
Rôles Scrum
Les efforts de développement sont soutenus par
une ou plusieurs Scrum Teams
Scrum team
Product owner : définit ce qui doit être développé,
et dans quel ordre
Scrum Master : guide la Scrum Team pour qu'elle
puisse créer et suivre ses propres choix dans le
framework Scrum
Development team : détermine comment délivrer
ce que le Product Owner a demandé
3. SCRUM Team
La SCRUM Team
La Scrum Team complète les activités du Sprint en
effectuant 4 activités de type inspect-and-adapt
Sprint Planning
Daily Scrum
Sprint Review
Sprint Retrospective
3.1 Product Owner
3.1 Product Owner
Le Product Owner est le point central de décision

vis-à-vis du Produit
Responsabilités
Gère le rapport bénéfices/coûts
Participe aux réunions de planificiation
Refine/groome le Product Backlog
Définit les critères d'acceptation et vérifie qu'ils
sont respectés
Comprends la définition du Done
Collabore avec la Development Team
Collabore avec les parties prenantes
3.1 Product Owner
Le Product Owner
fournit des directives,
prend les décisions finales et veille à ce que l’équipe vise les
bons objectifs.
décide des releases
activement impliqué dans, communique bien avec et écoute
attentivement les arguments de l'équipe.
fournit la vision, mais aussi les limites dans lesquelles cette
vision doit être réalisée.
hiérarchise le Product Backlog axé sur la valeur métier.
s’assurer que le projet génère un bon retour sur investissement.
comprends l'entreprise et le marché, est la voix du client
(interne ou externe), gère le cycle de vie du produit ou du
service et établit un équilibre entre les besoins fonctionnels et
non fonctionnels.
3.1 Product Owner
Geoffrey Moore’s « Elevator Pitch »

For (target Customer)
Who (statement of need/opportunity)
The (product) is a (product category)
That (compelling benefit)
Unlike (primary competitive alternative)
Our product (primary differentiation)
For example, the iPod’s vision statement might read as:
• For music lovers
• Who want their music on the go
• The iPod is an MP3 Player
• That offers intuitive playback functionality
• Unlike Sandisk Sansa
• Our product is easy to use and synchs with our integrated music library iTunes
3.1 Product Owner
Le Product Owner est la seule personne responsable

de la gestion du Product Backlog :
Value optimizer
Exprimer clairement les PBIs
Prioriser les PBI pour atteindre au mieux les objectifs
business ;
Optimiser la valeur du travail effectué par l'équipe
de développement;
S'assurer que le Product Backlog est visible,
transparent et clair pour tous et montre ce sur quoi
l'équipe Scrum travaillera ensuite;
S'assurer que l'équipe de développement comprend
les éléments du Product Backlog au niveau requis
3.1 Product Owner
Value optimizer
La valeur, définie dans un contexte Scrum, est
l'avantage financier qu'une organisation reçoit ou
pourrait recevoir en créant et en diffusant le produit
en cours de développement (mais la valeur n'est pas
uniquement financière).
Le PO évaluera les résultats des efforts de
développement afin de fermer la boucle de feedback.
Le Product Owner ordonne le backlog pour optimiser
la valeur, mais il s'agit d'une valeur estimée, il est
donc important de voir si cette estimation ou cette
prévision de valeur se réalise réellement
La qualité est la préoccupation de l'équipe de
développement (définition du « Done »)
3.1 Product Owner
Expert du marché
Le PO doit connaître de manière experte le
marché du produit.
Il / elle doit constamment rassembler des
informations et des données concernant le
marché, afin de maximiser la valeur du produit.
Se déconnecter du marché peut être une recette
pour un désastre produit
Le PO ne devrait jamais avoir peur de changer de
vision ou de tactique en fonction des
changements du marché.
3.1 Product Owner
Prends les décisions par rapport aux Releases

Le PO est le seul à pouvoir décider de mettre en
production le dernier Product Increment.
le PO est responsable de l'évaluation et de la
communication des progrès vers un objectif ou de
la publication, au moins, de chaque Sprint dans la
Sprint Review
Afin d’obtenir la valeur du produit, une mise en
production doit avoir lieu ; au plus tôt on met en
production, au plut tôt la valeur est livrée ;
Le PO devrait travailler pour comprendre la
définition de "Done" de la Scrum Team
3.1 Product Owner
Lead Facilitator of key Stakeholder Involvment

Les parties prenantes clé sont généralement les clients, les
acheteurs, les utilisateurs et les personnes qui financent le
développement du produit.
Le PO est responsable de s'assurer que les principales parties
prenantes assistent et interagissent aux Sprint Reviews
La responsabilité du Product Owner est de maximiser la
valeur du produit dans son ensemble, ce qui implique un
équilibrage intelligent des intérêts.
Souvent, le PO mettra en relation les principales parties
prenantes avec les membres de l’équipe de développement
pour affiner le backlog ou obtenir des commentaires sur les
produits.
Assurez-vous simplement d'avoir un moyen de renvoyer les
résultats de ces collaborations au PO pour les tenir au courant.
3.1 Product Owner
Le PO est un membre actif et collaboratif de la

SCRUM Team
Le Product Owner devrait être hautement il faut éviter de modifier le S.Bck
afin de rester sur la bonne voie de
disponible pour des clarifications, la décision développement, mais si jamais on est
dans l’obligation de modifier car peut
d'ajouter ou de supprimer un périmètre à un aider à mieux atteindre le sprint goal :
Sprint déjà en cours - il s'agit d'une décision de négociation du sprint backlog entre le PO
et la Dev team.
collaboration entre le PO et la Development Team
Le PO est membre de l’équipe Scrum et, en tant
que tel, il respecte le framework Scrum.
3.1 Product Owner
Product Backlog Management Leader

Le PO est seul responsable des décisions à prendre
dans le Product Backlog.
Il a le dernier mot sur l'ordre du Product Backlog, et
ceux qui veulent changer l'ordre du PB doivent
influencer le PO pour le faire
N'oubliez pas que la gestion du PB pourrait être
entièrement déléguée à l'équipe de développement.
Il est donc fort possible que le PO ne crée ou n'écrive
jamais un User Story ou Product Backlog Item.
le PO est propriétaire des décisions concernant les
détails du backlog de produit, mais il se peut qu'il ne
soit pas en mesure de capturer ces détails.
3.1 Product Owner
Qui est le Product Owner ?

Attitude entrepreneuriale
Inclination à l’innovation
Open minded
100 % job
Vue du processus entier
Visionnaire et faiseur
Leader et joueur d'équipe
Communicateur et négociateur
Engagé et missionné
Disponible et Qualifié
3.1 Product Owner
Erreurs courantes à propos du PO

PO sans pouvoir
PO trop occupé
PO partial par rapport au produit
PO distant
Proxy-PO
PO de type « comité »
3.1 Product Owner
Qui est le Product Owner ?

Qu’est-ce que le Proxy-PO ?
Source : Scrum.org
3.1 Product Owner
Autres rôles
3.1 Product Owner
Hiérarchies de Product Owners

3.1 Product Owner
La journée d'un Product Owner

Participe
Product backlog Sprint backlog
Participe si possible
PBIs Tasks
Daily
Scrum
Sprint Planning
Réponds
Refinement Sprint aux
Execution questions
Participe
Potentially
Sprint Shippable « Done »
Sprint
Retrospective product increment
Review
Participe Participe
3.1 Product Owner
Le Scrum Master aide le Product Owner de

plusieur façons
Trouver des techniques pour une gestion efficace
du Product Backlog;
Aider la Scrum Team à comprendre le besoin de
PBIs clairs et concis;
Comprendre la planification des produits dans un
environnement empirique;
S'assurer que le PO sait comment organiser le
Product Backlog pour maximiser la valeur;
Comprendre et pratiquer l'agilité et,
Faciliter les événements Scrum à la demande ou
au besoin
3.2 Le SCRUM
Master
3.2 Le SCRUM Master
Scrum Master
aide tous les acteurs à comprendre et adhérer aux
principes et pratiques SCRUM
agit comme un coach, accompagnant et aidant la
Scrum Team et le reste de l'organisation à
développer sa propre approche Scrum
responsable de protéger l'équipe d'interférences
exterieures
3.2 Le SCRUM Master
Scrum Master
supprime les obstacles qui entravent la
productivité de la Scrum Team (quand la Scrum
Team elle-même ne peut raisonnablement pas les
supprimer)
fonctionne comme un leader, non comme un
manager
mais il a une « position de management »
3.2 Le SCRUM Master
Le Scrum Master
est un Coach
est un Servant Leader
a l'autorité vis-à-vis du processus Scrum
est un « impediment remover », il dégage la voie
est un agent du changement
3.3 La Development
Team
3.3 La Development Team
Scrum Team
Development Team
typiquement de 3 à 9 personnes maximum
peut être séparé en plusieurs Scrum Teams si une
équipe est insuffisante
les membres de l'équipe doivent collectivement
avoir toutes les compétences nécessaires pour
fournir un logiciel de bonne qualité, et
fonctionnant correctement
Scrum définit la Development Team comme étant
cross-functional, auto-organisatrice
3.3 La Development Team
Caractéristiques
Self-organizing
Cross-functionnaly diverse & sufficient
T-shaped skills (broad & deep)
attitude « mousquetaire »
high-bandwidth attitude
communication transparente
taille adaptée (environ 9 personnes)
engagée et focalisée sur les livrables
travaille à un rythme soutenu et soutenable
(sustainable pace)
équipe long terme
3. SCRUM Team
Autres éléments
La Scrum Team complète les activités du Sprint en
effectuant 4 activités de type inspect-and-adapt
Sprint Planning
Daily Scrum
Sprint Review
Questions
1. Scrum does not have a role called "project manager."

A) True
B) False
2. The Development Team should have all the skills needed to:
A) Complete the project as estimated when the date and cost are committed to the Product
Owner.
B) Do all of the development work, except for specialized testing that requires additional
tools and environments.
C) Turn the Product Backlog items it selects into an increment of potentially releasable
product functionality.
3. Who should know the most about the progress toward a business objective or a release, and
be able to explain the alternatives most clearly?
A) The Product Owner
B) The Development Team
C) The Scrum Master
D) The Project Manager
Questions
4. What are the two primary ways a Scrum Master keeps a Development Team working at its
highest level of productivity?
A) By facilitating Development Team decisions
B) By removing impediments that hinder the Development Team
C) By starting and ending the meetings at the proper time
D) By keeping high value features high in the Product Backlog
5. Which statement best describes a Product Owner's responsibility?

A) Optimizing the value of the work the Development Team does.
B) Directing the Development Team.
C) Managing the project and ensuring that the work meets the commitments to the
stakeholders.
D) Keeping stakeholders at bay.
Questions
6. What is the role of Management in Scrum?

A) Continually monitor staffing levels of the Development Team.
B) Monitor the Development Team's productivity.
C) Support the Product Owner with insights and information into high value product and
system capabilities. Support the Scrum Master to cause organizational change that fosters
empiricism, self-organization, bottom-up intelligence, and intelligent release of software.
D) Identify and remove people that aren't working hard enough.
7. The CEO asks the Development Team to add a "very important" item to a Sprint that is in
progress. What should the Development Team do?
A) Add the item to the current Sprint without any adjustments.
B) Add the item to the current Sprint and drop an item of equal size.
C) Add the item to the next Sprint.
D) Inform the Product Owner so he/she can work with the CEO.
4. Product Backlog
4. Product Backlog
Liste priorisée des fonctionnalités du produit

Un Produit, un Product Backlog
Product backlog Sprint backlog
PBIs Tasks
Daily
Scrum
Sprint Planning
Refinement Sprint
Execution
Potentially
Sprint Sprint Shippable of « Done »
Retrospective Review product
increment
4. Product Backlog
avec Scrum, on développe toujours en premier le

travail avec la plus forte valeur ajoutée
c'est le Product Owner qui détermine cette liste de
fonctionnalités, avec l'avis du reste de la Scrum Team
les éléments du Product Backlog, Product Backlog
Items (PBIs) sont des éléments requis pour atteindre
la vision du Product Owner
au tout départ, il n'y a que des User Stories
plus tard, le Product Backlog peut aussi contenir de
nouvelles fonctionnalités, des fonctionnalités
changées, de la correction de défauts, de
l'amélioration technique, etc
4. Product Backlog
Les PBIs en haut de Product Backlog sont détaillés

de sorte qu’ils puissent être réalisés pendant le(s)
Sprint(s) à venir
Les PBIs pouvant être sélectionnés pour être
« Done » dans le Sprint à venir sont considérés
« Ready »
Il n’y a pas de description de « Ready » dans le
Scrum Guide
4. Product Backlog
Structure
Fonctionnalité A Priorité haute

Fonctionnalité B
Fonctionnalité C
Défaut 121
Fonctionnalité D
Refonte Y1
Fonctionnalité E
Fonctionnalité F Priorité basse

4. Product Backlog
Product Backlog Refinement (grooming)
l’estimation en temps apparaitra dans le sprint backlog
Estimation en point au lieu de temps, ex : une

fonctionnalité nécessite 30 pts, ça rend les choses
relatives, cette estimation est basée sur le REX, « X pts
pour ne fonctionnalité Y »
Créer et
préciser Prioriser
Estimer
4. Product Backlog
Estimer la taille des Product Backlog Items (PBI)

la taille doit être relative, tels que des story points
ou ideal days.
la taille relative des PBIs est comparée aux autres
PBIs considérés
Fonctionnalité A 2
Fonctionnalité B 3
Fonctionnalité C 8
Défaut 121 15
4. Product Backlog
Product Backlog Items (PBI)

éléments de fonctionnalités qui livrent de la
valeur au client ou à l'utilisateur
souvent exprimés sous la forme de user stories
4. Product Backlog
Caractéristiques d'un bon Product Backlog

Détaillé de façon appropriée
Emergent
Estimé
Priorisé
4. Product Backlog

les PBIs n'ont pas tous les mêmes niveaux de détail
les PBIs qui doivent être livrés rapidement sont au
sommet du Product Backlog, sont petits en taille,
et très détaillés
au fur et à mesure qu'on s'approche des PBI plus
larges, comme les epics, on décompose la user
story en collection de user stories plus petites
Emergent
Estimé
Priorisé
4. Product Backlog

Emergent
Le Product Backlog est continuellement mis à jour,
en fonction du flux continu d'informations qui
parvient à la Scrum Team
la structure du Product Backlog émerge
constamment dans le temps
au fil de l'arrivée de nouveaux requirements ou de
l'affinage d'anciens requirements, le Product
Owner doit reprioriser les PBIs
Estimé
Priorisé
4. Product Backlog

Emergent
Estimé Taille
Chaque PBI a une estimation en termes 2
2
de charge nécessaire pour le développer 4
les PBIs en haut du Product Backlog sont 5
petits, détaillés, leur estimation devrait 5
être meilleure 12
il peut ne pas être possible d'estimer la 23
durée d'un PBI de façon précise, surtout
41
s'il s'agit d'un epic. On utilise alors les
tailles de T-shirt (L, XL, XXL, etc.)
L
Priorisé
XL
4. Product Backlog

Detaillé de façon appropriée
Emergent
Estimé
Priorisé : le PO est responsable de l’ordre des PBIs, et
N sprints aussi des releases, c’est lui qui déclenche
une mise en prod ou pas
Haute priorité
Release 1
Release 2
Release 3
Faible priorité
4. Product Backlog
Product Backlog & refinement responsabilité du PO PBI Taille

créer et affiner (ajouter des détails aux) Estimation
PBIs, estimer les PBIs, prioriser les PBIs PBI inséré
effort collaboratif dirigé par le Product

Owner, avec la participation d'autres Re-priorisation
parties prenantes, de même que le Scrum

Master et la Development Team
Scrum ne dit pas quand on doit
exactement refiner le P.Bck, dés qu’il le
faut on le fait, comme on peut fixer un Taille originale du PBI Affiner PBIs
jour de la semaine pour le faire, on peut
demander l’avis d’autre personnes
« experts
Supprimer PBI
4. Product Backlog
Product Backlog & refinement

Le framework Scrum indique seulement qu'il faut
refiner/groomer le Product Backlog ; il ne dit pas
quand
parfois, les équipes préfèrent répartir le grooming
à travers le sprint, et ne pas bloquer un moment
pré-déterminé pour cela
parfois, les équipes prennent un moment après
leur Daily Scrum pour refiner/groomer le Product
Backlog
4. Product Backlog
Product Backlog ordering

Valeur aux clients existants
Valeur aux prospects
Valeur pour la viabilité à long terme
Risques pour l’entreprise ou le marché
Dépendances
Engagements
Complexité/taille
Effort
4. Product Backlog
Requirements
sont exprimés sous la forme de Product Backlog
Items (PBI)
initialement, les PBIs sont vastes et il y a peu de
détails les concernant
ils sont exprimés sous la forme de User Stories
au fil du temps, on précise ces PBIs grâce aux
conversations entre la Scrum Team et d'autres
parties prenantes, décomposant les PBIs en PBIs
plus détaillés
il s'agit de « progressive refinement »
4. Product Backlog
User Stories
Scrum voit les requirements comme des leviers
importants qui peuvent être utilisés pour
atteindre les objectifs métier
on arrive à court de temps ou de budget → on
retire des requirements on rajoute les nouveaux requirements au début du P.Bck
de nouvelles informations indiquent que le

cost/benefit ratio d'un requirement n'est plus
favorable →on retire le requirement du Product
Backlog
de nouveaux requirements à forte valeur sont
identifiés → on les ajoute au Product Backlog
4. Product Backlog
User Stories
format très pratique pour exprimer des besoins
métiers pour de nombreux PBIs, spécialement
pour les requirements
rends les requirements compréhensibles par les
métiers et les équipes techniques
peuvent être écrits à divers niveaux de granularité
et peuvent être facilement affinés
R. Jeffries les décrit selon les « 3 C »
Card
Conversation
Confirmation
4. Product Backlog
User Stories
Card
sur des post-it
spécifie les « user roles »
précise le but que le rôle veut atteindre (goal)
précise pourquoi le rôle veut atteindre ce but
(benefit)
petit, avec peu d'explications, pour inciter à la
brièveté
4. Product Backlog
User Stories
Conversation
les détails des requirements sont exprimés et Dev + PO + stakeholders
communiqués via une « conversation » entre la
development team, le product owner, les parties
prenantes
les user stories peuvent et devraient être
complétés de toutes les informations nécessaires à
leur compréhension
4. Product Backlog
User Stories
Confirmation
préciser les conditions de la satisfaction
préciser les critères d'acceptation (voir plus loin vs
définition du « Done »)
face avant : description de la user story
face arrière : conditions de satisfaction ou de test
4. Product Backlog
User Stories
Personna
Persona : technique pour faire émerger les profils
d’utilisateur de l’application
On personnifie le profil
On lui donne un nom, une photo
On décrit son caractère, ses attentes, etc.
On indique ce qu’il attend d’une telle application
On ne parle plus "des" utilisateurs, mais de Jean-
François : l’acheteur, ou Maryse
4. Product Backlog
User Stories
Niveau de détail
les user stories peuvent être rédigées à divers
niveaux de détail
le plus bas niveau de détail correspond aux
« epics », qui peuvent englober le travail de
plusieurs mois
Jour (« Ready » pour le sprint)

Heure (tâches)
durée : semaine à sprint

Semaines (>sprint)
Mois (>release) (epic) release : plusieurs sprints

4. Product Backlog
User Stories
Indépendants
Négociables INVEST
Valorisables
Estimables
Dimensionnés de façon adaptée (Small)
Testables
4. Product Backlog
Technique : Levels of decomposition

4. Product Backlog
Technique : Story mapping

PERSONA
GOAL
ACTIVITY
FEATURE
4. Product Backlog
User Stories : Comparison with SAFe levels
Source : SAFe® Scaled Agile

4. Product Backlog
Estimations
Product Backlog
estimer les PBIs
estimation en Story points ou ideal days
pendant le refinement du Product Backlog
Sprint Backlog
estime la durée des tâches du Sprint Backlog
estimés en heures
pendant le Sprint Planning
4. Product Backlog
Concepts pour l'estimation des PBI

Estimer en équipe
Les estimations sont faites
les estimations sont faites par les personnes qui par l’équipe de
feront le travail développement
le rôle du Product Owner est de décrire le PBI et de

répondre à toutes les questions de la Development
Team
le Scrum Master doit aider et faciliter l'activité
d'estimation
4. Product Backlog
Concepts pour l'estimation des PBI

Les estimations ne sont pas des engagements
si les estimations étaient des engagements, la
Development Team ferait automatiquement des EXACT = au milieu de la cible
évaluations plus longues que la réalité pour se
prémunir des erreurs
Se focaliser sur l'exactitude, non sur la précision
trop de précision est une perte de temps
Utiliser les échelles relatives plutôt qu'absolues
les humains sont bien meilleurs dans des
évaluations relatives que dans l'absolu
4. Product Backlog
Unités pour l'estimation des PBI

MESURES RELATIVES PLUTOT QU’ABSOLUES
Story Points
Les Story Points mesurent la taille d'un PBI. l’absolu = engagement sur la durée
On s'attend à ce que les Story Points soient
influencés par des facteurs tels que la complexité et
la taille du PBI
Les story points ne sont pas une estimation de la D’ou les story points, estimation basée sur l’effort.
complexité mais bien de l’effort On prend une User story et on lui donne un certain
nombre de point, et on la prend comme référence
Ideal days
unité familière qui représente par exemple le trop proche de l’absolu, déconseillé
nombre de j.h nécessaire pour réaliser une User Story
Planning Poker
voir plus loin
4. Product Backlog

Planning Poker
technique basée sur le consensus pour estimer
l'effort
des experts sont rassemblés pour discuter de
l'évaluation des PBIs, des hypothèses d'évaluation
et partager une compréhension commune des PBIs
Le Planning Poker favorise une évaluation relative
des PBIs, en les regroupant par taille comparable
Échelle d'estimation : la plus fréquente est celle
préconisée par Mike Cohn, basée sur une suite de
Fibonacci: 1, 2, 3, 5, 8, 13, 20, 40, et 100.
4. Product Backlog

Planning Poker
infinite : Utilisé pour indiquer que le PBI est si
vaste qu'il n'y a aucun sens à mettre un nombre
dessus
« ? » : indique que le membre de l'équipe ne
comprends pas le PBI et demande au Product
Owner d'autres informations pour clarification
« π » : SVP, une pause !
4. Product Backlog

Règles du Planning Poker
1. Le Product Owner sélectionne les PBIs en haut
du Product Backlog et les lit à l'équipe
2. La Development team discute le PBI et demande
éventuellement des clarifications au Product
Owner
3. Chaque personne estime le PBI en choisissant
une carte du jeu
4. Product Backlog

Règles du Planning Poker
4. Chaque estimateur a effectué son estimation et
sélectionné sa carte : toutes les cartes sont
retournées en même temps
5. Si tout le monde a sélectionné la même carte, il
y a consensus sur l'estimation du PBI
6. Si les estimations sont différentes, l'équipe
s'engage dans des discutions pour clarifier les
hypothèses et les choix de chacun, pour clarifier les
incompréhensions
7. Après cette discussion ,on revient au point 3-
jusqu'à trouver un consensus
Questions
1. The Product Backlog is ordered by:

A) Size, where small items are at the top and large items are at the bottom.
B) Risk, where safer items are at the top, and riskier items are at the bottom
C) Least valuable items at the top to most valuable at the bottom.
D) Items are randomly arranged.
E) Whatever is deemed most appropriate by the Product Owner.
2. Which of the following practices might help the Product Owner minimize waste in developing
and sustaining the Product Backlog? (Choose 2 answers)
A) Let others manage the Product Backlog. Nobody else other than the PO manages the P.Bck
B) Only fully describe Product Backlog items when it seems sure that they are likely to be
implemented.
C) Write or cause Product Backlog items to be written clearly, and with as little ambiguity as
possible.
D) Always write the Product Backlog items as computer code that will later just be tested by
developers.
Questions
3. A Product Backlog is: (Choose 3 answers)

A) An inventory of things to be done for the Product.
B) Ordered based on priority, value, dependencies, and risk. it’s not an exhaustive list, as the backlog
C) An exhaustive list of upfront approved requirements to be implemented for the system. lives during the product dev so items can
D) Managed by the Product Owner. be added or removed or modified
E) Only visible to the Product Owner and stakeholders. to the scrum team not only the PO
4. When should the Product Backlog be refined? (Choose 2 answers)

A) The Product Owner and the Development Team do it in the 1-2 preceding Sprints. there is no time between sprint, the next one
B) The Product Owner takes the time between the Sprints to do it. starts at the end of the current sprint
Texte
C) The Product Owner must do this as essential work in Sprint 0.il n y’a pas de sprint 0 = false
D) The Product Owner and the Development Team do it in the actual Sprint if they haven't been
able to do it in preceding Sprints.
E) Business analysts in the organization should do this work for the Scrum Team 1-2 Sprints ahead
of the development Sprints.
5. Sprints
5. Sprints
Même durée (1 semaine à un mois)

Rien ne doit altérer la durée on ne change pas la durée du sprint —> fixée
qd un sprint se termine le suivant commence,

il n y’a pas de temps mort
Sprint 1 Sprint 2 Sprint 3 Sprint 4

5. Sprints
Sprints
le travail est réalisé dans des itérations, ou cycles,
d'une durée maximale préconisée de un mois
le travail réalisé dans chaque Sprint devrait créer
la valeur relative au client, pas que financière.
quelque chose d'une valeur tangible pour le client
les Sprints sont timeboxed, c'est-à-dire qu'ils ont si jamais on termine le travail dédié au sprint
avant la durée prédéfinie, on peut rajouter des
une durée fixe, et ils doivent avoir tous la même fonctionnalités pour le reste du temps, à voir
avec le PO.
durée
un nouveau Sprint suit immédiatement la
terminaison d'un Sprint précédent
sauf force majeure ‘pas d’avancement,
on admet comme règle de ne changer sous aucun meilleur façon de faire, plus de sens pour une
prétexte les objectifs de la Development Team en feature, etc’ , et tout le monde doit être
d’accord.
cours de Sprint
5. Sprints
Un Sprint est Timeboxed

limite le WIP grande itération = bcp de travail à réaliser, plus livraision
l’itération est courte on aura plus de feedback et plus de
force la priorisation
démontre la progression avec chaque livraison
évite le perfectionnisme on livre à la fin du sprint, pas besoin de rajouter quoique ce soit, délai à respecter
incite à la clôture et à la livraison
améliore la prédictibilité
5. Sprints
Un Sprint a une durée courte

facilite la planification
favorise des feedbacks rapides
circonscrit et limite les erreurs
améliore le ROI
permet des points de contrôle fréquents
5. Sprints
Tous les Sprints doivent avoir la même durée

la Scrum Team doit adopter une durée unique pour
tous les Sprints, et ne pas la changer à moins qu'il
n'y ait une raison réelle de le faire
le fait que la Development Team ne puisse réaliser
tout le travail prévu dans le Sprint n'est pas une
raison suffisante d'augmenter la durée du Sprint →
c'est en fait un symptôme du besoin d'amélioration
permet de réduire la surcharge liée à la
coordination
simplifie la planification
permet de mieux maîtriser l'évaluation de la vélocité : capacité à faire de l’équipe
mesurée en nombre de points
Vélocité
5. Sprints
Pas de modification des buts du Sprint

quand un Sprint a commencé, il ne peut PAS y avoir
de modification du travail mettant en danger le but
du Sprint (Sprint Goal)
c'est un engagement mutuel de la Development
Team et du Product Owner
trouver l'équilibre entre changement et clarification
être pragmatique : la « no goal-altering rule » n'est no goal-altering rule is rule not a law
pas une loi

terminaison anticipée du Sprint
La Development Team peut décider d'avertir le
Product Owner qu'il faudrait interrompre le Sprint
Le Product Owner prend la décision finale
Questions
1. When might a Sprint be abnormally terminated?

A) When it becomes clear that not everything will be finished by the end of the Sprint.
B) When the Development Team feels that the work is too hard.
C) When the sales department has an important new opportunity.
D) When the Sprint Goal becomes obsolete.
2. The length of a Sprint should be:

A) Short enough to keep the business risk acceptable to the Product Owner.
B) Short enough to be able to synchronize the development work with other business events.
C) No more than four weeks.
D) All of these answers are correct.
3. The purpose of a Sprint is to produce a done increment of working product.

A) True
B) False
6. Sprint Planning
6. Sprint Planning
Sprint goal
Product backlog
Sprint backlog
PBIs Tasks
Daily
Scrum
Sprint Planning
Refinement Sprint
Execution
Potentially
increment
6. Sprint Planning
Sprint Planning
au tout début d'un Sprint
le Product Owner and la Development Team se
mettent d'accord sur le Sprint Goal, l'objectif du
Sprint, c'est-à-dire ce qu'il est sensé livrer
la Scrum Team revoit le Product Backlog et détermine le PO fait l’ordonnancement, et
sélectionne avec la Dev team les
les PBIs prioritaires que la Development Team pourra PBIs à mettre sur le sprint
raisonnablement produire
le Sprint Planning est time-boxed à une durée
maximale de 8 heures
(un Sprint de 1 semaine donne lieu à un Sprint
Planning inférieur à 2h)
La development team peut inviter d’autres personnes
pour fournir des conseils techniques par exemple
6. Sprint Planning
Sprint Backlog
utilisé pour clarifier ce qui doit être réalisé
décompose chaque PBI sélectionné en un
ensemble de tâches
la Development Team va alors fournir des
estimations (typiquement, en heures) de l'effort
nécessaire pour réaliser les tâches
La plupart des Scrum Teams travaillant sur des
Sprints de deux semaines à un mois, terminent
leur Sprint Planning en moins de 8 heures
Un sprint de une semaine ne devrait pas
nécessiter un Sprint Planning de plus de 2 heures
(probablement moins)
6. Sprint Planning
Sprint Backlog
La principale caractéristique du Sprint Backlog est
de contenir des Tasks
PBIs Tasks
Tâche A Tâche B Tâche C

Heures : 2 Heures : 5 Heures : 12
Tâche D Tâche E
Heures : 9 Heures : 4
Tâche F Tâche G Tâche H

Heures : 2 Heures : 6 Heures : 5
6. Sprint Planning
Sprint Backlog
6. Sprint Planning
Estimation & Vélocité

“Combien de requirements peut-il être
développés ?”
“Quand aurons-nous terminé?”
“Combien cela va-t-il coûter?”
Pour répondre à ces questions, Scrum propose
d'estimer la taille de ce qui doit être réalisé, et de
mesurer la vélocité avec laquelle le travail peut
être réalisé
avec cette information, on peut en déduire la
durée de développement (et le coût
correspondant), en divisant la taille estimée du
travail par la vélocité de l'équipe
6. Sprint Planning
Qu'est-ce que la Vélocité ?

c'est la « quantité » de travail réalisé dans chaque
Sprint
elle est obtenue en ajoutant la taille des PBIs qui
ont été réalisés pendant le Sprint
le Product Owner ne reçoit aucune valeur des PBIs
non réalisés ou finalisés, donc ils ne sont pas
comptés dans la vélocité
la vélocité mesure la taille des PBIs délivrés, pas la
valeur associée
6. Sprint Planning
Vélocité
Questions
1. The time-box for the Sprint Planning meeting is?

A) 4 hours.
B) 8 hours for a monthly Sprint. For shorter Sprints it is usually shorter.
C) Whenever it is done.
D) Monthly.
2. When do a Development Team member become the exclusive owner of a Sprint Backlog
item?
A) At the Sprint planning meeting.
B) Never. All Sprint Backlog Items are "owned" by the entire Development Team, even
though each one may be done by an individual development team member.
C) Whenever a team member can accommodate more work.
D) During the Daily Scrum.
3. Which two (2) things does the Development Team do during the first Sprint?
A) Deliver an increment of releasable software.
B) Determine the complete architecture and infrastructure for the product.
C) Develop and deliver at least one piece of functionality.
D) Develop a plan for the rest of the release.
E) Create the complete Product Backlog to be developed in subsequent Sprints.
Questions
4. How much work must a Development Team do to a Product Backlog item it selects for a
Sprint?
A) As much as it has told the Product Owner will be done for every Product Backlog item
it selects in conformance with the definition of done.
B) As much as it can fit into the Sprint.
C) All development work and at least some testing.
D) Analysis, design, programming, testing and documentation.
7. Sprint Execution
7. Sprint Execution
Sprint goal
Product backlog
Sprint backlog
PBIs Tasks
Daily
Scrum
Sprint Planning
Refinement Sprint
Execution
Potentially
increment
7. Sprint Execution
Personne ne dit à la Development Team dans quel

ordre, ou comment elle doit réaliser les tâches du l’engagement de l’équipe de Dev est sur les
Sprint Backlog
fonctionnalités, c’est elle qui gère les taches
qui sont sur le sprint backlog
les Team Members définissent leur propre travail

au niveau de la tâche du Sprint Backlog, et
s'organisent de la meilleure manière pour atteindre
les objectifs
7. Sprint Execution
Daily Scrum
Chaque jour du Sprint, idéalement à la même
heure, la Development Team a un Daily Scrum
timeboxed (15 minutes ou moins)
c'est un daily stand-up, car cela favorise la brièveté
de Daily Scrum
3 questions sont posées par chaque Team Member
qu'est-ce que j'ai accompli hier qui ait aidé la
development team à atteindre le Sprint Goal?
Que dois-je faire aujourd’hui pour aider la
Development Team à atteindre le Sprint Goal ?
Est-ce que je vois des difficultés ou obstacles qui
empêcheraient la Development Team d’atteindre le
Sprint Goal ?
7. Sprint Execution
Daily Scrum
ce n'est pas une réunion vouée à la résolution de
problèmes
beaucoup d'équipes parlent des problèmes après
leur Daily Scrum, et le font en petits groupes
d'intéressés
ce n'est pas une revue de statut du projet
peut être très utile pour communiquer le statut
des PBI en cours de développement aux autres
membres de la Development Team
Si d’autres personnes que la Scrum Team sont
présentes, le Scrum Master s’assurent qu’elles ne
perturbent pas le Daily Scrum
7. Sprint Execution
Technique : Information/Scrum Radiator

7. Sprint Execution
Information Radiator
7. Sprint Execution
Information Radiator
7. Sprint Execution
7. Sprint Execution
Sprint Burndown Chart

Chaque jour pendant la Sprint Execution, la Sprint Burndown : ce fait sur les taches du sprint,
Development Team évalue l'effort qui reste à pour savoir la quantité de travail restante pour
accomplir une tache X.
fournir pour chaque tâche non complétée
Quantité en HEURE
Nb d'heures estimées restantes
Jours dans le Sprint

7. Sprint Execution
Quantité de travail restante pour chaque sprint, sur les PBIs du backlog en POINTS ( anciens en haut et nouveaux en bas)
Release Burndown Chart

●
On this burndown chart, the height of
each bar represents the amount of work
shows the net change in the amount of remaining in the release.
work remaining ●
The team finished 25 points in sprint 1,
leaving 150 to go as of the start of sprint 2.
There were 120 as of the start of sprint 3.
So, the top of the bar is reduced by the
amount of work the team finishes in a
given sprint.
●
Before the start of sprint 4, the Product
Owner added work to the project. This
additional work is shown at the bottom of
the bar for the fourth sprint. You can see
that the vertical height of sprint 4 goes
from about -40 to about 95, or 135 points
of work remaining. Fourty of those 135
points are from new work.
7. Sprint Execution
Definition du « Done »
Sprint goal
Product backlog
Sprint backlog
PBIs Tasks
Daily
Scrum
Sprint Planning
Refinement Sprint
Execution
Potentially
increment
7. Sprint Execution
Acceptation d’une User Story : Acceptance Criteria

Le Product Owner définit les critères
d’acceptation (au dos de la User Story) :
Acceptance Criteria
Exemple
Product Owner
– User Story : « En tant que client final je souhaite
payer par Carte Bancaire »
– Acceptance criteria : « Le paiement fonctionne
avec Visa, Amex, MC »
La fonctionnalité réalisée est souvent appelée
« Accepted »
7. Sprint Execution
Definition de « Done »
une checklist des différentes tâches que la
Development Team est sensée réaliser pour
déclarer que le travail peut être « potentially
shippable »
c’est une check list de critères qualité, qui
reprends l’ensemble des conditions selon
lesquelles une User Story est considérée comme
« Faite »
7. Sprint Execution
Exemple de Definition of Done
Acceptance criteria
From Product Owner
7. Sprint Execution
Si plusieurs Scrum Teams travaillent ensemble sur
un même produit, chacune d’elles doit adhérer à
une définition commune du « Done » au
minimum
Au fur et à meure qu les équipes montent en
maturité, elles peuvent enrichir leur définition du
« Done » en incluant des critères de plus en plus
exigeants
C’est la Development Team qui est responsable
de la définition du Done car elle est responsable
de la qualité de ses livrables
Cette définition doit être comprise par le PO
Questions
1. Who is required to attend the Daily Scrum?

A) The Development Team. Seule l’équipe de développement doit assister Obligatoirement au DAILY SCRUM,
B) The Scrum team. il se peut que d’autre personnes y participent.
C) The Development Team and Scrum Master.
D) The Development Team and Product Owner.
E) The Scrum Master and Product Owner.
2. During the Daily Scrum, the Scrum Master's role is to:

A) Lead the discussions of the Development Team.
B) Make sure that all 3 questions have been answered.
C) Manage the meeting in a way that each team member has a chance to speak.
D) Teach the Development Team to keep the Daily Scrum within the 15 minute time-box.
E) All answers apply.
Enseigner à l’équipe de développement comment respecter le Daily scrum, les membres
de l’équipe doivent avoir déjà préparer les réponses aux trois questions, et ne parleront
que des obstacles qui pourront empêcher l’avancement de leur travail.
Questions
3. What is the main reason for the Scrum Master to be at the Daily Scrum?
A) To make sure every team member answers the three questions. Cette question ne se pose pas, car il n y’a
pas besoin de participer au Daily Scrum
B) He or she does not have to be there; he or she only has to ensure the
Development Team has a Daily Scrum.
C) To write down any changes to the Sprint Backlog, including adding new items,
and tracking progress on the burn-down.
D) To gather status and progress information to report to management.
4. Why is the Daily Scrum held at the same time and same place?
A) The place can be named.
B) The consistency reduces complexity.
C) The Product Owner demands it.
D) Rooms are hard to book and this lets it be booked in advance.
5. The time-box for a Daily Scrum is?

A) The same time of day every day.
B) Two minutes per person.
C) 4 hours.
D) 15 minutes.
8. Sprint Review
8. Sprint Review
A la fin de chaque Sprint Plus il y’a de mondes, plus la revue va être riche.
C’est le PO qui invitent les personnes à assister à

C'est une conversation qui a lieu entre les la revue.
participants de la Scrum Team, les parties prenantes

concernées, les sponsors, les clients et les membres
intéressés d'autres équipes invitées par le Product
Owner
Objectifs : inspecter & adapter le produit
La sprint review est time-boxed à 4h pour un sprint
de 1 mois
8. Sprint Review
fournit une vue transparente de l'état courant du

produit
c'est le moment de poser des questions, de faire
des observations ou des suggestions, et d'avoir des
discutions sur la meilleure façon d'atteindre le Sprint
Goal
Questions
1. Which topics should be discussed in the Sprint Review ?

A) The Scrum process and how it was used during the Sprint
B) Sprint results
C) Coding and engineering practices
D) All of the above
2. What is the time-box for the Sprint Review?

A) 2 hours for a monthly Sprint
B) 4 hours for a monthly Sprint
C) As long as needed
D) 1 day
E) 4 hours and longer as needed
9. Sprint
Retrospective
9. Sprint Retrospective
a lieu fréquemment après la Sprint Review et

avant le Sprint suivant
c'est l'opportunité d'inspecter le processus Scrum
de l'entreprise
la focalisation est sur l'amélioration continue du
processus Scrum pour qu'il soit toujours plus
performant
Time-box : 3h pour un sprint de 1 mois
Revoir par exemple la définition du « Done »
Questions
1. When is it most appropriate for a Development Team to change the definition of « Done » ?
A) During the Sprint Retrospective
B) Prior to starting a new Sprint
C) During Sprint Planing
D) Prior to starting a new project
2. During a Sprint Retrospective, for what is the Scrum Master responsible ?

A) Participating as a Scrum Team member and facilitating as requested or needed
B) Summarizing and reporting the discussions to management
C) Acting as a scribe to capture the Development Team’s answers
D) Prioritizing the resulting action items
3. Which are NOT appropriate topics for discussion in a Sprint Retrospective

A) The value of work currently represented in the Product Backlog
B) Definition of « Done »
C) Team relations méthodologie uniquement
D) Sprint Backlog for the next Sprint
E) How the team does its work
4. The Product Owner makes sure the right stakeholders are invited to the Sprint Retrospective. They
might have important instructions for team improvements.
A) True
En retrospective il n y’a pas de partie prenantes -> uniquement en Review quand on parle du produit.
B) False Seule l’équipe Scrum assiste à la sprint retrospective.
10. Autres
outils/techniques
10. Autres outils/techniques
La Dette technique (Technical Debt) vient :

d'une conception inadaptée
des défauts
de tests insuffisants
d'une intégration faible ou d'une gestion des
déploiements non maîtrisée
Un code complexe
et tellement d'autres choses...
Les problèmes surgissent lorsque la Technical Debt
n'est pas prise en compte Report de fonctionnalités / baisse de la vélocité à cause
des corrections de bug et du fait qu’on devrait livré des
fonctionnalités qui aurait du etre finies pendant le sprint
d’avant
Consequences de la Technical Debt

Point de basculement imprévisible
Augmenter le temps de livraison
Nombre significatif de défauts
Hausse des coûts de développement et de
support
Diminuer la prévisibilité
Sous performance
Frustration
Diminution de la satisfaction client
Effet de la dette technique
Vélocité actuelle
donnant des produits
de bonne qualité
Quantité de travail
Vélocité
projetée
Date Date
souhaitée probable
de MEP de MEP
LA mauvaise réponse à la dette technique

Diminuer les tests pour augmenter la vélocité
moins de tests augmente la dette et diminue la
vitesse
les problèmes sont détectés plus tard et
nécessiteront plus de travail pour y remédier
Bonne pratique : Test-Driven Development
TDD est une technique où le développeur écrit et
automatise un test unitaire avant d'écrire le
morceau de code qui fera passer le test (Crispin
and Gregory 2009).
La dette techique doit être gérée

Tous les produits ont une dette technique
Suggestions
Gérer l'accumulation de dette technique
comme emprunter de l'argent pour payer la dette
Rajouter le sprint déjà prévu de l’US concernée afin de ne pas la
Rendre la dette technique visible laisser trainer. sinon on arrivera pas à la résorber
Insertion d'éléments de dette technique dans le Product
Backlog
Remboursement de la dette technique
Rembourser la dette technique à intérêt élevé en premier
rembourser la dette technique tout en effectuant un
travail précieux pour le client
toutes les dettes techniques ne doivent pas être
remboursées
Dette technique
Fonctionnalité A
Fonctionnalité B
Fonctionnalité C Technical debt
Défaut 121
Fonctionnalité D
Refonte Y1
Fonctionnalité E
Fonctionnalité F
Release Planning
making scope, date, and budget trade-offs for
incremental deliveries.
Release Planning
10 % of total development effort
Minimum
Releasable
Features
Release Planning
Quand le Release Planning est-il effectué ?
Release Planning
La séquence correcte de lancement du sprint est
donc :
Release Planning
Sprint planning
Sprint execution
Daily Scrum
Sprint Review
Questions
1. If burndowns charts are used to visualize progress, what does a trend line through a
release burndown chart indicate?
a. the evolution of the cost spent of the project
b. when the project will be over if the Product Owner removes work that is equal in
effort to any new work that is added
c. when all work will be completed so the Scrum Team can be released for other work
d. when the work remaining will likely be completed if nothing changes on the
Product Backlog or the Development Team
2. Sprint burndown charts are an efficient tracking tool because they show:
a. how many hours have been worked by each Development Team member
b. how many Product Backlog items remain
c. how much effort has gone into a Sprint
d. estimated work remaining for the Sprint
3. What is the Release Burndown Chart?

a. a graph indicating what has been completed by the Scrum Team
b. what has been completed by the Scrum Team to date
c. the work remaining to be completed by the Product Owner
d. a measure of the remaining Product Backlog across the time of a release plan
11. Scaling SCRUM
11. Scaling SCRUM
Un produit & multiple component teams

11. Scaling SCRUM
Deux produits & de multiples component teams

11. Scaling SCRUM
Deux produits & de multiples component teams

SCRUM-of-SCRUMs
A technique to scale Scrum up to large groups
(over a dozen people), consisting of dividing the
groups into Agile teams of 5-10.
Each daily scrum within a sub-team ends by
designating one member as "ambassador" to
participate in a daily meeting with ambassadors
from other teams, called the Scrum of Scrums
les dailys scrum n’auront pas lieu en meme temps, donc il y’aura plusieurs daily scrum
partage d’info lourd —> 15 mins ?
11. Scaling SCRUM
Scaled Agile Framework (SAFe®)

4 niveaux d’agilité
Équipes
Programme
Value Stream
Portfolio
Questions
1. When multiple teams work together on the same product, each team should maintain a
separate Product Backlog.
A) True
B) False
2. Multiple Scrum Teams working on the same product or system all select work from the
same Product Backlog.
A) True
B) False
3. Multiple Scrum Teams working on the same project must have the same Sprint start
date.
A) True
il n y’a pas de raison, on doit pouvoir synchroniser, et mettre en production après avoir intégrer les différents travaux
B) False
4. A Product Owner with multiple teams working on one product should maintain
separate Product Backlogs for each team.
A) True
B) False
BRAVO !

Untitled

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Untitled

Transféré par

Droits d'auteur :

Formats disponibles

Bootcamp Certification Scrum Master (PSM I) & Product Owner (PSPO) © Skills4All.

Connaître la méthode Scrum du point de vue du

Ce support est basé sur le SCRUM Guide révision

Avertissement sur le support de cours

1. Introduction aux méthodes agiles

Agile in the world (9th Annual State of Agile

Caractéristiques d'une méthode de gestion de

Principle of Waterfall vs Agile

Source : SAFe Scaled Agile Framework

Courbe d'acceptation de Kübler-Ross

Proposition de valeur des méthodes agiles

Agile in the world (9th Annual State of Agile

XP (Extreme Programming) : Méthode agile axée

Lean Software Development

SCRUM : Un cadre dans lequel les personnes peuvent

Evaluation de la maturité agile : Agilometer

Source : PRINCE2 Agile ©AXELOS

Les rôles dans les méthodes agiles

Autres principes Agiles

Autres principes Agiles

Autres principes agiles

Autres principes agiles

Autres principes agiles

Autres principes agiles

Autres principes agiles

Scrum est un framework pour organiser et gérer le

1. What does it mean to say that an event has a time-box?

2. It is mandatory that the product increment be released to production at the end

4. The three pillars of empirical process control are:

5. Which statement best describes Scrum?

Le Product Owner est le point central de décision

Geoffrey Moore’s « Elevator Pitch »

Le Product Owner est la seule personne responsable

Prends les décisions par rapport aux Releases

Lead Facilitator of key Stakeholder Involvment

Le PO est un membre actif et collaboratif de la

Product Backlog Management Leader

Qui est le Product Owner ?

Erreurs courantes à propos du PO

Qui est le Product Owner ?

Hiérarchies de Product Owners

La journée d'un Product Owner

Le Scrum Master aide le Product Owner de

1. Scrum does not have a role called "project manager."

5. Which statement best describes a Product Owner's responsibility?

6. What is the role of Management in Scrum?

Liste priorisée des fonctionnalités du produit

avec Scrum, on développe toujours en premier le

Les PBIs en haut de Product Backlog sont détaillés

Fonctionnalité A Priorité haute

Fonctionnalité F Priorité basse

Product Backlog Refinement (grooming)

l’estimation en temps apparaitra dans le sprint backlog

Estimation en point au lieu de temps, ex : une

Estimer la taille des Product Backlog Items (PBI)

Product Backlog Items (PBI)

Caractéristiques d'un bon Product Backlog

Caractéristiques d'un bon Product Backlog

Caractéristiques d'un bon Product Backlog

Caractéristiques d'un bon Product Backlog

Caractéristiques d'un bon Product Backlog

Product Backlog & refinement responsabilité du PO PBI Taille

effort collaboratif dirigé par le Product

parties prenantes, de même que le Scrum