Le document fournit un guide détaillé sur le framework Scrum, ses principes fondamentaux, et la manière dont il est structuré, incluant ses rôles, événements, et artéfacts. Il met également en avant l'importance de la transparence, de l'inspection, et de l'adaptation dans le développement de produits complexes. Enfin, il explique les responsabilités des différents acteurs, notamment du Product Owner, de l'équipe de développement, et du Scrum Master, ainsi que les concepts d'auto-organisation et d'annulation de sprint.

1. Basé sur le Scrum Guide,
seule référence du PSM
Préparation PSM 1
« Professional Scrum Master »
Guillaume LAURIE - 2020
Les images ne sont pas soumises aux mêmes droits

2. Scrum
Théorie, piliers, valeurs

3. Définition
Ce que Scrum est :
• Scrum est un framework processé
permettant de développer des produits
complexes
• Scrum est léger, simple à comprendre,
difficile à maîtriser
Ce que Scrum n’est pas :
• Scrum n’est pas une méthode, un
process ou un outil
• Scrum n’est pas une boîte à outils ou
un livre de recettes

4. Mais encore ?
• Scrum est composé de :
• Evénements
• Artéfacts
• Rôles
• Règles (qui décrivent les
interactions entre chacun)
• Scrum est basé sur :
• Empirical process control theory
(méthode empirique – par
l’expérience)
• L’itération, l’approche incrémentale
et l’optimisation, le contrôle du
risque

5. Utilisations de Scrum
• Research and identify viable
markets, technologies, and product
capabilities;
• Develop products and
enhancements;
• Release products and
enhancements, as frequently as
many times per day;
• Develop and sustain Cloud (online,
secure, on-demand) and other
operational environments for
product use; and,
• Sustain and renew products.

6. Piliers de
Scrum
Transparence
• Le travail et les
résultats doivent
être visibles par
l’ensemble de
l’équipe Scrum
• L’équipe Scrum
partage un langage
commun et des
standards
• L’équipe Scrum
partage la même
« definition of
done »
Inspection
• L’équipe Scrum
doit régulièrement
inspecter afin de
détecter des
variations entre
l’attendu et le
réaliser pour
détecter les
variances
• Les inspections
doivent être
fréquentes sans
pour autant gêner
le travail et
l’atteinte du goal
Adaptation
• L’équipe Scrum
peut décider à tout
moment de
s’adapter si elle
découvre qu’elle
dévie et qu’elle se
dirige vers un
produit
« inacceptable ».
L’adaptation doit
se faire as soon as
possible sans pour
autant mettre en
danger le sprint
goal

7. Valeurs de Scrum
Commitment (engagement):
les équipes s’engagent sur
le résultat
Courage : relève les
challenges et traitent les
problèmes
Focus : Reste focus sur
la destination, le sprint
goal
Openness (ouverture) :
rester ouvert aux
changements
Respect : le respect
est la base de la
confiance

8. Definition of Done (DoD)
Un PBI ou un incrément sont considérés comme « fini » (done)
lorsqu’ils répondent à la « definition of done ».
La definition of done peut donc varier beaucoup d’une équipe scrum à
une autre. Le DoD permet de s’assurer que l’incrément est
potentiellement releasable
Le DoD peut faire partie des conventions, normes ou directives de
développement – dans ce cas, elle sera respectée par toutes les
équipes Scrum, sinon elles devront créer une DoD commune

9. Scrum
Evénements

10. ATTENTION : Le SPRINT n’est pas un événement, il faut le considérer comme un container qui contient des événements,
lorsqu’on sort d’un sprint, on entre dans un autre sprint.
Source image : mailjet.com
Les événements – le concept d’itération

