Abonnez-vous à DeepL Pro pour traduire des fichiers plus volumineux.

Visitez www.DeepL.com/pro pour en savoir plus.

Ce document a été créé conformément au guide Scrum 2020, qui aidera les gens à mieux
comprendre le cadre Scrum et à couvrir les domaines pour les examens PSM 1 ou CSM.

Auteur :
Muhammad Zahid Hussain

Date :
21 août 2022

1
Agile :

• L'agilité est la capacité à créer et à répondre au changement. C'est une façon de faire
face à un environnement incertain et turbulent et, en fin de compte, d'y réussir. Il s'agit
d'une approche du développement de logiciels qui vise la livraison continue de logiciels
fonctionnels créés par itérations rapides.

L'état d'esprit agile :

• Pour être agile, il ne suffit pas d'utiliser un certain nombre d'outils ou de pratiques ou de
suivre une méthodologie spécifique.
• L'agilité implique un "nouvel état d'esprit" et une "façon de penser" - qui se fonde sur le
manifeste agile comprenant 4 valeurs et 12 principes.

Faire de l'agilité ou être agile :

• Faire de l'agile se réfère aux pratiques agiles telles que le développement itératif et
incrémental, y compris des événements tels que les réunions quotidiennes, etc. Il s'agit
également d'un "état d'esprit non agile".
• Être agile fait référence à "l'état d'esprit agile", à "l'adoption des pratiques agiles" et à "l'adaptation
du processus".

Chef de projet Agile / Scrum Master, Must :

• Adopter un état d'esprit agile.

• Comprendre les principes agiles.
• Vendre l'idée de l'Agile / Éduquer les autres.
• Attendez-vous à des sceptiques / Coach other.

Membres de l'équipe Agile :

• Voir la valeur de l'approche agile. (Pourquoi l'utiliser ?)

• Expérimenter les avantages de la méthode agile.
• Obtenir des victoires rapides.
• Le concept principal de l'agile est qu'il y a un carnet de commandes avec des priorités.

Les parties prenantes du projet, doivent :

• Être prêt à essayer l'approche agile.

• Être convaincu des valeurs agiles.
• Expérience d'un ROI (retour sur investissement) rapide.
• Mangez d'abord le dessert (les bonnes choses).

Tâches relatives aux principes et à l'état d'esprit agiles :

• Défendre les principes et les valeurs agiles au sein de l'organisation.

• Assurer une compréhension commune des principes agiles.
2
• La transparence est synonyme de confiance.

3
• Partager les connaissances et les nouvelles collaborations (réunions quotidiennes et séances de
rétrospective).
• Le leadership émergent, qui signifie que n'importe quel membre de l'équipe peut devenir un leader.
• Pratiquer le leadership au service des autres.

Valeurs et principes agiles :

• Il existe deux stratégies pour respecter les valeurs et les principes de la méthode Agile : -
1. Adopter une approche agile formelle, conçue et éprouvée pour obtenir les résultats souhaités.
2. Mettre en œuvre les changements apportés au projet. Pratiquer d'une manière
adaptée au contexte du projet afin de faire progresser les valeurs et les principes
fondamentaux.

Manifeste Agile :

• Le manifeste Agile comprend 4 déclarations de valeurs et 12 principes directeurs. Ceux-

ci ont été rédigés par des experts en développement de logiciels.

1. Les individus et les interactions plutôt que les processus et les outils
2. Logiciel fonctionnel et documentation complète
3. La collaboration avec le client plutôt que la négociation du contrat
4. Réagir au changement plutôt que de suivre un plan

Les principes qui sous-tendent le Manifeste Agile :

1. Notre priorité absolue est de satisfaire le client par la livraison rapide et continue de
logiciels de qualité.
2. Accueillir les changements d'exigences, même à un stade avancé du développement.
Les processus agiles exploitent le changement pour l'avantage concurrentiel du
client.
3. Fournir des logiciels fonctionnels fréquemment, de quelques semaines à quelques
mois, avec une préférence pour les délais les plus courts.
4. Les chefs d'entreprise et les développeurs doivent travailler ensemble quotidiennement tout au
long du projet.
5. Construisez des projets autour d'individus motivés. Donnez-leur l'environnement et
le soutien dont ils ont besoin et faites-leur confiance pour accomplir le travail.
6. La méthode la plus efficace pour transmettre des informations à u n e équipe de
développement et au sein de celle-ci est la conversation en face à face.
7. Les logiciels fonctionnels sont la première mesure du progrès.
8. Les processus agiles favorisent le développement durable. Les sponsors, les
développeurs et les utilisateurs doivent être en mesure de maintenir un rythme
constant indéfiniment.
9. L'attention constante portée à l'excellence technique et à la qualité de la conception renforce
l'agilité.

4
10. La simplicité - l'art de maximiser la quantité de travail non effectué - est essentielle.
11. Les meilleures architectures, exigences et conceptions émergent d'équipes auto-organisées.
12. À intervalles réguliers, l'équipe réfléchit à la manière de devenir plus efficace, puis
ajuste son comportement en conséquence.

5
Scrum en bref :

• Dans le cadre de Scrum, les équipes prennent un problème et le divisent en petits

morceaux, puis appliquent une méthode incrémentale et itérative :

Par exemple :

