Guide mémo pour réussir ses

certifications Scrum Master et

Product Owner (PSM1 et PSPO1)
Pour réussir ces certifications, il vous faut bien comprendre les points
suivants :

• La définition de Scrum : ce qu’est Scrum et aussi ce que Scrum n’est pas.

Ce que Scrum conseille, pense et interdit
• Les différents rôles dans Scrum : PO, SM, DT et Management
• Les artefacts obligatoires et facultatifs
• Les events / rituels de Scrum, leurs time box et leurs acteurs
• La Scalabilité dans Scrum

Déroulement de l’examen :

• Vous pouvez passer l’examen de chez vous avec une connexion internet
• Il est sous forme d’un QCM de 80 questions en 1 heure
• 85% de bonnes réponses sont nécessaires (12 erreurs maxi)
• Une astuce, pour certaines questions quand vous avez un doute sur la
bonne réponse, essayer de procéder à l’envers et d’éliminer les mauvaises
réponses
SCRUM est :

• Un framework (ce n’est pas une méthodologie, un livre de cuisine… ou d’autres

réponses de ce type que l’on retrouve souvent pendant l’examen)

• Utilisé pour gérer des projets complexes dans un environnement complexe

• Basé sur une approche (process) empirique

• Prévu pour des projets de logiciels que l’on va livrer de manière Itérative (Sprint)
et Incrémentale

Un incrément de logiciel constitué sprint après sprint et que l’on mettra en

production quand cela fera sens pour le Product Owner
Se rapproche de la notion de Release mais il n’y a pas de Release dans Scrum
SCRUM conseille :

• Le recourt à une équipe pluri-fonctionnelle composée de « généralistes éclairés » (profil

de compétence en T) et qui travaille à un rythme soutenable (sustainable pace)