11. Sprint planning :
Max : 8h / 1 mois
Equipe Scrum
Input : Product Backlog +
Increment
Output : Sprint Goal + Sprint
Backlog + plan to deliver
(first days detailed)
Sprint retrospective :
Max : 3h / 1 mois
Equipe Scrum
Input : ce qui s’est bien / mal passé
Output : 1 high priority improvement for the
process
Sprint review :
Max : 4h / 1 mois
Equipe Scrum / Key stakeholders
Input : Livraison incrément
Output : De nouvelles tâches proposées par Key
Stakeholders
Daily Scrum :
Max : 15 min
Equipe Dev
Output : Point sur ce qui a été
fait et ce qui sera fait +
problème
Refinement (non événement) :
Max : 10% du temps du sprint
Equipe Dev / PO
Input : nouvelles tâches
Output : maj backlog avec
nouvelles tâches
ATTENTION : Le SPRINT n’est pas un événement, il faut le considérer comme un container qui contient des événements.

12. Sprint planning :
Time-box : 8h / si sprint 1 mois
Qui : Equipe Scrum
Input : Product Backlog + Increment
Output : Sprint Goal + Sprint Backlog + plan to deliver (first days
detailed)
Le PO peut aider à clarifier les items.
By the end of the Sprint Planning, the Development Team should be
able to explain to the Product Owner and Scrum Master how it intends
to work as a self-organizing team to accomplish the Sprint Goal and
create the anticipated Increment.
Sprint goal ?
Qui le créé : Equipe dev
C’est la raison d’être du sprint, la cohérence, il
ne doit pas changer une fois le sprint démarré.
It provides guidance to the Development Team
on why it is building the Increment. It is created
during the Sprint Planning meeting.

13. Daily Scrum :
Timebox : 15 min
Qui : Equipe Dev
Pas forcément debout mais recommandé !
L’essentiel : court et bien structuré (et focus sur le sprint goal).
3 questions que l’on trouve dans le scrum guide :
Qu’as-tu fait hier ?
Que fais-tu aujourd’hui ?
Est-ce que tu as rencontré des problèmes qui pourraient empêcher la
livraison ?
Le Scrum master s’assure que la réunion ait lieu (c’est sa responsabilité
en tant que garant du framework).
But : éliminer les autres réunions, améliorer la communication,
identifier les problèmes (impediments), facilite une prise de décision
rapide…

14. Sprint review :
Max : 4h / si sprint 1 mois
Qui : Equipe Scrum / Key stakeholders
Input : Livraison incrément – un incrément correspond au
précédent incrément + les tâches répondant à la « définition of
done » terminées pendant le sprint
Pendant : L’occasion de collaborer sur le done réalisé pendant le
sprint et écouter les nouvelles demandes des key stakeholders
Output : Un backlog mis à jour et réordonné ! (De nouvelles tâches
proposées par Key Stakeholders au PO)
Attention, il s’agit d’un meeting informel !
Le PO peut inviter des stakeholders
But : enregistrer l’avancement de l’incrément et prendre de
nouvelles idées

15. Sprint retrospective :
Max : 3h / 1 mois
Qui : Equipe Scrum
Pendant : ce qui s’est bien / mal passé
Output : 1 high priority improvement for the
process
But : inspection du fonctionnement de l’équipe
et créer un plan pour améliorer le
fonctionnement pour le prochain sprint
Même si les improvements peuvent être faits
tout le temps, il s’agit d’un temps formel
permettant d’inspecter et s’adapter

16. Product Backlog Refinement (attention, ce n’est pas un événement):
Max : 10% du temps du sprint
Qui : Equipe Dev / Po
Pendant : Ajouter des détails aux PBI (product backlog items), estimer
les tâches et ordonner le PB (product backlog)
Output : maj backlog avec nouvelles tâches

17. Scrum
Artéfacts

18. Product Backlog :
• Responsable : Product Owner
• Utilisation : Alimente le Sprint Planning
• Doit être visible (accessible par l’équipe scrum) et
ordonné (pour refleter les priorités du PO)
• Liste toutes les fonctionnalités à developer, leurs
pré-requis, ameliorations et corrections
• Devient plus fourni au fur et à mesure que le
produit avance
• Plus un item est haut dans le Product Backlog et
plus il est affiné / clair et leur estimation (à la
charge de l’équipe dev) est plus precise
• Rempli par le Product Owner ou à la discretion
du Product Owner
Le product backlog est dynamique, en changement
constant – Tant qu’un produit existe, son product
backlog existe
1 seul Product Backlog par projet (même si de
nombreuses équipes Dev)