o Liste des fonctionnalités du site web (inscription, connexion, CMS et paiement), etc.
o L'équipe dresse la liste de toutes ces caractéristiques dans le Backlog du produit
et ordonne la liste pour travailler sur les éléments les plus importants en fonction
de leur priorité.
o Après avoir hiérarchisé les éléments, l'équipe collabore lors de l'événement de
planification du sprint (Sprint Planning) et sélectionne quelques éléments
prioritaires qu'elle ajoute au carnet de commandes du sprint (Sprint Backlog).
o Travail d'équipe sur les éléments du carnet de commandes du sprint pendant (le
sprint) et à la fin, le produit (l'incrément) a été livré.
o (Increment) pour tout service ou produit doit être opérationnel et les nouvelles
fonctionnalités doivent être prêtes à l'emploi OU être visibles et utilisables par le
client.

Le flux Scrum :

1. Scrum commence par le Backlog du produit qui contient tout le travail à faire ou
décrit/représente ce qui permettra d'atteindre l'objectif du produit et qui est
maintenu par le Product Owner. Il/elle s'assure également que les éléments les plus
importants sont ceux qui sont en tête de liste.
2. Ensuite, nous organisons une réunion de planification au cours de laquelle les
développeurs sélectionnent un élément du carnet de commandes (le carnet de
6
 commandes du sprint est créé).
3. Le Sprint Backlog favorise l'alignement des attentes entre l'entreprise et l'équipe
technique.

7
 4. Pendant l'exécution du sprint, les développeurs organisent une mêlée quotidienne
pour synchroniser leur travail et maximiser les chances d'atteindre l'objectif du
produit.
5. Au cours du sprint, dès que les éléments du carnet de commandes répondent à la
définition de l'achèvement (DOD), un incrément voit le jour.
6. À la fin du sprint, l'équipe organise une réunion d'examen au cours de laquelle le
propriétaire du produit invite les parties prenantes à inspecter l'incrément produit.
Au cours de cette réunion, les commentaires des parties prenantes peuvent avoir
une incidence sur le carnet de commandes.
7. Après la réunion de révision, l'équipe scrum participe à une réunion de rétrospective
au cours de laquelle elle examine et adapte la manière dont le travail a été effectué
et planifie la poursuite de l'amélioration.
8. Le Scrum Master est responsable du bon déroulement de l'ensemble du processus scrum.

Scrum en tant qu'effort axé sur la valeur :

1. Les idées sont enregistrées dans le carnet de commandes, qui découle de la

vision du produit. Pour fournir une meilleure valeur, le carnet de commandes
doit également avoir une bonne valeur.
2. Le propriétaire du produit est responsable de la gestion du carnet de commandes.
3. L'affinage du carnet de commandes est un processus continu.
4. L'incrément est le résultat du sprint, que nous appelons aussi livraison verticale.

8
9
• Scrum suit la méthodologie Agile de développement itératif et incrémental. Une mise en
œuvre partielle d'un système total est construite de manière à ce qu'elle soit livrable.
Des fonctionnalités supplémentaires sont ajoutées. Les défauts éventuels de la livraison
précédente sont corrigés et le produit fonctionnel est livré. Le processus est répété
jusqu'à ce que l'ensemble du développement du produit soit achevé. Les répétitions de
ces processus sont appelées itérations. À la fin de chaque itération, un incrément de
produit est livré.

Théorie Scrum :

Scrum est fondé sur ce qui suit :

1. L'empirisme : Il signifie que la connaissance provient de l'expérience et que les

décisions sont prises sur la base de ce qui est observé.
2. Pensée allégée : Il s'agit d'une nouvelle façon de penser et de se concentrer sur
l'essentiel (ce qui est le plus nécessaire) et de réduire les gaspillages. Par exemple, si
l'objectif de l'événement scrum quotidien est atteint en 5 minutes, il n'est pas
nécessaire de rester en réunion pendant 15 minutes.

L'empirisme repose sur les trois piliers suivants :

1. Transparence : Il s'agit d'une norme commune de compréhension qui signifie que

tous les observateurs partagent la même compréhension de ce qui est vu et dit.
L'aspect significatif du processus doit être visible pour les personnes responsables
des résultats. Dans Scrum, la transparence est mise en œuvre dans 4 événements
Scrum et 3 artefacts.
2. L'inspection : Il s'agit d'une hypothèse de test pour vérifier ce qui s'est passé, ainsi
que d'apprendre et de s'adapter. Scrum a défini 4 événements pour l'inspection.
3. Adaptation : Au cours de l'inspection, si un processus semble s'écarter des limites
extérieures, il convient de l'adapter le plus tôt possible.

10
Valeurs de Scrum :

Si toutes les responsabilités sont mises en œuvre, les artefacts maintenus, mais que les valeurs
ne sont pas respectées, cela signifie que Scrum n'est pas mis en œuvre dans son essence.
Scrum fait référence à cinq valeurs :

1. Engagement : Les personnes s'engagent personnellement à atteindre les objectifs de

l'équipe scrum. Dans l'équipe scrum, les professionnels et les techniciens doivent
travailler ensemble. Toute l'équipe est tenue responsable des résultats. Peu importe
votre domaine de spécialisation, si l'un a réussi, tout le monde a réussi et si l'un a
échoué, tout le monde a échoué.
2. Courage : Les membres de l'équipe Scrum doivent avoir le courage de faire ce qu'il
faut et de travailler sur des problèmes difficiles. C'est nécessaire pour travailler sur
des problèmes difficiles. Les membres doivent emprunter des chemins difficiles
lorsqu'ils doivent faire face à un problème difficile.
3. Concentration : Chaque membre de l'équipe se concentre sur le travail du sprint et
sur l'objectif de l'équipe scrum.
4. L'ouverture : Ce point est étroitement lié à la transparence. L'équipe Scrum et les
parties prenantes ont accepté de s'ouvrir sur l'ensemble du travail et des défis
pendant l'exécution du travail. Pour cela, on utilise le plus souvent un radiateur
d'information tel que le Scrum Board, etc.
5. Le respect : Les membres de l'équipe doivent se respecter mutuellement pour être
des personnes indépendantes et compétentes. C'est un élément essentiel pour une
équipe complexe, performante et en pleine croissance.

11
L'équipe Scrum :

L'équipe Scrum est une petite équipe de personnes. Il n'existe pas non plus de sous-équipes
ou de concepts hiérarchiques. L'équipe se compose d'un Product Owner, d'un Scrum Master
et de 10 développeurs au maximum.

L'équipe Scrum a les trois responsabilités/rôles suivants :

1. Propriétaire de produit : il s'agit d'un professionnel qui s'occupe du carnet de commandes du
produit.
2. Les développeurs : Ils sont chargés de transformer les idées reflétées dans le carnet
de commandes en incréments utilisables.
3. Scrum Master : Responsable du bon déroulement de la mêlée.

• Si l'équipe Scrum devient trop grande, elle doit être décomposée en plusieurs équipes
cohésives (même nature de pensée) et chacune doit se concentrer sur le même objectif
de produit et avoir le même carnet de commandes.

• Collectivement, l'ensemble de l'équipe scrum est responsable de tous les types

d'activités, depuis la collaboration avec les parties prenantes jusqu'à la livraison finale.
En outre, l'ensemble de l'équipe est responsable de la livraison d'incréments utilisables.
• Il s'agit d'une unité cohésive de professionnels qui se concentrent sur un seul objectif à
la fois, à savoir l'objectif du produit.
• L'équipe doit être (autogérée 🡺 elle sait quoi, quand et comment faire ?) et
(interfonctionnelle 🡺 elle dispose de toutes les compétences nécessaires pour fournir
un incrément de valeur).

12
Propriétaire de produit :

• Responsable de la chaîne de livraison de la valeur ou de la maximisation de la valeur

du produit résultant de l'équipe scum. L'image suivante montre comment le Product
Owner maximise la valeur du produit.

• Il/elle gère le carnet de commandes du produit. Cela inclut la communication et le

développement des objectifs du produit et la commande d'articles dans le carnet de
commandes.
• Le PO n'est pas un pont nécessaire entre le client/l'équipe commerciale et les
développeurs. Les développeurs et le client peuvent s'adresser l'un à l'autre si
nécessaire, mais ils ne peuvent pas commander et interrompre les développeurs. Le
Scrum Master doit s'assurer de tout cela.
• Un Product Owner faible ne peut pas travailler efficacement. Il doit avoir le pouvoir
de hiérarchiser le travail, d'inspecter l'incrément et de s'adapter en temps voulu.

Product Owner - Principaux enseignements :

• Les techniciens et les commerciaux doivent comprendre scrum pour en tirer profit. Si
ce n'est pas le cas, le Scrum Master doit organiser des sessions de coaching ou
travailler avec l'approche traditionnelle de la gestion de projet en fermant le
périmètre de travail.
• Il/elle doit avoir des connaissances et une autorité dans le domaine des affaires.
• Il/elle doit être disponible pour l'équipe en cas de besoin.
• D'autres personnes peuvent effectuer des tâches liées à la gestion du carnet de
commandes, mais le propriétaire du produit en reste responsable.

13
Les développeurs :

• Responsable de la transformation des éléments du Backlog de produit en un

incrément utilisable conformément à la définition de ce qui est fait.
• Ils sont interfonctionnels et autogérés.
• Ils s'engagent à atteindre l'objectif du sprint.
• Responsable de l'élaboration du plan de sprint, appelé backlog de sprint.
• Il est responsable de l'exécution du Daily Scrum et de l'adaptation quotidienne de son plan en
vue de la réalisation de l'objectif du sprint.
• Se tenir mutuellement responsables en tant que professionnels.

Le Scrum Master :

• Il est au service de l'organisation et de l'équipe scrum.

• Il aide les personnes extérieures à interagir positivement avec l'équipe scrum.
• Il/elle est responsable de l'efficacité de l'équipe scrum.
• Il forme l'équipe et l'organisation à la compréhension du scrum.
• Provoque la levée des obstacles. Ceux-ci peuvent être soulevés par n'importe qui et à n'importe
quel moment.
• Diriger et faciliter l'adaptation du scrum en animant des réunions.
• Le Scrum Master est également un manager qui gère le cadre de scrum. Bien qu'il n'ait pas
l'autorité sur l'équipe ou la gestion des personnes.
• Le Scrum Master ne doit pas "chasser" les obstacles/bloqueurs. En outre, il ne doit
pas nécessairement supprimer tous les obstacles. (L'équipe doit être autogérée et
doit savoir comment supprimer les obstacles et le scrum master doit l'aider à
s'autogérer).

14
Faire face au travail non fait et aux obstacles :

1. Le travail non effectué doit-il faire partie de l'incrément ?

Réponse : Non, il ne devrait pas faire partie de l'incrément pour les raisons suivantes :
a. Une partie non réalisée de l'incrément entravera l'autonomie de l'incrément.
b. La présentation d'un travail non effectué lors d'une réunion d'évaluation peut
entraîner des problèmes de communication avec les parties prenantes, car elles
pourraient penser que le travail a été effectué, ce qui nuirait à la transparence.
c. D'autres développeurs pensent qu'il n'y a pas de mal à livrer un travail non
achevé. Ils doivent savoir comment gérer le travail non fait.

2. Le travail non fait doit-il être présenté aux parties prenantes lors de la revue de sprint ?

Réponse : Ces éléments ne doivent pas faire partie de la réunion de révision mais
doivent être replacés dans le backlog du produit. Ces éléments peuvent faire l'objet
d'une discussion lors de la réunion de révision.

3. Traiter avec un développeur hostile. Ce développeur est en conflit avec les autres
membres de l'équipe et crée un environnement hostile. Le cas échéant, qui est
responsable du retrait du développeur ? LE PO ? SM ? Les développeurs ou les RH ?

Réponse : Le Scrum Master est responsable parce que le développeur concerné est
considéré comme un obstacle ? Non, les développeurs doivent l'éliminer, le Scrum
Master les aide s'ils ne sont pas en mesure d'éliminer ces obstacles.

⮚ Le Scrum Master doit favoriser l'autogestion.

⮚ Si l'équipe soulève un obstacle, le scrum master ne doit pas le résoudre lui-même
mais former l'équipe à le résoudre car l'équipe est autogérée.

15
Artéfacts Scrum :

• Scrum a trois artefacts (Backlog de produit, Backlog de sprint et Incrément). Ces

artefacts soutiennent les trois piliers que sont la transparence, l'inspection et
l'adaptation.
• Le Backlog de produit représente le travail "TODO", le Backlog de sprint représente le
travail "Plan" pour le sprint et l'Incrément représente la "Valeur" et la "Transparence"
pour l'inspection et l'adaptation.
• Les artefacts sont conçus pour maximiser la transparence et toutes les parties prenantes devraient
s'y aligner.
• L'objectif de chaque artefact peut être mesuré par l'engagement.

But du produit :

o Il décrit l'état futur du produit qui peut servir d'objectif à l'équipe de scrum pour
planifier.
o Il existe dans le carnet de commandes du produit et repose généralement sur des
hypothèses.
o Il décrit l'état futur du produit.

16
 o Le produit lui-même ne peut pas être un objectif. Il n'est qu'un moyen
d'atteindre des objectifs de haut niveau, par exemple gagner de l'argent ou
automatiser un processus manuel pour gagner du temps.
o Il peut y avoir plusieurs objectifs de produit qui peuvent être liés et organisés
sur une feuille de route de produit. (La feuille de route du produit ne fait pas
partie du guide officiel de Scrum).

o S'il existe plusieurs objectifs de produit, l'équipe doit se concentrer sur un

seul objectif de produit à la fois.
o Le propriétaire du produit est chargé de développer et d'expliquer l'objectif du produit.
o Les objectifs communs des organisations en matière de produits sont les suivants :
✓ Acquérir ou conserver des clients.
✓ Accroître l'engagement
✓ Générer des revenus et réduire les coûts.

Backlog de produit - Vue d'ensemble :

• Il s'agit d'une liste ordonnée émergente de ce qui est nécessaire pour améliorer le
produit. Il s'agit d'une source unique de travail pour l'équipe de scrum. La liste peut
contenir des exigences, des fonctionnalités ou des améliorations.

17
• Les attributs communs des éléments du carnet de commandes sont la description, l'ordre et la
taille.
• Le carnet de commandes est un manifeste de la stratégie produit qui signifie
"Comment la vision doit être réalisée".
• Le diagramme en oignon suivant montre comment la vision de l'entreprise ou du
client se transforme en une demande adressée aux développeurs pour qu'ils
fournissent un incrément.

• La vision du produit représente la vision de l'entreprise ou du client qui reflète

l'objectif de développement d'un produit.

18
• Le plus souvent, les éléments existent sous la forme de "User Stories" dans le backlog du
produit. Mais la User Story n'est pas une partie officielle du guide scrum.

Ordonner le carnet de commandes :

• Le guide Scrum ne prescrit aucun détail ou règle concernant l'ordre des éléments
dans le carnet de commandes.
• Le propriétaire du produit commande en tenant compte de ce qu'il juge approprié.
Par exemple, en fonction de la taille, de la complexité ou de la valeur commerciale.

• Les attributs tels que la taille, l'ordre et la description varient souvent en fonction du domaine
de travail.

Dimensionnement des éléments du carnet de commandes :

• Les développeurs sont responsables du dimensionnement et de l'estimation des éléments du

carnet de commandes.
1. Note : Le mot estimation n'est pas utilisé dans le guide Scrum.
• Le guide Scrum ne prescrit aucune règle pour le dimensionnement/l'estimation.
• L'unité la plus populaire est "Story Pointing".
• La technique d'estimation ou de dimensionnement la plus populaire en agile est le "Planning
19
 Poker".
• Dans les équipes agiles, l'estimation se fait selon une approche "relative" plutôt qu'absolue.

20
 • Le Story Pointing se fait en fonction de la "taille" et de la "complexité" du problème.
(Note : Le Story Pointing n'est pas une partie officielle du guide scrum).

Planning Poker - Technique d'estimation (pas une partie officielle du guide Scrum) :

• Il s'agit d'une technique d'estimation agile basée sur la collaboration et le consensus.

• Chaque développeur contient une carte avec un numéro et chaque numéro
représente un point de l'histoire.
• Au cours de cette activité, le propriétaire du produit décrit/explique les éléments
du carnet de commandes, après quoi chaque développeur choisit en privé une
carte représentant son estimation ou son dimensionnement.
• Si l'équipe n'est pas parvenue à un consensus sur l'estimation fournie, la
ressource dont l'estimation est élevée et celle dont l'estimation est faible doivent
expliquer la raison de leur estimation. Si l'équipe n'est pas d'accord, cette activité

sera à nouveau exécutée.

Valeur de l'élément du Backlog de produit :

• Le guide Scrum ne prescrit aucune technique pour définir la valeur des éléments du
carnet de commandes. Cela dépend totalement du propriétaire du produit qui pense
que c'est approprié.
• L'une des techniques les plus répandues est le "modèle Kano". Il classe les éléments du carnet
de commandes en
l'une des trois catégories suivantes. (Il ne s'agit pas d'une partie du guide scrum).

21
Raffinement du carnet de commandes :

• Il s'agit de décomposer et de définir plus précisément les éléments du carnet de

commandes en éléments plus petits et plus précis.
• Raffinement effectué en collaboration par l'équipe Scrum, généralement par les
développeurs et le propriétaire du produit.
• L'équipe Scrum définit comment et quand l'affinage est effectué.

Definition of Ready (DOR) : (Pas une partie officielle du guide Scrum)

• Il s'agit d'un ensemble de critères définis lorsque les éléments du carnet de

commandes sont prêts à être exécutés.
• Il améliore la transparence et la compréhension commune du carnet de commandes.

22
Suivi des progrès accomplis dans la réalisation de l'objectif :

• A tout moment, le travail total restant à accomplir pour atteindre un objectif.

• Le guide Scrum décrit trois pratiques possibles qui sont les suivantes :

1. Graphique d'épuisement des ressources : Il indique le travail restant à accomplir en

fonction du temps.

2. Graphique d'épuisement des ressources : Il indique la quantité de travail

accomplie (ligne rouge) et la variation du champ d'application (ligne rouge).

23
 3. Flux cumulatif : il montre l'état des problèmes au fil du temps. Cela vous aide à
identifier les goulets d'étranglement potentiels qui doivent être examinés.

• Il n'est pas nécessaire que l'objectif du produit soit atteint pour que tous les éléments du
carnet de commandes soient réalisés.

Backlog de sprint :

24
• Backlog de sprint créé après la réunion de planification du sprint.

• L'objectif du sprint est fixe, mais le carnet de commandes du sprint est flexible.
• Il s'agit d'une image en temps réel du travail que le développeur s'est engagé à
accomplir pendant le sprint. Il est très visible.
• Si les développeurs veulent négocier l'étendue du sprint, ils doivent en parler au Product
Owner en lui rappelant que l'objectif du sprint ne doit pas être modifié.
• Le carnet de sprint est planifié par et pour les développeurs.
• L'objectif du sprint est l'engagement des développeurs et non le backlog du sprint.
• L'objectif du sprint est créé lors de la réunion de planification du sprint, puis ajouté au carnet de
commandes du sprint.
• Le carnet de bord du sprint peut également être établi au cours du sprint.

25
Augmentation :

• Il s'agit de la somme de tous les éléments du carnet de commandes achevés au cours du

sprint et de la valeur livrée au cours des sprints précédents.
• Plusieurs incréments sont créés au cours du sprint, mais l a somme de tous les
incréments doit être présentée lors de la réunion de révision.
• L'incrément soutient l'empirisme à la fin du sprint.
• Il doit toujours être en état de fonctionner.
• Il n'est pas nécessaire de publier l'incrément à la fin de chaque sprint. Il est publié
lorsque le propriétaire du produit estime qu'il est utile.
• Le sprint n'est pas non plus une porte d'entrée pour la mise en production. La libération peut être
effectuée au cours d'un sprint.
• L'incrément naît lorsqu'il répond à la définition de l'acte accompli (DOD).

Définition de Fait :

o Il s'agit d'un critère ou d'une définition de ce qui est nécessaire pour qu'un travail
soit considéré comme accompli. Il favorise la transparence et la visibilité.
o Tout le monde devrait avoir la même compréhension de ce qu'est le fait.
o Selon le guide scrum, il s'agit d'une description formelle de l'état de l'incrément
lorsqu'il répond aux mesures de qualité requises pour le produit.
o Lorsque les éléments du backlog répondent à la définition de "done", l'incrément
est né et s'il n'y répond pas, il est renvoyé dans le backlog du produit.
o DOD ≠ Critères d'acceptation.
o La DOD est la même pour tous les articles, alors que les critères d'acceptation sont
différents pour chacun d'entre eux.
o Chaque incrément doit avoir une seule définition de l'acte accompli.
o Défini par l'organisation comme un standard, si ce n'est pas le cas, l'équipe
Scrum le définira mutuellement.
o Définir le DOD est un effort continu et peut évoluer au cours de l'exécution, ce
qui signifie qu'il n'est pas fixé pendant le sprint. Il peut y avoir des ajouts ou des
retraits dans la liste des critères.

Dette technique : (Ne fait pas partie du guide Scrum mais est présente dans le glossaire Scrum)

• Il s'agit du coût implicite des retouches supplémentaires causées par le choix d'une
mauvaise solution au lieu d'une meilleure approche qui prendrait plus de temps.
• Les conséquences de mauvaises pratiques de développement de logiciels seront
principalement subies par les parties prenantes non techniques.
• Le code avec une dette technique élevée est vraiment difficile à travailler et le coût du changement
est élevé.
• Le cadre Scrum gère cela par le biais de la définition des tâches à accomplir et la qualité
du produit est un sujet abordé lors de la réunion rétrospective et les choses peuvent
être gérées dans les sprints à venir.
• Ce n'est pas nécessairement toujours mauvais. (Elle peut être utilisée à des fins d'apprentissage).

26
Événements Scrum :

• Il existe cinq événements Scrum, à savoir le Sprint, la Planification du Sprint, la

Mêlée quotidienne, la Revue du Sprint et la Rétrospective du Sprint. Dans cet article,
nous allons nous plonger dans chacun des événements Scrum qui se déroulent au
cours d'un Sprint. Dans Scrum, le Sprint est un événement d'une durée fixe d'un
mois maximum, qui contient tous les autres événements.
• Les événements Scrum sont souvent appelés "cérémonies Scrum".
• Tous les événements de la mêlée sont encadrés dans le temps. Le timeboxing
consiste à allouer une unité de temps fixe à une activité. L'unité de temps est
appelée time box. La durée maximale d'une case temporelle est de 15 minutes.

1. Le sprint :

• Le sprint est un cycle répétitif au cours duquel le travail est achevé et prêt à
être revu. La durée du sprint Scrum dépend de la taille du projet et de
l'équipe qui y travaille.
• Il n'y a pas de décalage entre les sprints, un nouveau sprint démarre
immédiatement après la clôture du précédent.
• Un sprint n'est annulé que lorsque le délai a expiré ou que l'objectif du sprint
est devenu obsolète, et seul le Product Owner a le pouvoir de l'annuler.
• Le sprint consiste en quatre événements formels et, au cours d'un sprint, un
incrément réalisé et utilisable doit être créé.
• Il doit avoir une durée déterminée. Pas plus d'un mois.
• Il aide également l'équipe de scrum à contrôler les risques.
• Pendant le sprint, aucune modification ne doit être apportée qui pourrait
affecter l'objectif du sprint. De même, la qualité ne doit en aucun cas être
compromise.
• Le carnet de commandes sera affiné si nécessaire.
• L'équipe doit clarifier et renégocier le champ d'application avec le
propriétaire du produit au fur et à mesure qu'elle en a connaissance.
• Les sprints suivants ne sont pas valables selon le guide scrum et ne sont pas
autorisés selon le guide :
o Durcissement (ou intégration ou stabilisation) Sprint.
o Sprint 0 et Sprint de conception
o Sprint de lancement
• Pour suivre la progression du sprint, le guide scrum n'a prescrit aucune
pratique projective. L'équipe peut utiliser les diagrammes Burn Down ou Up,
les WBS, etc.
• Dans le cadre de scrum, chaque sprint doit être réalisé conformément à la définition de
l'action.

2. Planification du sprint :

• L'événement de planification du sprint a lieu le premier jour du sprint. Il a

pour but de planifier le travail à effectuer pendant le Sprint et toute l'équipe
Scrum est impliquée dans cet événement.
27
• L'équipe Scrum participe à cet événement et peut également inviter d'autres
parties prenantes à donner leur avis.
• Délai de 8 heures pour un sprint d'un mois.

28
• Lors de cet événement, l'équipe de scrum définit l'objectif (ce qui doit être construit) du
sprint.
• Un plan est élaboré au cours de cet événement pour atteindre l'objectif, appelé backlog
du sprint.
• Seuls les développeurs peuvent modifier le carnet de sprint et le carnet de
sprint est la seule source de travail pour les développeurs.
• L'objectif du sprint est l'engagement des développeurs et non le backlog du sprint.
• Comment organiser un événement de planification de sprint :
o Introduction
Le Scrum Master, qui joue le rôle de facilitateur, introduit
l'événement en souhaitant la bienvenue aux participants, en
expliquant l'objectif de la réunion aux personnes invitées par l'équipe
Scrum et en montrant l'ordre du jour de la réunion. (5-10 min)
o Thème 1 : Pourquoi ?
Le propriétaire du produit prend la direction des opérations, donne
une vue d'ensemble du produit et rappelle à tout le monde l'objectif à
long terme du produit ainsi que l'objectif actuel du produit. Il se
prépare et propose un projet d'objectif de sprint. Par exemple, en
supposant que nous soyons dans un domaine de paiement, l'objectif
du sprint pourrait être le suivant : D'ici la fin du Sprint, nous
prendrons en charge les paiements par carte pour tous les clients de
l'UE. (10-15 min)
o Thème 2 : Quoi ?
Le Product Owner et les développeurs passent rapidement en revue le
Product Backlog. Les développeurs doivent avoir contribué à l'affinage
du Backlog de produit, en passant "juste assez" de temps pour faire
quelques clarifications finales et des changements éventuels après la
dernière session d'affinage du Backlog de produit. (30 min) Les
développeurs font une prévision de la capacité qu'ils pensent pouvoir
consacrer à la construction de l'incrément pendant le sprint et
sélectionnent ensuite une liste de PBI qu'ils pensent pouvoir achever
d'ici la fin du sprint. Si ces PBI semblent suffisants pour atteindre
l'objectif du sprint proposé par le BC, cette partie de la planification
du sprint est terminée. Dans le cas contraire, le PO et les
développeurs collaborent pour élaborer un nouvel objectif de sprint
qui correspond mieux à ce que les développeurs peuvent fournir.
Dans l'exemple ci-dessus, ils pourraient arriver à quelque chose
comme : D'ici la fin du sprint, nous ne prendrons en charge que les
paiements par carte de débit pour tous les clients de l'UE. (15-30 min)
o Deuxième thème : Comment ?
Les développeurs créent collectivement un plan d'action pour réaliser
l'incrément. Ils s'autogèrent sur la meilleure façon d'y parvenir. Il n'est
pas nécessaire de créer un plan détaillé pour le Sprint. L'équipe Scrum
doit plutôt anticiper les opportunités émergentes et être prête à
adapter son plan au fur et à mesure qu'elle apprend. Il est
probablement suffisant d'avoir une idée de ce que chaque

29
 développeur fera dans les 2 ou 3 jours à venir. Dans cette phase de la
planification du sprint, le PO n'est pas vraiment nécessaire.
Cependant, il est bon qu'il soit disponible pour répondre aux
questions ou clarifier les besoins des clients. (30- 45 min)
o Fermeture
Le Scrum Master remercie les participants pour leur contribution et
clôt officiellement l'événement. (5 minutes)

30
3. Scrum quotidien :

• La mêlée quotidienne est le moment où les développeurs prennent du recul

pendant 15 minutes, analysent leur situation par rapport à l'objectif du sprint
et décident collectivement de la chose la plus importante que chaque
développeur doit faire dans les prochaines 24 heures pour se rapprocher de
l'objectif du sprint.
• Le Scrum Master s'assure uniquement que l'événement ou la réunion a eu
lieu et conseille les développeurs pour qu'ils respectent le délai de 15
minutes.
• Les autres parties prenantes ne seraient pas autorisées à assister à la réunion.
• Le Product Owner et le Scrum Master ne sont pas non plus invités à la réunion, sauf s'ils
sont tous les deux
travailler activement en tant que développeur et participer, ils sont en tant que
développeur.
• Les développeurs peuvent choisir la structure et les techniques qu'ils
souhaitent pour organiser cet événement, l'accent étant mis sur l'inspection
en vue de la réalisation de l'objectif du sprint.
• Quand ? Tous les jours ouvrables à la même heure
Durée : 15 minutes au maximum
Les participants : La mêlée quotidienne est le seul événement autogéré par
les développeurs. Le rôle du SM est d'enseigner et de coacher les
développeurs pour qu'ils puissent la gérer de manière autonome.
Résultat : Un Sprint Backlog adapté, si nécessaire
Structure : Les développeurs décident de la manière dont ils veulent gérer le projet.

4. Revue Sprint :

• La revue de sprint est l'occasion pour l'ensemble de l'équipe Scrum de se

tenir devant les utilisateurs, les parties prenantes et les clients et d'inspecter
et d'adapter le produit. Elle a lieu à la fin du Sprint. La réunion doit inclure
une vue d'ensemble de l'état du produit en termes de progrès, de budget et
de prochaines étapes. En général, il y a aussi une démonstration pratique du
produit actuel. Les utilisateurs et les parties prenantes font part de leurs
commentaires, puis les développeurs les intègrent dans le carnet de
commandes du produit.
• La revue Sprint porte sur la "transparence" et la "collaboration".
• Quand : Dernier jour du Sprint
Durée : Un maximum de quatre heures pour un sprint d'un mois. Pour les
sprints plus courts, la durée est généralement plus courte : environ deux
31
heures pour un sprint de deux semaines.
Les participants : L'ensemble de l'équipe Scrum (Product Owner,
Développeurs, Scrum Master) ainsi que les clients, les parties prenantes et
les utilisateurs. L'événement est généralement animé par le Scrum Master.
Résultat : Backlog de produit révisé et modifications du produit ou de la
stratégie de diffusion, le cas échéant.

32
 Structure : Une phase d'inspection suivie d'une phase d'adaptation (séance
de travail).

• Comment effectuer une revue de sprint :

o Introduction :
Le SM, qui joue le rôle de facilitateur, introduit l'événement en
souhaitant la bienvenue aux participants. Il explique l'objectif de la
réunion aux participants, qui peuvent être des utilisateurs, des parties
prenantes et des clients. Il présente ensuite l'ordre du jour de la
réunion. (5-10 min)
o Phase d'inspection :
Le PO prend la direction des opérations et fournit une vue d'ensemble
de l'état du produit en termes de progrès, de budget et de prochaines
étapes. Il rappelle à tous l'objectif du produit et décrit l'objectif du
sprint que les développeurs ont essayé d'atteindre. (10 min) Le PO
laisse la place aux développeurs pour qu'ils fassent la démonstration
de l'incrément. Il ne s'agit pas d'une présentation PowerPoint de ce
que l'équipe a fait, mais d'une démonstration pratique du produit
actuel. En général, les développeurs passent en revue les scénarios
décrits dans les critères d'acceptation de chaque PBI. Certaines
équipes laissent même les utilisateurs ou les clients essayer le produit
eux-mêmes, pendant que les développeurs et le Product Owner
observent comment ils interagissent avec l'Incrément. (30 min)
L'équipe Scrum recueille les commentaires de tous les participants
invités sur l'Incrément. (15-30 min)

• Phase d'adaptation :
Les utilisateurs, les parties prenantes et les clients peuvent quitter la réunion
à ce stade, tandis que l'équipe Scrum poursuit la session de travail pour
intégrer les commentaires pertinents dans le Backlog de produit. Si le retour
d'information est lié à quelque chose qui n'a pas d'impact sur le Sprint à
venir, ils peuvent simplement prendre des notes pour traiter le retour
d'information dans l'une des prochaines sessions d'affinage du Backlog de
Produit. Cependant, si le feedback affecte potentiellement le prochain
objectif du Sprint, l'équipe Scrum effectuera une session rapide d'affinage du
Backlog de Produit pendant la Revue de Sprint pour se préparer à la
planification du Sprint à venir. (30 min)

• Clôture :
Le Scrum Master remercie les participants pour leur contribution et clôt
officiellement l'événement. (5 minutes)

33
5. Rétrospective du sprint :

• La rétrospective du sprint est le seul événement de Scrum qui est exclusif à

l'équipe Scrum. L'intention est de créer un espace sûr où tous les membres
de l'équipe Scrum se sentent à l'aise pour partager ouvertement leurs
observations et exprimer leurs points de vue et leurs idées. L'objectif de
l'événement est d'inspecter le déroulement du dernier sprint et de planifier
des moyens d'améliorer la qualité et l'efficacité.
• Il est tenu d'améliorer les choses et de poursuivre l'amélioration.
• Quand : Dernier jour du Sprint, juste après la Revue du Sprint
Durée : Un maximum de trois heures pour un sprint d'un mois. Pour les
sprints plus courts, la durée est généralement plus courte.
Les participants : Uniquement l'équipe Scrum : Product Owner (PO),
Développeurs, Scrum Master (SM). Le Scrum Master facilite généralement
l'événement
Résultat : Un plan d'amélioration
Structure : Une bonne structure est suggérée dans le livre "Agile
Retrospective - Making Good Teams Great" d'Esther Derby et Diana Larsen,
qui comprend les 5 étapes suivantes :
• Préparer le terrain
• Recueillir des données
• Générer des idées
• Décider de ce qu'il faut faire
• Fermer la rétrospective

• Comment mener une rétrospective de sprint :

o Préparer le terrain
o Le SM, qui joue le rôle de facilitateur, introduit l'événement en
souhaitant la bienvenue aux participants et en présentant l'ordre du
jour de la réunion. Il s'efforce de créer un environnement propice à
une communication ciblée et ouverte. Il est essentiel pour l'équipe de
prendre du recul par rapport au stress et d'envisager différentes
perspectives afin de trouver des possibilités d'amélioration. (5
minutes)
o Voici une activité simple mais efficace. Demandez à chaque personne
d'écrire sur une note autocollante la pire chose qui lui passe par la
tête en ce moment et sur une autre note autocollante ce qui la
rendrait heureuse après l'événement. Demandez-leur ensuite de jeter
la première note et de garder la seconde.
o Recueillir des données
o Il est maintenant temps de rassembler les données objectives (par
exemple le nombre de bogues trouvés) et subjectives (par exemple la
façon dont les différentes personnes se sont senties tout au long du
Sprint) du Sprint. (10-15 min)
o Il est parfois difficile pour les gens de se souvenir des données après
34
quelques semaines. Envisagez de demander à chacun de signaler les
événements lorsqu'ils se produisent (par exemple en ajoutant des
notes autocollantes sur un tableau Miro) avec une brève description
et un horodatage. Au cours de la rétrospective, vous pouvez examiner