• L’utilisation d’équipe fonctionnelle (qui peut intervenir sur toutes les couches de
l’application (en opposition avec les équipes dites « components »)

• L’équipe de développement est en charge du travail jusqu’à la mise en production.

• Que tous les membres de la Dev Team soient nommés des Développeurs, même ceux qui
ne développent pas

• De s’améliorer constamment et pas seulement lors des rituels prévus par le framework

• De mettre à jour les artefacts et leurs informations dès que nécessaire et pas
seulement lors des rituels prévus par le framework
SCRUM pense que :
• La qualité / maturité / succès d’une équipe ne se mesure pas :

Ø Au fait qu’elle ait des Releases Sprint (pas de release dans Scrum), mais par
contre qu’elle ait des Sprint released (shipped) en production
Ø Si le Done est non tenu et/ou inconsistant - alors on y perd en transparence
(vélocité,…), en qualité (risque de bug), et les projections du Product Owner
ne sont plus valables

• Il faut : s’engager, vouloir, pouvoir les faire Done en toute transparence (réponse
souvent proposée et à choisir pendant les tests)
• La Definition of Done permet la transparence

• L’incrément ne mérite son nom que s’il contient de réelle nouveauté par rapport à
la version précédente (pas de correction de bug ou de refonte de fonctions déjà
livrées)
SCRUM interdit :
• Toute « perte de temps » :

Ø PAS de Sprint 0 (préparation) ou Sprint H ou de Hardening (intégration

avant release)
Ø PAS de Sprint dédié à l’architecture / l’infrastructure ou à la QA
Ø PAS de Pause, entre chaque sprint

• Tout ce qui n’est pas dans Scrum comme :

Ø Les rôles types : Project Manager, Tester, Business Analyst,…

Ø Les rituels types : Release Sprint, Sprint Testing,…

• De changer des choses sans prévenir

Des réponses faisant référence à ces choses sont souvent proposées dans les tests,
elles seront donc à considérer comme fausses, et à éliminer
Le PRODUCT OWNER (PO)

• C’est une personne unique, responsable/accountable du projet

• C’est un manager non hiérarchique
• Le PO est ROI (Return On Investment)

Son rôle est de :

• Manager et Ordonner le Product BackLog
• Envisager les objectifs des itérations puis les définir en coordination étroite avec
la Dev Team
• Décider quand cela fait sens de mettre en production l’incrément mis à sa
disposition par la Dev Team
• Répondre aux questions de la DT
• Interagir avec les Parties Prenantes
• Rendre compte de l’avancement et de la stratégie de livraison au management
et aux parties prenantes

Il est le responsable de l’existence des User Stories soient écrites, il peut néanmoins en déléguer
la rédaction
DEVELOPPEMENT TEAM (DT)
Composition : Entre 3 et 9 développeurs (hors Product Owner et Scrum Master). Equipe capable
d’exécuter des fonctions nécessaires pour délivrer un incrément

Son rôle est :

• De s’auto-organiser pour effectuer au mieux le travail qui lui incombe et résoudre les
problèmes et les conflits qui naissent en son sein
• De fabriquer un incrément de logiciel qui soit conforme à la Définition du Done

• De s’assurer que l’incrément en cours de fabrication est bien « stable » pour ce qui est des
nouvelles fonctionnalités MAIS AUSSI des anciennes

• De s’assurer qu’à la fin de chaque sprint l’incrément livré soit de qualité suffisante pour
pouvoir être mis en production si le Product Owner le souhaite (il n’est pas forcement mis
en production pour autant si le PO ne le souhaite pas)

• Elle est Responsable du DoD (Définition of Done) et peut consulter le PO à cet effet

• Elle est responsable de, notamment, suivre le Reste à faire du Sprint

• Elle est auto-organisée, mais pas autogérée (elle est constituée pour répondre aux besoins
du PO)
SCRUM MASTER (SM)
C’est un manager non hiérarchique
Son rôle est de :

• Promouvoir l’agilité et Scrum

• Faire en sorte que les rituels et les artefacts obligatoires se tiennent, enseignant et
accompagnant les autres rôles de la Scrum Team et les parties prenantes

• Lever les blocages

• Faire respecter les différentes time-box

• Favoriser la prise de décision et la collaboration commune par / dans la Scrum Team

• C’est un facilitateur (Servant Leader) :

-Il aide la Dev Team à s’auto-organiser afin qu’elle devienne autonome et monte en maturité
-Même dans la Retrospective, il joue son rôle de membre de l’équipe « facilitateur »
-Il a vocation à disparaître au profit de la Dev Team, plus présent au début et tend à
disparaître en cours de projet
-Il incite à une collaboration directe entre le PO et la Dev Team
LE MANAGEMENT

Son rôle est de :

Faciliter la vie de la Scrum Team :

• Accompagner le Scrum Master dans ses actions de changements

organisationnels

• Habiliter la Dev Team à être auto-organisée

Respecter le cadre de Scrum :

• S’ils souhaitent des changements – il doit passer par le Product Owner (qui
mettra à jour le Product Backlog)
TIME BOX

« co-
Event/ Rituel « Leader » « facilitateur » « observateur actif / inactif »
producteur »
Sprint DT PO SM (PP) si nécessaire
Sprint-Planning - Goal : PO DT
- Quoi : Pbi PO DT (PP) si nécessaire
SM
- Comment : Task DT PO
PO SM et PP è non obligatoire , et tous en
Daily Scrum DT DT
spectateurs, si ils sont présents
Sprint-Review PO DT & PP SM
Sprint Retrospective SM PO & DT SM Parties Prenantes (PP) si nécessaire
Backlog Refinement PO DT SM Parties Prenantes (PP) si nécessaire
Les Events / Rituels de SCRUM
Les Parties Prenantes (PP) peuvent être présentes mais en « spectateurs », elles s’expriment
uniquement à la Sprint-Review

« co-
Event/ Rituel « Leader » « facilitateur » « observateur actif / inactif »
producteur »
Sprint DT PO SM (PP) si nécessaire
Sprint-Planning - Goal : PO DT
- Quoi : Pbi PO DT (PP) si nécessaire
SM
- Comment : Task DT PO
PO SM et PP è non obligatoire , et tous en
Daily Scrum DT DT
spectateurs, si ils sont présents
Sprint-Review PO DT & PP SM
Sprint Retrospective SM PO & DT SM Parties Prenantes (PP) si nécessaire
Backlog Refinement PO DT SM Parties Prenantes (PP) si nécessaire
Artefacts obligatoires

Artefact Owner Composé de « Créé » et « Managé » Commentaires

« Créé » et « Managé » par le PO
Product Product Product avec appui de DT durant les Le PBLog évolue tout au long du projet, il
Backlog Owner Backlog Items activités de Backlog Refinement contient des PBi + gros que ceux présents
(PBLog) (PO) (Pbi) « Managé » avec les PP durant dans le SBLog
Sprint-Review
Tout type de Doit etre cohérent avec le sprint goal,
Sprint décomposition « Créé » et « Managé » par la DT Problème et questions doivent être traités
Dev Team
Backlog utile des PBI avec appui PO durant le Sprint entre PO et DT
(DT)
(SBLog) (Test, User Planning et le Sprint Peut évoluer en cours du Sprint (anomalies,
storie…) corrections …)
L’incrément livré par la DT à la fin d’un sprint
est composé :
Product
- Des nouvelles fonctionnalités
Incrément Owner PBi Done « Créé » par la DT durant le Sprint
- ET des anciennes
(PO)
Il doit être Done et Shippable
Si + d’une DT, l’incrément doit être GLOBAL
Artefacts facultatifs (néanmoins conseillés)

Artefact Owner Objectif « Créé » et « Managé » Observation

Fixé conjointement par :
Definition - PO et DT Souvent l’acronyme INVEST sert de
Product Owner Fixe les critères
du Ready Sous la surveillance du base à cette définition
(PO) d’un PBi
(DoR) SM pour qu’elle soit
SMART
Fixe les critères
Il devrait toujours y avoir une
pour qu’un Pbi
définition du Done
puisse être
Dev Team (DT) Elle doit être bâtie sur ce que
intégré dans
Definition en est l’équipe sait faire à un instant T
l’incrément. Peut Fixé par la Dev Team avec
du Done responsable (le Elle doit progresser (+ rigoureuse)
donc permettre à un avis éventuel du PO
(DoD) PO donne son dès que la connaissance de l’équipe
la DT de
avis) le permet
déterminer le
Il peut y avoir plusieurs niveaux de
nombre de Pbi
Done (PBi, Sprint, Release,…)
pour ce Sprint
Artefact Owner Objectif « Créé » et « Managé » Observation
La vélocité d’une DT ne doit
(normalement) pas se comparer à la
« Mesurer » la La vélocité ne se manage
Dev Team vélocité d’une autre DT
Vélocité production de valeur pas, elle se constate sprint
(DT) La vélocité et sa stabilité sont un bon
fournie DT après sprint
signe de maturité de la DT mais pas
un signe de succès du projet
Mesurer la progression Sert à visualiser / envisager la
Créé par le PO et MAJ à
Product de « l’effort » déjà progression du projet dans le temps
Burn Up l’issue de chaque Sprint
Owner réalisé (Work, pas Ex de métriques suivis (#US,#Valeur,
Review
value) #Effort)
Mesurer « l’effort » Créé par la DT (Parfois le Sert à visualiser la tendance
restant à accomplir => SM) à l’issue du Sprint « d’avancement » de l’équipe dans sa
Burn Dev Team
Work, pas value Planning et MAJ chaque tenue de l’objectif du sprint
Down (DT)
jour à l’issue du Daily Donne en tendance la date de fin
Scrum approximative
EQUIPE

• Lorsque la composition d’une équipe change (et elle peut changer si besoin), alors
la productivité va baisser quelque temps (il faut le temps de se réorganiser)

• Idem s’il y a plusieurs équipes et que leurs compositions changent, alors leur
productivité va régresser

• Les causes qui peuvent avoir un impact sur la performance de la DT ou la bloquer

sont multiples (changement scope, techno, Team members,…)

• Chaque Scrum Team doit comprendre un PO et un SM (qui peuvent être

partagés entre plusieurs Scrum Teams),
Le PRODUCT BACKLOG

• Est normalement ordonné avec ce qui a le plus de priorité en tête de liste

(top) - business value

• On prend en compte également les risques, dépendances avec d’autres produits et

items …

• Néanmoins il peut être ordonné différemment, comme le veut le Product Owner

qui en est le responsable

• Il peut évoluer si les besoins et/ou les conditions liés au produit changent
PRODUCT BACKLOG Items

Ils peuvent / doivent être de tout type :

Fonctionnel
Non Fonctionnel
Correctif…

Tout ce qui représente du travail pour l’équipe doit être dans le Product Backlog

• Un PBi est terminé lorsqu’il ne reste pas de travail à faire avant de le mettre à la
disposition des clients

• Les Exigences non fonctionnelles (architecture, temps de réponse, sécurité…)

peuvent également être dans la définition du Done
Le SPRINT
• Il contient :

Le Sprint Planning
Le Daily Scrum
La Sprint Review
La Sprint Retrospective

• Il débute immédiatement après la fin du sprint précédent, il ne se passe rien

entre les sprints

• Il se termine quand le time-box est terminé (4 semaines / 30 jours max)

• Doit servir à obtenir un incrément de logiciel Done et potentiellement Shippable

(mise en production possible si souhaitée, mais pas obligatoire « rappel », il peut
néanmoins y avoir quelques bugs mineurs)

Seul le PO peut décider de l’arrêter avant la fin du time-box

Le SPRINT Planning

Il sert à définir le Sprint Goal et le Sprint Backlog. 


Le Sprint Goal doit rester stable pour toute la durée du Sprint
Avant le sprint planning le PO doit avoir des objectifs Business clairs et précis afin de travailler
avec la DT de façon pertinente.

Déroulement :

• L’équipe doit constituer son plan d’action pour le sprint qui commence en tirant (to pull)
dans le Sprint Backlog les Product Backlog Items (PBi) qu’elle estime pouvoir livrer
dans l’Incrément (Done et Shippable) à la fin de la période
• L’ordre de prise en compte des Product Backlog Items est plutôt de la responsabilité
du Product Owner mais est négocié avec l’équipe de Développement
• Seule l’Equipe de développement (DT) est responsable des estimations de charge et
du découpage (Task) des Pbi, en concertation avec le PO
• Le Sprint Backlog peut stocker tout type de décomposition des PBi
• Si le travail de décomposition n’est pas totalement fini avant la fin du time-box, on
commence à « coder » et l’on poursuit la décomposition en tache de fond «over time »
• Si la DT pense qu’elle a pris trop de travail, on revoit le Sprint Backlog et/ou elle
informe le PO du risque de ne pas pouvoir tout faire
Le DAILY SCRUM

• Se tient tous les jours à la même heure au même endroit (pour simplifier les
choses) et pas obligatoirement tenu debout

• Durée maxi: 15 mn

• Il est organisé et managé par l’équipe de développement pour elle-même

• La Dev Team est le seul acteur actif du Daily Scrum. Elle fait en sorte que tout le
monde réponde aux 3 questions

qu’ai-je fais hier?, Que vais-je faire aujourd’hui? Et quels sont les points bloquants?

• En cas de problème, de remise en cause des dates ou du travail à faire, il doit y

avoir concertation avec le Product Owner
BACKLOG Refinement

Il n’a pas de Time Box: Il doit être à peu près de 10% de la capacité de l’équipe Scrum
(Scrum Team : PO+SM+DT)

C’est un travail entre le PO et la Dev Team pendant les sprints

INVEST :

I - indépendant
N- négociable
V - valuable
E - estimable
S - small (ou secure)
T - testable
SPRINT Review
• Elle est uniquement consacrée au produit, à l’aide des :

Product Backlog, Sprint Backlog, incrément et du BurnUp

• Seul ce qui est Done est présenté et discuté

Elle comprend :

• La démo produit
• La récolte du feedback des parties prenantes (et du PO)

• L’analyse des résultats de la démo : toujours Done (vélocité et BurnUp) ou KO

(Besoin éventuel de nouveaux PBi de correction dans le Product Backlog)

• La revue du Product Backlog pour envisager ce qui pourrait être fait ensuite
SPRINT Retrospective

• On y parle de tout (sauf du produit lui-même )

• L’objectif après une phase d’introspection, est d’adapter un plan d’action (liste de
changements que l’équipe souhaiterait mettre en œuvre éventuellement pour
s’améliorer :

Ø Cela peut porter sur n’importe quel point du fonctionnement du projet et de

l’équipe
Ø Les actions décidées à réaliser suite à ce plan, doivent être incluses dans le
Product BackLog (Pbi)
Scalabilité (lorsqu’il y a plusieurs DEV Teams)

• Il ne peut y avoir toujours qu’un seul Product Backlog et un seul Product

Owner

• Il peut néanmoins y avoir un ou plusieurs Scrum Master partagé(s) avec les

équipes

• Les équipes de développement sont collectivement auto-organisées :

Ø Elles choisissent comment elles se structurent

Ø Elles définissent un Done commun
Ø Elles choisissent ensemble comment elles sélectionnent (to Pull) et se
répartissent le travail à faire durant le sprint (qui peut (c’est même conseillé)
avoir les mêmes dates/durées pour chacune des équipes
Ø Elles doivent se synchroniser pour pour pouvoir livrerl’incrément (Done et
Shippable)
Quelques pièges à éviter

• Les réponses comportant des termes ou des notions qui ne font pas partie du
framework Scrum, sont en général fausses

• Même chose, pour les réponses comportant des rôles n’appartenant pas au
framework Scrum, elles sont généralement fausses

• L’utilisation des termes Must ou Mandatory veut bien dire obligatoires, et dans
Scrum les seules choses obligatoires sont :

Ø Trois artefacts : le Product backlog, le Sprint backlog et l’Incrément

Ø 6 events/rituels : Sprint, Sprint Planning, Daily Scrum, Sprint Review,

Sprint Retrospective, Backlog Refinement

Ø 3 rôles : Product Owner, la Development Team et le Scrum Master

De même, si il est écrit les affirmations ci-dessous dans
des réponses, vous pouvez les considérer comme
fausses et les éliminer !

Si il est écrit que:

• Scrum ne marche pas ou ne peut pas marcher

• Scrum, ses artefact ou ses events/rituels sont des sources d’informations ou des
occasions pour le management de blâmer un des membre de la Scrum Team,

• C’est une bonne chose que d’aller « baver » auprès du management, ou de

« taper » sur quelqu’un ou un rôle auprès des autres,

• Si il y a plusieurs équipes et que leur composition change, alors les équipes voient
leur productivité progresser, c’est évidemment l’inverse elle va baisser

• Que quelque chose (tâche, programme,..) peut appartenir à l’un des membres de
l’équipe (« own ») , c’est faux car tout appartient à tout le monde dans Scrum
Attention également à l’ambiguïté de certains termes Anglais

Over the time signifie : au fil du temps

Time signifie : l’heure du début

To create signifie : Finaliser

www.agilefacile.com