19. Sprint Backlog :
• Responsable : Dev Team
• Créé lors : du Sprint planning, alimenté en
utilisant les PBI (+ le plan)
• Représente : Le travail à réaliser par l’équipe dév
pour atteindre le sprint goal (défini lors du sprint
planning)
• Est une prévision de ce que sera le prochain
incrément
• Doit être suffisamment clair pour permettre aux
équipe de developer les fonctionnalités
• Le Sprint backlog est modifié au cours du sprint
• L’équipe dev maintient à jour le monitoring du
travail restant (souvent au travers du burn-down
chart)
Seul l’équipe de dev peut modifier son contenu !
Chaque daily scrum, on fait le point sur le volume
de travail restant, on alerte le PO si on n’atteindra
pas le sprint goal
1 sprint goal par équipe scrum

20. Incrément :
• Responsable : Product Owner
• Créé lors : En ajoutant l’increment précédant + le
travail fournit dans le dernier sprint
• Représente : Le logiciel qui fonctionne
partiellement releasable
• Doit être utilisable selon les conditions du
Definition of Done
Seul le PO peut decider de le releaser !
Toutes les équipes Scrum travaille sur le même
Incrément

21. Transparence des artéfacts :
• Pilier de la démarche empirique, les increments
doivent être transparents
• Des artéfacts non transparents ne permettent pas
d’optimiser la valeur business ni la productivité et font
augmenter les risques
• Le Scrum Master doit travailler avec le PO et l’équipe
pour s’assurer de la transparence des artéfacts
• Cela passe par l’inspection mais également par la
sensibilisation et l’accompagnement au changement
Source image : 4tempsdumanagement.com

22. Scrum
Les rôles

23. Source image : Œil de coach
IMPORTANT :
Notez l’absence du “project manager” qui n’existe
pas dans SCRUM et n’est pas remplacé !

24. Le Product Owner :
augmenter la valeur
• S’assure de créer des PBI clairs (product backlog
items) et compris par l’équipe de dev
• Ordonner le Product Backlog (selon l’ordre qui lui
semble le plus adapté)
• Optimiser la valeur de ce qui est produit par l’équipe
dev
• S’assurer que le Product Backlog est visible, clair et
transparent et montre sur quoi porteront les
prochains sprint
• Est en charge du monitoring des progrès vers
l’objectif en mesurant le travail accompli et restant
Responsable : product backlog
1 seul Product Owner par Produit
1 seul Product Backlog par Produit

25. L’équipe de dev :
Produire un incrément
• S’auto organisent pour arriver à un increment à partir du
product backlog (créé leur équipe par exemple) et n’ont pas
besoin de quelqu’un qui leur dit quoi faire (comme le
scrum master)
• Cross functionnal, ils ont les compétences requises pour
produire l’incrément et ne dépendent pas d’individus
externes
• Pas de titres, pas de divisions par spécialité, l’équipe est
responsable de tout pas les individus
Responsable : sprint backlog + plan / daily scrum
Taille : 3 à 9
Product Owner et Scrum Master peuvent faire partie de
l’équipe de dev mais ce n’est pas une bonne pratique

26. Le Scrum Master :
Garant du framework
• Servent-Leader, le Scrum Master N’EST PAS un
manager ! Il ne donne aucun ordre, ne décide
rien
• S’assure que chacun dans l’équipe scrum
comprend les rôles, les événements, les
artéfacts, les règles
• S’assure que chacun dans l’équipe scrum
comprend la théorie, les pratiques et les valeurs
• Aide ceux qui sont à l’extérieur de l’équipe scrum
à communiquer avec l’équipe scrum (afin
d’améliorer les intéractions)
Responsable : Bonne application du framework et
chacun comprend son rôle