35
 les notes autocollantes et les classer sur une ligne temporelle.
Ensuite, chaque personne visualise son humeur par rapport à ces
événements. Vous disposez ainsi de données objectives et subjectives
en un seul artefact visuel.
o Générer des idées
o Il est maintenant temps d'examiner les données et d'essayer de
trouver des modèles. Celles-ci permettront à l'équipe d'identifier un
ou deux domaines d'amélioration. (15-30 min)
o Décider de ce qu'il faut faire
o Une fois que le domaine d'amélioration le plus important a été
identifié, l'équipe collabore pour définir quelques éléments
réalisables à incorporer dans le prochain sprint. Ces éléments sont
considérés comme des expériences. Une fois que l'équipe a validé le
fait qu'ils ont un impact positif, elle peut les incorporer dans ses
routines et ses pratiques. L'utilisation de la technique SMART permet
de définir des actions spécifiques, mesurables, atteignables,
pertinentes et limitées dans le temps. (30-45 min)
o Fermer la rétrospective
o Le Scrum Master remercie les participants pour leur contribution, clôt
l'événement et encourage tout le monde à célébrer le Sprint. Dans le
cas d'une organisation en personne, c'est peut-être le moment pour
le PO de partager un gâteau pour remercier tout le monde de ses
efforts. (5 min)

36
Scrum à l'échelle :

• Scrum à l'échelle" est une mise en œuvre de Scrum dans laquelle plusieurs équipes
Scrum créent un système ou un produit logiciel. L'objectif de Scrum,
indépendamment de l'échelle à laquelle il est utilisé, est de créer des versions de
haute qualité et publiables du produit à la fin de chaque sprint.
• Il est basé sur Scrum tel que défini dans le guide Scrum mais en modifiant les
événements, les rôles et les artefacts afin de mieux répondre aux besoins de
l'échelle.
• Toutes les équipes Scrum à l'échelle ont un PO, un PB et un Product Goal.
• 3 - 9 équipes devraient être dans la mêlée de Nexus.
• Enfin, il devrait y avoir un incrément intégré.
• Pour mieux gérer les dépendances, il faut définir une équipe d'intégration composée
du PO, d'un Scrum Master et de quelques développeurs d'autres équipes Scrum.
Cette équipe est responsable de la définition des tâches à accomplir et d'autres
tâches techniques liées à la collaboration.

🡸======================The End =====================🡺

37