27. Le Scrum Master :
Au service du Product Owner
• S’assure que chacun comprend ce qui est attendu
(but, périmètre, domaine…)
• Trouve des techniques de management du Product
Backlog (mais ne les impose pas)
• Aide l’équipe scrum à comprendre l’importance de PBI
clairs et concis
• Aide à comprendre la planification dans un process
empirique (basé sur l’expérience)
• S’assure que le PO comprend comment organiser son
product backlog pour produire le maximum de valeur
• Facilite les événements Scrum si demandé ou si
besoin
Responsable : S’assurer que le PO (product owner) a
bien compris ses responsabilités (notamment le fait qu’il
pilote le projet au travers du backlog)

28. Le Scrum Master :
Au service de l’équipe dev
• Coach l’équipe pour leur permettre de s’auto-organiser
et être cross functionnal (non spécialisés)
• Les aide à créer des incréments à forte valeur ajoutée
• Enlève les obstacles (impediments) qui pourraient se
placer sur le chemin et empêcher l’atteinte du sprint
goal
• Facilite les événements Scrum si demandé ou si besoin
• Coach l’équipe de dév dans un environnement dans
lequel Scrum n’est pas encore compris ni adopté
Responsable : S’assurer que l’équipe de dév a bien
compris ses responsabilités (notamment le fait de
produire un incrément et atteindre le sprint goal)

29. Le Scrum Master :
Au service de l’organisation
• Aide l’organisation dans son adoption de Scrum
(leading et coaching)
• Planifie l’implementation de scrum dans l’organisation
• Aide les employés et parties prenantes à comprendre
et mettre en place scrum et le process empirique de
développement de produit
• Créer les changements qui permette d’améliorer la
productivité de l’équipe scrum
• Travailler avec les autres scrum masters pour
améliorer l’efficacité de l’application de scrum dans
l’organisation.
Responsable : du bon déploiement de Scrum dans
l’organisation

30. Scrum
Points d’attention

31. NFR : Non Functionnal
Requirements
Les NFR sont des exigences qui ne sont pas
des fonctionnalités. Il peut s’agir de sécurité
ou de performances par exemple.
On les traite à 3 endroits :
• DoD : si ce sont des standards nécessaires à
toutes les fonctionnalités
• Backlog Produit : si représente une
fonctionnalité
• Intégrées aux critères d’acceptation des PBII

32. Concept d’auto-organisation
Le concept d’auto-
organisation de l’équipe de
dév est au cœur de Scrum.
L’équipe n’a pas de chef et n’a
pas besoin de l’aide d’une
personne extérieure pour lui
dicter sa conduite
L’équipe s’organise seule pour
atteindre ses objectifs et doit
s’assurer son côté cross-
functionnal
Donc les équipes ne doivent
pas être spécialisées (tests
par exemple) mais capables
de gérer l’atteinte du sprint
goal
Les développeurs doivent être
considérés comme un
ensemble d’experts capables
de se répartir en équipes sans
aide extérieur du moment
qu’on leur explique
l’importance d’équipes
pluridisciplinaires et le projet
à réaliser

33. Annulation de Sprint
Un sprint peut être annulé si son sprint goal est
devenu obsolète (très rare car un sprint dure
maximum un mois)
Seul le PO peut annuler un Sprint (même s’il le fait
à la demande des stakeholders, de l’équipe ou du
Scrum Master)
Les PBI qui ont atteint le « Done » (voir DoD)
peuvent être review, le PO peut ainsi les accepter si
releasable.
Tous les PBI non terminés sont réestimés et
retournent dans le Product Backlog.
L’annulation de sprint est perturbant pour l’équipe
et très rares

34. Alors prêt pour
la certification ?
Pensez à vous entraîner sur Scrum.org,
30 questions disponibles, pas toujours
les mêmes (permet d’avoir une partie
des questions du tests)
https://www.scrum.org/open-
assessments/scrum-open
Entraînez-vous en utilisant également le
test de Mikhail Lapshin
https://mlapshin.com/index.php/scrum-
quizzes/
Guillaume LAURIE - 2020
Les images ne sont pas soumises aux mêmes droits