Vous êtes sur la page 1sur 39

2021

PREPARATION EXAMEN PSM1 FOUNDATION

Wilfried FOALEM, Ingénieur Télécoms


WILFRIED FOALEM, INGENIEUR TELECOMS
ITIL4, PSM, PRINCE2, P3O certified
Le Guide Scrum™
Le Guide de Référence de Scrum:
Les Règles de Jeu

Novembre 2017

Développé et maintenu par les créateurs de Scrum: Ken Schwaber et Jeff


Sutherland

FRANÇAIS / FRENCH
Table des Matieres
But du Guide Scrum ......................................................................................................................... 3
Définition de Scrum ......................................................................................................................... 3
Usages de Scrum ............................................................................................................................. 3
Théorie de Scrum ............................................................................................................................ 4
Valeurs Scrum .................................................................................................................................. 5
Équipe Scrum ................................................................................................................................... 6
Le Product Owner ........................................................................................................................ 6
L’équipe de Développement ....................................................................................................... 7
Le Scrum Master .......................................................................................................................... 7
Les événements Scrum .................................................................................................................... 9
Le Sprint ....................................................................................................................................... 9
Planification du Sprint ............................................................................................................... 10
Daily Scrum ................................................................................................................................ 12
Revue de sprint .......................................................................................................................... 13
Rétrospective de Sprint ............................................................................................................. 14
Backlog Produit.......................................................................................................................... 15
Backlog Sprint ............................................................................................................................ 16
Incrément .................................................................................................................................. 17
Artefact de Transparence .............................................................................................................. 17
Définition de « Fini » ................................................................................................................. 18
Note de Fin .................................................................................................................................... 19
Remerciements ............................................................................................................................. 19
Personnes .................................................................................................................................. 19
Historique .................................................................................................................................. 19
Traduction ................................................................................................................................. 19
Changements entre les versions 2016 et 2017 du Guide Scrum .................................................. 20

©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at
http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you have
read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Page | 2
But du Guide Scrum
Scrum est un cadre de travail (framework) pour le développement, la livraison et la maintenance
de produits complexes. Ce guide contient la définition de Scrum. Cette définition comprend les
rôles, les événements, les artefacts et les règles de Scrum qui les lient ensemble. Ken Schwaber
et Jeff Sutherland ont développé Scrum ; Le Guide Scrum est écrit et fourni par eux. Ensemble, ils
sont derrière le Guide Scrum.

Définition de Scrum
Scrum(n) : Un cadre de travail (framework) au sein duquel les acteurs peuvent aborder des
problèmes complexes et adaptatifs, en livrant de manière efficace et créative des produits de la
plus grande valeur possible.

Scrum est :

• Léger
• Simple à comprendre
• Difficile à maîtriser

Scrum est un cadre de processus qui a été utilisé pour gérer le travail sur des produits complexes
depuis le début des années 1990. Scrum n'est pas en soi un processus, une technique ou une
méthode définitive. C'est plutôt un cadre de travail (framework) dans lequel vous pouvez utiliser
différents processus et techniques. Scrum met en évidence l'efficacité relative à la gestion de
votre produit et aux techniques de travail afin que vous puissiez continuellement améliorer le
produit, l’équipe et l’environnement de travail.

Le cadre Scrum est constituté d’équipes Scrum et leurs rôles, événements, artefacts et règles
associés. Chaque composante de ce cadre a un but précis et est essentielle au succès et à
l’utilisation de Scrum.

Les règles de Scrum sont les modalités qui lient rôles, événements et artefacts entre eux. Ces
règles sont décrites tout au long de ce document.

Les tactiques d'utilisation de Scrum peuvent varier. Elles ne font pas partie de ce guide.

Usages de Scrum
Scrum a été initialement développé pour la gestion et le développement de produits. Depuis le
début des années 1990, Scrum a été largement utilisé dans le monde entier pour:

1. Rechercher et identifier des marchés, des technologies et des caractéristiques produit


viables ;
2. Développer des produits et des améliorations ;
3. Publier des produits et des améliorations, jusqu’à plusieurs fois par jour ;
©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at
http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you have
read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Page | 3
4. Développer et maintenir des environnements Cloud (en ligne, sécurisé, à la demande) et
d'autres environnements d’exploitation de produits ; et,
5. Maintenir et renouveler des produits.

Scrum a été utilisé pour développer des logiciels, du matériel, des logiciels embarqués, des
réseaux de fonctions interactives, des véhicules autonomes, des écoles, des gouvernements, du
marketing, de la gestion opérationnelle des organisations et presque tout ce que nous utilisons
dans notre vie quotidienne.

Face à l’augmentation des complexités sur le plan technologique, marché et environnemental et


de leurs interactions, l'utilité de Scrum, pour faire face à cette complexité, est confirmée
quotidiennement.

Scrum s'est avéré particulièrement efficace dans le transfert itératif et incrémental de savoir.
Maintenant, Scrum est largement utilisé pour la gestion de l'organisation, de ses produits et ses
services.

L'essence de Scrum est d’avoir une petite équipe de personnes. L'équipe individuelle est plus
flexible et adaptable. Ces forces continuent à s’appliquer pour une, plusieurs, beaucoup ou des
réseaux d'équipes qui développent, publient, exploitent et maintiennent le travail et le résultat
des travaux des milliers de personnes. Elles collaborent et interagissent grâce aux architectures
sophistiquées de développement et aux environnements cibles de publication.

Lorsque les mots «développer» et «développement» sont utilisés dans le Guide Scrum, ils font
référence à des travaux complexes, tels que les types identifiés ci-dessus.

Théorie de Scrum
Scrum est fondé sur la théorie du contrôle empirique de processus, ou l'empirisme. L'empirisme
affirme que la connaissance provient de l'expérience et la prise de décisions est basée sur des
faits connus. Scrum utilise une approche itérative et incrémentale pour optimiser la prédictibilité
et le contrôle de risque.

Trois piliers soutiennent l’implémentation d’un contrôle empirique de processus: la


transparence, l'inspection et l'adaptation.

Transparence
Les aspects importants du processus doivent être visibles à tous ceux qui sont responsables des
résultats. La transparence requiert la définition d’un standard commun pour ces aspects afin que
les observateurs partagent une compréhension commune de ce qui est observé.

À titre d’exemple :

• Un langage commun faisant référence au processus doit être partagé par tous les
participants ; et,
©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at
http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you have
read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Page | 4
• Ceux qui effectuent le travail et ceux qui inspectent l’incrément résultant doivent
partager une définition commune de « Fini » (Definition of Done).

Inspection
Les utilisateurs de Scrum doivent fréquemment inspecter les artefacts Scrum et l’état
d’avancement par rapport à un Objectif de Sprint (Sprint Goal) afin de détecter les écarts
indésirables. La fréquence de ces inspections ne devrait pas gêner le travail en cours. Ces
inspections sont plus bénéfiques lorsqu'elles sont effectuées avec diligence par des inspecteurs
qualifiés sur les lieux de travail.

Adaptation
Si un inspecteur détermine qu’un ou plusieurs aspects du processus dérivent hors des limites
acceptables, et que le produit qui en résulte ne sera pas acceptable, le processus ou le matériel
utilisé par le processus doit être ajusté. Un ajustement doit être fait dès que possible afin de
minimiser le risque d’autres dérives.

Scrum prescrit quatre événements formels d'inspection et d'adaptation, tels que décrit dans la
section événements Scrum de ce document :

• Planification du Sprint (Sprint Planning)


• Mêlée Quotidienne (Daily Scrum)
• Revue de sprint (Sprint Review)
• Rétrospective de Sprint (Sprint Retrospective)

Valeurs Scrum
Lorsque les valeurs d'engagement, courage, focus, ouverture et respect sont incarnées et vécues
par l'équipe Scrum, les piliers Scrum de transparence, d'inspection et d'adaptation émergent et
consolident la confiance entre tout le monde. Les membres de l'équipe Scrum apprennent et
explorent ces valeurs au fur et à mesure qu'ils travaillent avec les événements, les rôles et les
artefacts de Scrum.

La bonne application de Scrum repose sur des personnes de plus en plus à même de vivre avec
ces cinq valeurs. Ces personnes s’engagent, personnellement, à atteindre les objectifs de l'équipe
Scrum. Les membres de l’équipe Scrum ont le courage de faire les bonnes choses et de résoudre
les problèmes difficiles. Tout le monde se concentre et se focalise sur le travail à faire durant le
Sprint et les objectifs de l'équipe Scrum. L'équipe Scrum et ses parties prenantes acceptent d'être
ouvertes sur tout le travail et les défis impliqués par l’accomplissement de ce travail. Les
membres de l’équipe Scrum se respectent mutuellement en tant que personnes compétentes et
indépendantes.

©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at
http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you have
read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Page | 5
Équipe Scrum
Une équipe Scrum comprend un Product Owner, une équipe de développement (Development
Team) et un Scrum Master. Les équipes Scrum (Scrum Teams) sont auto-organisées et
pluridisciplinaires. Les équipes auto-organisées choisissent la meilleure façon d’accomplir leur
travail, au lieu d’être dirigées par des personnes externes à l’équipe. Les équipes
pluridisciplinaires ont toutes les compétences nécessaires pour effectuer le travail sans dépendre
d’autres personnes n’appartenant pas à l’équipe. Scrum définit un modèle d’équipe optimisant la
flexibilité, la créativité et la productivité. L'équipe de Scrum s'est révélée être de plus en plus
efficace dans toutes les précédentes applications, ainsi que dans tout autre travail complexe.

Les équipes Scrum livrent des produits de manière itérative et incrémentale, maximisant ainsi les
opportunités de retour d’information. Les livraisons incrémentales d’un produit « Fini » assurent
la disponibilité d’une version potentiellement utile du produit fonctionnel.

Le Product Owner
Le Product Owner est responsable de maximiser la valeur du produit résultant du travail de
l’équipe de développement. La façon de jouer ce rôle peut varier grandement selon les
organisations, les équipes Scrum et les individus.

Le Product Owner est le seul responsable de la gestion du Backlog Produit (Product Backlog). La
gestion du Backlog Produit comprend :

• L’expression claire des éléments du Backlog produit ;


• L’ordonnancement des éléments dans le Backlog produit pour mieux réaliser les objectifs
et les missions ;
• L’optimisation de la valeur du travail effectué par l'équipe de développement ;
• L’assurance que le Backlog produit est visible, transparent et clair pour tous, et montre
sur quoi l’équipe de développement travaillera prochainement ; et,
• L’assurance que l'équipe de développement comprend adéquatement les éléments du
Backlog produit.

Le Product Owner peut lui-même accomplir les tâches susmentionnées ou les déléguer à l’équipe
de Développement. Toutefois, le Product Owner en demeure responsable.

Le Product Owner est une personne, et non un comité. Le Product Owner peut représenter les
désirs d’un comité dans le Backlog Produit, mais ceux qui veulent changer la priorité d’un
élément du Backlog Produit (Product Backlog Item PBI) doivent consulter le Product Owner.

Afin que le Product Owner réussisse dans sa démarche, toute l'organisation doit respecter ses
décisions. Les décisions du Product Owner sont visibles dans le contenu et l’ordonnancement du
Backlog produit. Nul ne peut forcer l'équipe de développement à travailler à partir d'un autre
ensemble d'exigences.
©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at
http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you have
read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Page | 6
L’équipe de Développement
L'équipe de développement se compose de professionnels qui fournissent un incrément « Fini »
potentiellement publiable (Releasable) à la fin de chaque Sprint. Un incrément « Fini » est requis
à la revue de sprint. Seuls les membres de l'équipe de développement créent l'incrément.

Les équipes de développement sont structurées et habilitées par l'organisation à s’organiser et


gérer leur propre travail. La synergie résultante optimise l'efficience et l'efficacité globale de
l'équipe de développement.
Les équipes de développement ont les caractéristiques suivantes :
• Elles sont auto-organisées. Nul (pas même le Scrum Master) n’indique à l’équipe de
développement comment transformer les éléments du Backlog Produit en incréments de
fonctionnalités potentiellement publiables ;
• Elles sont pluridisciplinaires, avec toutes les compétences nécessaires, en tant qu’équipe,
pour créer un incrément produit ;
• Scrum ne reconnaît aucun titre aux membres de l’équipe de développement,
indépendamment du travail effectué par une personne ;
• Scrum ne reconnaît pas d’équipes au sein de l’équipe de développement
indépendamment des domaines qui doivent être couverts tels que l’exécution de tests,
l’architecture, la gestion opérationnelle ou l’analyse fonctionnelle ; et,
• Les membres de l’équipe de développement peuvent détenir individuellement des
compétences et des centres d’intérêt spécifiques, mais c’est l’équipe de développement
dans son ensemble qui est tenue responsable.

Taille de l'équipe de développement


La taille optimale de l'équipe de développement doit être suffisamment petite pour rester
réactive et assez grande pour accomplir un travail significatif durant le Sprint. Le fait d’avoir une
équipe de développement de moins de trois membres, réduit l'interaction et produit de faibles
gains de productivité. Durant un Sprint, les petites équipes de développement peuvent
rencontrer des contraintes liées aux compétences ce qui les empêchent de livrer un incrément
potentiellement publiable. À l’opposé, une équipe de plus de neuf membres implique trop de
coordination. Les grandes équipes de développement engendrent trop de complexité pour qu’un
processus empirique soit utile. Les rôles de Product Owner et Scrum Master ne sont pas inclus
dans l’équipe de développement, à moins qu'ils aient également des tâches dans le Backlog
Sprint.

Le Scrum Master
Le Scrum Master est chargé de promouvoir et supporter Scrum tel que défini dans le Guide
Scrum. Les Scrum Masters remplissent leur rôle en aidant tout le monde à comprendre la théorie,
les pratiques, les règles et les valeurs de Scrum.

Le Scrum Master est un leader-serviteur de l'équipe Scrum. Le Scrum Master assiste les
personnes externes à l'équipe Scrum pour identifier quelles sont les interactions bénéfiques avec

©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at
http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you have
read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Page | 7
elle. Le Scrum Master aide tout le monde à adapter leurs interactions avec l’équipe Scrum pour
maximiser la valeur créée par cette équipe.

Le Scrum Master au service du Product Owner


Le Scrum Master sert le Product Owner de plusieurs façons, y compris :
• S'assurer que les objectifs, le périmètre et le domaine du produit sont compris par tous les
membres de l'équipe Scrum de la meilleure façon possible ;
Trouver des techniques pour une gestion efficace du Backlog produit ;
• Aider l'équipe Scrum à comprendre le besoin de clareté et concision des éléments du Backlog
produit ;
• Comprendre la planification de produits dans un contexte empirique ;
• S'assurer que le Product Owner sait comment organiser le Backlog produit pour maximiser la
valeur ;
• Comprendre et mettre en œuvre l'agilité ; et,
• Faciliter les événements Scrum, en cas de demande ou nécessité.

Le Scrum Master au service de l’équipe de Développement


Le Scrum Master sert l’équipe de Développement de plusieurs façons, y compris :
• Coacher l'équipe de développement en matière d'auto-organisation et de pluridisciplinarité ;
• Aider l'équipe de développement à créer des produits de grande valeur ;
• Supprimer les obstacles à la progression de l'équipe de développement ;
• Faciliter les événements Scrum, en cas de demande ou nécessité ; et,
• Coacher l'équipe de développement dans des environnements organisationnels où Scrum
n'est pas encore complètement adopté et compris.

Le Scrum Master au service de l’Organisation


Le Scrum Master sert l’organisation de plusieurs façons, y compris :
• Accompagner l'organisation dans son adoption de Scrum ;
• Planifier les implémentations de Scrum au sein de l'organisation ;
• Aider les employés et les parties prenantes à comprendre et adopter Scrum ainsi que le
développement empirique de produits ;
• Provoquer les changements qui augmentent la productivité de l'équipe Scrum ; et,
• Collaborer avec d'autres Scrum Masters pour accroître l'efficacité de l'application de
Scrum au sein de l'organisation.

©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at
http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you have
read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Page | 8
Les événements Scrum
Les événements prescrits sont utilisés par Scrum pour créer la régularité et minimiser le besoin
de réunions non définies par Scrum. Tous les événements sont limités dans le temps ; en boîte de
temps (time-boxés), de telle sorte que chaque événement ait une durée maximale. Une fois
qu'un Sprint commence, sa durée est fixe et ne peut être écourtée ou prolongée. Les autres
événements peuvent se terminer dès que leurs objectifs sont atteints, tout en assurant qu’il y a
eu suffisamment de temps accordé pour ces événements sans pour autant permettre le
gaspillage dans le processus.

Outre le Sprint lui-même, qui est un conteneur pour tous les autres événements, chaque
événement Scrum est une occasion formelle d'inspecter et d'adapter quelque chose. Ces
événements sont spécifiquement conçus pour permettre la transparence et l’inspection. Ne pas
inclure l’un de ces événements entraîne une transparence réduite et constitue une occasion
perdue d'inspection et d'adaptation.

Le Sprint
Le cœur de Scrum est le Sprint, qui a une boîte de temps (time-box), une durée, d'un mois ou
moins au cours de laquelle un Incrément Produit « Fini » fonctionnel et potentiellement publiable
est créé. Les sprints ont une durée cohérente durant la phase de développement. Un nouveau
Sprint commence immédiatement après la conclusion du Sprint précédent.

Les Sprints contiennent et consistent en une planification du Sprint (Sprint Planning), des mêlées
quotidiennes (Daily Scrums), des activités de développement, une revue de sprint (Sprint Review)
et une rétrospective de Sprint (Sprint Retrospective).

Pendant le Sprint:

• L’objectif du sprint est fixe ; les changements qui le remettent en cause ne sont donc pas
permis ;
• Les objectifs de qualité sont maintenus ; ils ne sont jamais revus à la baisse ; et,
• Le périmètre peut être clarifié et renégocié entre le Product Owner et l’équipe de
développement selon ce que l’équipe Scrum apprend.

Chaque sprint peut être considéré comme un projet n'ayant qu'un horizon d'un mois. À l’instar
d’un projet, un Sprint est utilisé pour accomplir quelque chose. Chaque Sprint a un objectif de ce
qui doit être construit, une conception (design) et un plan flexible qui guidera la construction, le
travail lui même et l’incrément produit résultant.

Les sprints sont limités à un mois calendaire. Lorsque l'échéance d'un Sprint est trop longue, la
définition de ce qui est en cours de construction peut changer, la complexité peut augmenter et
le risque peut s'accroître. Les sprints permettent la prédictibilité en assurant l'inspection et
l'adaptation de la progression vers un objectif du Sprint (Sprint Goal) au moins tous les mois
calendaires. Les sprints limitent également le risque à un coût maximal d’un mois calendaire.
©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at
http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you have
read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Page | 9
Annulation d'un Sprint
Un Sprint peut être annulé avant son échéance. Seul le Product Owner a le pouvoir d'annuler le
Sprint, bien qu'il ou elle puisse le faire sous l'influence des parties prenantes, de l'équipe de
développement ou du Scrum Master.

Un Sprint serait annulé si l'objectif du Sprint devient obsolète. Cela pourrait se produire si
l'organisation change de direction ou si les conditions de marché ou celles technologiques
changent. En général, un Sprint devrait être annulé s'il n'a plus de sens compte tenu des
circonstances. Mais en raison de la courte durée de Sprints, l'annulation est rarement justifiable.

Lorsqu'un Sprint est annulé, tous les éléments achevés et « Finis » du Backlog produit (PBIs :
Product Backlog Items) sont examinés. Généralement, si une partie du travail est potentiellement
publiable, le Product Owner l'accepte. Tous les éléments du Backlog produit incomplets sont
estimés à nouveau et remis au Backlog produit. Le travail effectué en vue de les compléter se
déprécie rapidement et doit être fréquemment estimé à nouveau.

Les annulations Sprint consomment des ressources, car tout le monde se regroupe dans une
autre réunion de planification du Sprint (Sprint Planning) pour commencer un autre Sprint. Les
annulations Sprint sont souvent bouleversantes pour l'équipe Scrum et sont très peu fréquentes.

Planification du Sprint
Le travail à effectuer durant un Sprint est défini durant la réunion de Planification du Sprint
(Sprint Planning). Ce plan est créé de manière collaborative par tous les membres de l'équipe
Scrum. La réunion de planification du Sprint dure au maximum huit heures pour un Sprint d'un
mois. Pour les sprints plus courts, l'événement est généralement plus court. Le Scrum Master
veille à ce que l’événement ait lieu et que les participants en comprennent le but. Le Scrum
Master apprend à l'équipe Scrum à le garder dans la boîte de temps (time-box).

La Planification du Sprint répond aux questions suivantes :


• Que peut-on livrer comme incrément résultant du Sprint à venir ?
• Comment sera effectué le travail à livrer et nécessaire pour achever l'Incrément?

Thème Un: Que peut-on faire de ce Sprint ?


L'équipe de développement travaille à prévoir les fonctionnalités qui seront développées
pendant le Sprint. Le Product Owner discute de l’objectif que le Sprint devrait concrétiser et des
éléments du Backlog produit qui, s’ils sont complétés durant le Sprint, pourraient permettre
d’atteindre l'objectif du Sprint. Toute l'équipe Scrum collabore pour comprendre le travail requis
durant le Sprint.

©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at
http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you have
read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Page | 10
Les éléments nécessaires pour le démarrage de la réunion de Planification du Sprint sont le
Backlog produit, le dernier incrément produit, la capacité projetée par l'équipe de
développement pendant le Sprint et les performances passées de l'équipe de développement. Le
nombre d’éléments sélectionnés du Backlog produit pour le Sprint revient uniquement à l'équipe
de développement. Seule l'équipe de développement peut évaluer ce qu'elle peut accomplir
durant le Sprint à venir.

Durant la planification du Sprint (Sprint Planning), l’équipe Scrum détermine aussi l’objectif du
Sprint (Sprint Goal). Il s’agit d’un objectif qui sera atteint durant le sprint grâçe à
l’implémentation des éléments du backlog produit choisis, et qui fournit à l’équipe de
développement la raison pour laquelle elle développe l’incrément.

Thème Deux: Comment le travail choisi sera-t-il terminé ?


Une fois l’objectif du sprint fixé et les éléments du Backlog Produit choisis, l’équipe de
développement planifie le travail pour transformer cette fonctionnalité en un incrément produit
«Fini» durant le Sprint. Les éléments du Backlog produit sélectionnés pour ce sprint plus le plan
de travail pour les livrer est appelé le Backlog Sprint (Sprint Backlog).

L'équipe de développement commence généralement par la conception du système et du travail


nécessaire afin de transformer le Backlog produit en un incrément fonctionnel du produit. La
taille ou l’effort estimé du travail peut varier. Cependant, lors de la réunion de planification,
l’équipe de développement doit envisager suffisamment de travail pour qu’elle ait une bonne
idée de ce qu'elle pense pouvoir accomplir durant le Sprint. Avant la fin de la réunion, l’équipe de
développement décompose le travail prévu pour les premiers jours du Sprint, souvent jusqu'à
une granularité d'une journée ou moins. L'équipe de développement s'auto-organise pour
entreprendre le travail consigné au Backlog Sprint, à la fois lors de la réunion de Planification du
Sprint et quand cela est nécessaire tout au long du Sprint.

Le Product Owner peut aider à clarifier les éléments du Backlog Produit choisis et à faire des
compromis. Si l’équipe de développement détermine qu’elle a trop ou pas assez de travail, elle
peut renégocier les éléments du Backlog Produit choisis avec le Product Owner. L’équipe de
développement peut également inviter d’autres personnes à la réunion pour recevoir des
conseils techniques ou liés au domaine.

À la fin de la planification du Sprint, l’équipe de développement devrait être en mesure


d’expliquer au Product Owner et au Scrum Master comment elle entend s’organiser pour réaliser
l’objectif du Sprint et créer l’incrément prévu.

Objectif du Sprint
L’objectif du Sprint (Sprint Goal) est un but fixé pour le Sprint et peut être réalisé par
l’implémentation d’une partie du Backlog Produit. Il fournit à l’équipe de développement la
raison pour laquelle elle construit l’incrément du produit. Il est défini lors de la réunion de
planification du Sprint (Sprint Planning). L’objectif du Sprint fournit à l’équipe de développement
une certaine flexibilité quant à la fonctionnalité implémentée durant le Sprint. Les éléments du
©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at
http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you have
read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Page | 11
Backlog Produit sélectionnés offrent une fonction cohérente, ce qui peut faire office d’objectif du
Sprint. Par ailleurs, l’objectif du Sprint peut être une autre source de cohérence poussant l’équipe
de développement à travailler ensemble au lieu d’entreprendre des initiatives distinctes.

Tout en effectuant son travail, l’équipe de développement garde à l’esprit l’objectif du Sprint.
Afin d’atteindre l’objectif du Sprint, l’équipe implémente les fonctionnalités et les technologies
nécessaires. Si le travail se révèle différent de ce qui a été prévu, l’équipe de développement
collabore avec le Product Owner et négocie le périmètre du Backlog Sprint durant le sprint.

Daily Scrum
La mêlée quotidienne (Daily Scrum) est un événement de 15 minutes (time-boxé) destiné à
l'équipe de développement. La mêlée quotidienne est tenue tous les jours du Sprint. L’équipe de
développement planifie le travail pour les prochaines 24 heures. Cela optimise la collaboration et
la performance de l'équipe tout en inspectant le travail depuis la dernière mêlée quotidienne et
envisageant le travail restant durant le Sprint. La mêlée quotidienne est tenue à la même heure
et au même lieu chaque jour pour réduire la complexité.

L'équipe de développement utilise la mêlée quotidienne pour inspecter son avancement vers
l'objectif du Sprint et comment cet avancement tend à l'achèvement des travaux prévus dans le
Backlog Sprint. La mêlée quotidienne optimise la probabilité que l'équipe de développement
atteigne l'objectif du Sprint. Chaque jour, l'équipe de développement doit comprendre comment
elle entend travailler ensemble en tant qu'équipe auto-organisée pour atteindre l'objectif du
Sprint et créer l'Incrément prévu à la fin du Sprint.

La structure de la réunion est définie par l'équipe de développement et peut être conduite de
différentes manières si elle se concentre sur la progression vers l'objectif du Sprint. Certaines
équipes de développement utiliseront les questions, d'autres seront plus basées sur la discussion.
Voici un exemple de ce qui pourrait être utilisé :

• Qu'est-ce que j'ai fait hier qui a aidé l'équipe de développement à atteindre l'objectif du
Sprint ?
• Que ferai-je aujourd'hui pour aider l'équipe de développement à atteindre l'objectif du
Sprint ?
• Est-ce que je vois des obstacles qui m'empêchent ou empêchent l'équipe de
développement de respecter l'objectif du Sprint ?

L'équipe de développement ou les membres de l'équipe se rencontrent souvent immédiatement


après la mêlée quotidienne pour des discussions détaillées ou pour adapter ou planifier à
nouveau le reste du travail du Sprint.

©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at
http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you have
read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Page | 12
Le Scrum Master s’assure que la mêlée quotidienne a lieu, mais c’est l’équipe de développement
qui est responsable de son déroulement. Le Scrum Master apprend à l’équipe de développement
à limiter la mêlée quotidienne à 15 minutes.

La mêlée quotidienne est une réunion interne pour l'équipe de développement. Si d'autres
personnes sont présentes, le Scrum Master s'assure qu'elles ne perturbent pas la réunion.

Les mêlées quotidiennes améliorent la communication, éliminent les autres réunions, identifient
les obstacles à éliminer qui perturbent le développement, mettent en avant et encouragent la
prise de décision rapide tout en améliorant le niveau de savoir au sein de l’équipe de
développement. Il s’agit d’un point clé d’inspection et d’adaptation.

Revue de Sprint
Une revue de Sprint (Sprint Review) est tenue à la fin du Sprint pour inspecter l’incrément réalisé
et adapter le Backlog Produit si nécessaire. Pendant la revue de Sprint, l'équipe Scrum et les
parties prenantes échangent sur ce qui a été fait durant le Sprint.

Sur la base de cela et de tout changement du Backlog Produit durant le sprint, les participants
collaborent sur les prochains travaux qui pourraient être faits pour optimiser la valeur. Cette
réunion se veut informelle, pas une réunion de pilotage, et la présentation de l'incrément est
destinée à susciter les réactions et à favoriser la collaboration.

Il s'agit au maximum d'une réunion de quatre heures pour les sprints d'un mois. Pour les sprints
plus courts, l'événement est généralement plus court. Le Scrum Master s’assure que l’événement
ait lieu et que les participants en comprennent son but. Le Scrum Master apprend à tous ceux qui
y sont impliqués à le garder dans la boîte de temps (time-boxé).

La Revue de sprint comprend les éléments suivants :


• Les participants incluent l'équipe Scrum et les principales parties prenantes invitées par
le Product Owner ;
• Le Product Owner indique quels éléments du Backlog Produit ont été « Finis » et ceux qui
n'ont pas été « Finis » ;
• L’équipe de développement discute de ce qui s’est bien passé pendant le Sprint, quels
problèmes ont été rencontrés, et comment ces problèmes ont été résolus ;
• L'équipe de développement démontre le travail « Fini » et répond aux questions sur
l'incrément ;
• Le Product Owner discute de l’état actuel du Backlog Produit tel qu'il est. Il ou elle
projette les dates prévisionnelles et celles de livraison en fonction des progressions
réalisées à ce jour (si nécessaire) ;

©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at
http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you have
read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Page | 13
• L'ensemble du groupe convient de ce qu'il faut faire pour la suite, de sorte que la revue
de sprint fournisse une contribution précieuse à la prochaine réunion de Planification du
Sprint ;
• La revue de la façon dont les conditions de marché ou un usage potentiel du produit
pourrait avoir dicté ce qu’il conviendrait mieux de faire dorénavant ; et,
• La revue des délais, budget, fonctionnalités potentielles et conditions de marché pour les
prochaines versions prévues de la fonctionnalité du produit.

Le résultat de la revue de sprint est un Backlog Produit révisé qui définit les éléments probables
pour le prochain Sprint. Le Backlog Produit peut également être globalement ajusté pour
répondre aux nouvelles opportunités d’affaires.

Rétrospective de Sprint
La rétrospective de Sprint (Sprint Retrospective) est une opportunité pour l'équipe Scrum de
s’auto-inspecter et de créer un plan d'améliorations à adopter au cours du prochain Sprint.

La rétrospective de Sprint se produit après la revue de sprint et avant la prochaine réunion de


planification du Sprint. Il s'agit au maximum d'une réunion de trois heures pour les Sprints d'un
mois. Pour les sprints plus courts, l'événement est généralement plus court. Le Scrum Master
s’assure que l’événement ait lieu et que les participants en comprennent son but.

Le Scrum Master s'assure que la réunion est positive et productive. Le Scrum Master apprend à
tous ceux qui y sont impliqués à la garder dans la boîte de temps (time-box). Le Scrum Master
participe en tant que membre de l’équipe Scrum et y amène le point de vue du responsable du
processus Scrum.

Le but de la rétrospective de Sprint est de :


• Inspecter la manière dont le dernier Sprint s’est déroulé en ce qui concerne les
personnes, les relations, les processus et les outils ;
• Identifier et ordonner les principaux éléments qui ont bien fonctionné et des
améliorations potentielles ; et,
• Créer un plan pour mettre en œuvre des améliorations sur la façon dont l'équipe Scrum
fait son travail.

Le Scrum Master encourage l'équipe Scrum à améliorer, dans le cadre de travail Scrum, son
processus de développement et ses pratiques afin de les rendre plus efficaces et agréables pour
le prochain Sprint. Lors de chaque rétrospective de Sprint, l'équipe Scrum propose des moyens
adéquats pour accroître la qualité du produit tout en améliorant les processus de travail ou
adaptant la définition de « Fini », quand cela est nécessaire et non conflictuel avec les normes du
produit ou celles de l'organisation.

©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at
http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you have
read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Page | 14
À la fin de la rétrospective de Sprint, l'équipe Scrum devrait avoir identifié les améliorations
qu'elle mettra en œuvre dans le prochain Sprint. La mise en œuvre de ces améliorations dans le
prochain Sprint est l'adaptation à l'inspection de l'équipe Scrum elle-même. Bien que des
améliorations puissent être mises en œuvre à tout moment, la rétrospective de Sprint offre une
opportunité formelle d'inspection et d'adaptation.

Les artefacts de Scrum


Les artefacts de Scrum représentent soit du travail, soit de la valeur fournissant ainsi de la
transparence et des opportunités pour l'inspection et d'adaptation. Les artefacts définis par
Scrum sont spécialement conçus pour maximiser la transparence d’informations essentielles afin
que chacun ait la même compréhension de l'artefact.

Backlog Produit
Le Backlog Produit est une liste ordonnée de tous les éléments identifiés comme nécessaires au
produit. Il constitue l’unique source d'exigences pour tout changement à apporter au produit. Le
Product Owner est responsable du Backlog produit, y compris son contenu, sa disponibilité et son
ordonnancement.

Un Backlog Produit n'est jamais complet. Ses toutes premières moutures ne font qu’esquisser les
besoins tels qu’initialement connus et compris. Le Backlog Produit évolue au fur et à mesure que
le produit et le contexte dans lequel il sera utilisé évoluent. Le Backlog Produit est dynamique ; il
change constamment pour identifier ce que le produit requiert pour être approprié, compétitif et
utile. Si un produit existe, son Backlog Produit existe.

Le Backlog Produit liste toutes les fonctionnalités, les fonctions, les exigences, les améliorations
et les corrections qui constituent des modifications à apporter au produit dans les versions
futures. Les éléments du backlog produit se composent d'une description, d'un ordre, d'une
estimation et d'une valeur. Les éléments du backlog produit incluent souvent des descriptions du
test qui prouveront leur complétude lorsqu’ils sont « Finis ».

À mesure qu’un produit est utilisé, que sa valeur augmente et que l’on commence à recevoir des
retours sur son utilisation, le Backlog produit devient une liste plus vaste et plus exhaustive. Les
exigences ne cessent jamais de changer, de sorte qu'un Backlog produit est un artefact vivant.
Les changements de besoins de l'organisation, des conditions de marché ou de la technologie
peuvent entraîner des changements dans le Backlog produit.

Il arrive souvent que plusieurs équipes Scrum travaillent sur le même produit. Un seul Backlog
Produit est utilisé pour décrire le travail à faire sur ce produit. On peut alors ajouter un attribut
aux éléments du Backlog Produit pour les regrouper.

©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at
http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you have
read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Page | 15
Le raffinement du backlog de produit (Product Backlog Refinement) consiste en l’ajout de détails,
d’estimations et de l’ordonnancement des éléments du Backlog Produit. Il s’agit d’une activité
régulière dans laquelle le Product Owner et l’équipe de développement collaborent pour
détailler les éléments du Backlog Produit. Durant le raffinement du Backlog Produit, les éléments
sont revisités et révisés. L’équipe Scrum décide comment et quand le raffinement est effectué. Le
raffinement n’occupe généralement pas plus de 10% de la capacité de l’équipe de
développement. Toutefois, les éléments du Backlog Produit peuvent être modifiés à n’importe
quel moment par le Product Owner ou à sa discrétion.

Les premiers éléments du Backlog Produit sont généralement plus détaillés que les suivants. Leur
estimation est plus précise grâçe à une plus grande clarté et un niveau de détail accru. Les
éléments qui sont placés plus loin dans le Backlog Produit sont moins détaillés. Les éléments qui
occuperont l’équipe de développement durant le prochain Sprint sont affinés au point que
n’importe lequel peut être raisonnablement « Fini » dans un Sprint. Ces éléments sont réputés
« Prêts » pour leur sélection durant la planification du Sprint. Les éléments du Backlog Produit
acquièrent ce degré de transparence grâce aux activités de raffinements décrites plus haut.

L'équipe de développement est responsable de toutes les estimations. Le Product Owner peut
influencer l'équipe de développement en l’aidant dans sa compréhension et le choix des
compromis, mais les personnes qui effectueront le travail ont le mot final sur les estimations.

Suivi de la progression vers les objectifs


À tout moment, la somme de travail restant pour atteindre un objectif de développement peut
être calculée. Le Product Owner suit l’évolution de la somme de travail restant au moins à
chaque revue de sprint. Il compare cette quantité à la somme de travail restant lors des revues
des Sprints précédents afin d’évaluer la progression vers l’achèvement du travail prévu dans les
délais voulus par l'objectif. Cette information est rendue transparente pour toutes les parties
prenantes.
Diverses pratiques de projections des tendances telles que les « burn-downs », les « burn- ups »
ou les « cummulative flow » ont été utilisées afin de prévoir la progression. Ces pratiques ont
prouvé leur utilité. Toutefois, elles ne remplacent pas l’importance de l’empirisme. Dans les
environnements complexes, ce qui se passera est inconnu. Seul ce qui s’est déjà passé peut être
utilisé pour la prise de décision prévisionnelle.

Backlog Sprint
Le Backlog Sprint est l’ensemble des éléments sélectionnés pour le Sprint plus un plan pour livrer
l’incrément du produit et réaliser l’objectif du Sprint. Le Backlog Sprint est une prévision que
l’équipe de développement fait de la fonctionnalité qui sera présente dans le prochain incrément
et le travail nécessaire pour livrer cette fonctionnalité dans un incrément « Fini ».

Le Backlog Sprint rend visible tout le travail que l'équipe de développement identifie comme
nécessaire pour atteindre l'objectif du Sprint. Pour assurer une amélioration continue, il

©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at
http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you have
read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Page | 16
comprend au moins une amélioration de processus, hautement prioritaire, identifiée lors de la
précédente réunion de rétrospective de Sprint.

Le Backlog Sprint est un plan suffisamment détaillé pour que la progression soit compréhensible
lors de la mêlée quotidienne. L’équipe de développement modifie le Backlog Sprint tout au long
du Sprint, et le Backlog Sprint émerge durant le Sprint. Cette émergence a lieu alors même que
l’équipe de développement exécute le plan et découvre le travail nécessaire pour atteindre
l’objectif du Sprint.

À mesure que du nouveau travail est nécessaire, l’équipe de développement l’ajoute au Backlog
Sprint. Lorsque le travail est effectué ou complété, les estimations du travail restant sont mises à
jour. Lorsque des éléments du plan sont jugés inutiles, ils sont écartés. Seule l’équipe de
développement peut changer son Backlog Sprint durant un Sprint. Le Backlog Sprint est une vue
en temps-réel et très visible du travail que l’équipe de développement prévoit d’accomplir durant
le Sprint et il appartient uniquement à l’équipe de développement.

Suivi de la progression du Sprint


À n’importe quel moment d’un sprint, la somme totale du travail restant dans le Backlog Sprint
peut être calculée. L’équipe de développement fait le suivi de cette somme de travail restant au
moins à chaque mêlée quotidienne pour évaluer la probabilité d’atteindre l’objectif du Sprint. En
effectuant le suivi du travail restant tout au long du sprint, l’équipe de développement peut gérer
son avancement.

Incrément
L'incrément est constitué des éléments du Backlog produit « Finis » pendant le sprint ainsi que de
la valeur cumulative des incréments livrés dans les sprints précédents. À la fin d’un Sprint, le
nouvel incrément doit être « Fini », ce qui implique qu’il doit être dans un état publiable et qu’il
correspond à la définition de « Fini » (Definition of Done) de l’équipe de développement. Un
incrément est la partie d’un travail fait, qui prend en charge l'empirisme, et vérifiable à la fin du
Sprint. L'incrément est un pas vers une vision ou un but. L’incrément doit être dans un état
publiable, sans égard à la décision du Product Owner de le publier ou non.

Artefact de Transparence
Scrum repose sur la transparence. Les décisions d’optimiser la valeur et contrôler le risque sont
prises en se basant sur l’état perçu des artefacts. Dans la mesure où la transparence est
complète, ces décisions ont une base solide. Dans la mesure où les artefacts ne sont pas
totalement transparents, ces décisions peuvent être faussées, la valeur peut diminuer et le risque
peut augmenter.

Le Scrum Master doit travailler avec le Product Owner, l’équipe de développement et les autres
parties impliquées pour comprendre si les artefacts sont complètement transparents. Il existe

©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at
http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you have
read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Page | 17
des pratiques pour faire face à une transparence incomplete ; le Scrum Master doit aider tout le
monde à appliquer les pratiques les plus appropriées en l’absence d’une transparence complète.
Un Scrum Master peut détecter une transparence incomplète en inspectant les artefacts, en
identifiant certains usages récurrents, en écoutant attentivement ce qui est dit et en décelant les
différences entre les résultats escomptés et réels.

La responsabilité du Scrum Master consiste à travailler avec l’équipe Scrum et l’organisation afin
d’accroître la transparence des artefacts. Ce travail implique généralement l’apprentissage, la
persuasion et le changement. La transparence ne se produit pas du jour au lendemain, mais est
plutôt un chemin.

Définition de « Fini »
Lorsqu'un élément du Backlog produit ou un Incrément est décrit comme « Fini », tout le monde
doit comprendre ce que « Fini » signifie. Bien que cela puisse varier considérablement d’une
équipe Scrum à une autre, les membres doivent avoir une compréhension commune de ce que
signifie que le travail soit complet, afin d'assurer la transparence. Il s'agit de la définition de
« Fini » (Definition of Done) pour l'équipe Scrum. Celle-ci est utilisée pour évaluer si le travail est
terminé dans un incrément produit.

La même définition guide l'équipe de développement en sachant combien d'éléments de Backlog


produit elle peut choisir au cours de la Planification du Sprint. L’objectif de chaque Sprint est de
fournir des Incréments de fonctionnalités potentiellement publiables qui adhèrent à la définition
de « Fini » actuelle de l’équipe Scrum.

Les équipes de développement fournissent un incrément de la fonctionnalité du produit à chaque


Sprint. Cet incrément est publiable, de telle sorte qu'un Product Owner peut choisir de le publier
immédiatement. Si la définition de « Fini » d’un incrément fait partie des conventions, standards
ou lignes directrices de l’organisation de développement, toutes les équipes doivent au minimum
la respecter.
Si la définition de « Fini » n'est pas une convention de l'organisation de développement, l'équipe
de développement de l'équipe Scrum doit établir une définition de « Fini » appropriée pour le
produit. S'il existe plusieurs équipes Scrum travaillant sur la livraison d’un système ou un produit,
les équipes de développement de toutes les équipes Scrum doivent mutuellement définir une
définition de « Fini ».

Chaque Incrément est ajouté à tous les Incréments précédents et testé de manière approfondie,
tout en veillant à ce que tous les Incréments fonctionnent ensemble.
Au fur et à mesure que les équipes de Scrum mûrissent, on s'attend à ce que leurs définitions de
« Fini » se développent pour inclure des critères plus stricts pour une meilleure qualité.
L’utilisation d’une nouvelle définition de « Fini » peut révéler le travail à faire dans les incréments
précédemment « Finis ». Tout produit ou système devrait avoir une définition de « Fini » qui est
une norme pour tout travail effectué.
©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at
http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you have
read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Page | 18
Note de Fin
Scrum est gratuit et offert dans ce guide. Les rôles, les événements, les artefacts et les règles de
Scrum sont immuables et, bien que la mise en œuvre de certaines parties de Scrum soit possible,
le résultat n'est pas Scrum. Scrum n'existe que dans sa totalité et fonctionne bien comme un
conteneur pour d'autres techniques, méthodologies et pratiques.

Remerciements
Personnes
Parmi les milliers de personnes qui ont contribué à Scrum, nous devrions distinguer ceux qui ont
joué un rôle déterminant dès le départ: Jeff Sutherland a travaillé avec Jeff McKenna et John
Scumniotales, et Ken Schwaber a travaillé avec Mike Smith et Chris Martin, et qui ont tous
travaillé ensemble. Beaucoup d'autres ont contribué dans les années suivantes et sans leur aide,
Scrum ne serait pas aussi affiné qu'il l’est aujourd'hui.

Historique
Ken Schwaber et Jeff Sutherland ont travaillé sur Scrum jusqu'en 1995 lorsqu'ils ont co-présenté
Scrum à la conférence OOPSLA en 1995. Cette présentation a essentiellement documenté
l'apprentissage que Ken et Jeff ont acquis au cours des dernières années et rendu public la
première définition formelle de Scrum.

L'histoire de Scrum est déjà considérée comme longue. Pour honorer les premiers endroits où il a
été essayé et affiné, nous reconnaissons Individual, Inc., Fidelity Investments et IDX (maintenant
GE Medical).

Le Guide Scrum documente Scrum tel que développé, évolué et soutenu pendant plus de 20 ans
par Jeff Sutherland et Ken Schwaber. D'autres sources vous fournissent des modèles, des
processus et des idées qui complètent le cadre Scrum. Ceux-ci optimisent la productivité, la
valeur, la créativité et la satisfaction par rapport aux résultats.

Traduction
Ce guide a été traduit de la version originale anglaise, fournie par Ken Schwaber et Jeff
Sutherland. L’équipe de traduction en langue Française est gérée par Kamel Kaouech.

L’équipe de traduction tient à remercier les contributeurs à la traduction des anciennes


versions du Guide Scrum. Les traducteurs du présent guide, la version 2017 du Guide
Scrum, désirent aussi remercier spécialement Mariem Sassi, Tristan Libersat, Christian
Lapointe, Laurent Reese et François Masselot pour la relecture. Information Importante :
L'utilisation du genre masculin a été adoptée afin de faciliter la lecture et n'a aucune
intention discriminatoire.

©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at
http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you have
read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Page | 19
Changements entre les versions 2016 et 2017 du Guide Scrum
1. Ajout de section pour les Usages de Scrum:
Scrum a été initialement développé pour la gestion et le développement de produits. Depuis le
début des années 1990, Scrum a été largement utilisé dans le monde entier pour:

1. Rechercher et identifier des marchés, des technologies et des caractéristiques produit


viables ;
2. Développer des produits et des améliorations ;
3. Publier des produits et des améliorations, jusqu’à plusieurs fois par jour ;
4. Développer et maintenir des environnements Cloud (en ligne, sécurisé, à la demande) et
d'autres environnements d’exploitation de produits ; et,
5. Maintenir et renouveler des produits.

Scrum a été utilisé pour développer des logiciels, du matériel, des logiciels embarqués, des
réseaux de fonctions interactives, des véhicules autonomes, des écoles, des gouvernements, du
marketing, de la gestion opérationnelle des organisations et presque tout ce que nous utilisons
dans notre vie quotidienne.

Face à l’augmentation des complexités sur le plan technologique, marché et environnemental et


de leurs interactions, l'utilité de Scrum, pour faire face à cette complexité, est confirmée
quotidiennement.

Scrum s'est avéré particulièrement efficace dans le transfert itératif et incrémental de savoir.
Maintenant, Scrum est largement utilisé pour la gestion de l'organisation, de ses produits et ses
services.

L'essence de Scrum est d’avoir une petite équipe de personnes. L'équipe individuelle est plus
flexible et adaptable. Ces forces continuent à s’appliquer pour une, plusieurs, beaucoup ou des
réseaux d'équipes qui développent, publient, exploitent et maintiennent le travail et le résultat
des travaux des milliers de personnes. Elles collaborent et interagissent grâce aux architectures
sophistiquées de développement et aux environnements cibles de publication.

Lorsque les mots «développer» et «développement» sont utilisés dans le Guide Scrum, ils font
référence à des travaux complexes, tels que les types identifiés ci-dessus.

2. Changement du texte dans la Section Scrum Master pour fournir une


meilleure clarification du rôle. Le texte est maintenant:
Le Scrum Master est chargé de promouvoir et supporter Scrum tel que défini dans le Guide
Scrum. Les Scrum Masters remplissent leur rôle en aidant tout le monde à comprendre la théorie,
les pratiques, les règles et les valeurs de Scrum.

Le Scrum Master est un leader-serviteur de l'équipe Scrum. Le Scrum Master assiste les
personnes externes à l'équipe Scrum pour identifier quelles sont les interactions bénéfiques avec
©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at
http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you have
read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Page | 20
elle. Le Scrum Master aide tout le monde à adapter leurs interactions avec l’équipe Scrum pour
maximiser la valeur créée par cette équipe.

3. Ajout à la section Scrum Master au Service du Product Owner


S'assurer que les objectifs, le périmètre et le domaine du produit sont compris par tous les
membres de l'équipe Scrum de la meilleure façon possible.

4. Mise à jour du premier paragraphe de la section Daily Scrum:


La mêlée quotidienne (Daily Scrum) est un événement de 15 minutes (time-boxé) destiné à
l'équipe de développement. La mêlée quotidienne est tenue tous les jours du Sprint. L’équipe de
développement planifie le travail pour les prochaines 24 heures. Cela optimise la collaboration et
la performance de l'équipe tout en inspectant le travail depuis la dernière mêlée quotidienne et
envisageant le travail restant durant le Sprint. La mêlée quotidienne est tenue à la même heure
et au même lieu chaque jour pour réduire la complexité.

5. Mise à jour de la section Daily Scrum pour fournir une meilleure


clarification du rôle. Le texte inclus est:
La structure de la réunion est définie par l'équipe de développement et peut être conduite de
différentes manières si elle se concentre sur la progression vers l'objectif du Sprint. Certaines
équipes de développement utiliseront les questions, d'autres seront plus basées sur la discussion.
Voici un exemple de ce qui pourrait être utilisé :

• Qu'est-ce que j'ai fait hier qui a aidé l'équipe de développement à atteindre l'objectif du
Sprint ?
• Que ferai-je aujourd'hui pour aider l'équipe de développement à atteindre l'objectif du
Sprint ?
• Est-ce que je vois des obstacles qui m'empêchent ou empêchent l'équipe de
développement de respecter l'objectif du Sprint ?

6. Ajout de la clarification à la notion du time-boxé


L’emploi du terme « au maximum » a pour but d’éliminer toutes questions relatives aux
événements qui doivent avoir une durée certaine d’une durée maximale allouée.

7. Ajout à la section Sprint Backlog:


Pour assurer une amélioration continue, il comprend au moins une amélioration de processus,
hautement prioritaire, identifiée lors de la précédente réunion rétrospective.

8. Ajout de la clarification à la section Incrément:


Un incrément est la partie d’un travail fait, qui prend en charge l'empirisme, et vérifiable à la fin
du Sprint. L'incrément est un pas vers une vision ou un but.

©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at
http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you have
read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Page | 21
Préparer la
certification
Certified Scrum
Master
avec Kelley Oconnell

Fichiers d’exercice
Ces fichiers d’exercice sont un complément au cours « Préparer la certification
Certified Scrum Master » de https://www.linkedin.com/learning/.
Principes agiles
1. Notre plus 2. Accueillez 3. Livrez fréquem- 4. Les utilisateurs
haute positivement les ment un logiciel ou leurs repré-
changements de opérationnel avec sentants et les
priorité est de sa- besoins, même des cycles de développeurs
tisfaire le client en tard dans le pro- quelques se- doivent travailler
Client livrant rapidement jet. Les processus maines à quelques ensemble quoti-
et régulièrement agiles exploitent mois et une pré- diennement tout
des fonctionna- le changement férence pour les au long du projet.
lités à grande pour donner un plus courts.
valeur ajoutée. avantage compé-
titif au client.
5. Réalisez les 6. Les processus 7. Un logiciel 8. La méthode
projets agiles encou- opérationnel est la la plus simple et
avec des per- ragent un rythme principale mesure la plus efficace
sonnes motivées. de développe- d’avancement. pour transmettre
Fournissez-leur ment soutenable. de l’information à
l’environnement Ensemble, les l’équipe de déve-
et le soutien dont commanditaires, loppement et à
Équipe
elles ont besoin les développeurs l’intérieur de celle-
et faites-leur et les utilisa- ci est le dialogue
confiance pour teurs devraient en face à face.
atteindre les ob- être capables de
jectifs fixés. maintenir indéfi-
niment un rythme
constant.
9. Une attention 10. La simplicité 11. Les meilleures 12. À intervalles
continue à l’excel- – l’art architectures, réguliers, l’équipe
lence technique de minimiser la spécifications et réfléchit aux
Produit et à une bonne quantité de travail conceptions émer- moyens de de-
et pro- conception ren- inutile – est essen- gent d’équipes venir plus effi-
cessus force l’agilité. tielle. auto-organisées. cace, puis règle
et modifie son
comportement en
conséquence.

Préparer la certification Certified Scrum Master


Principes agiles 1 sur 1
Préparer la
certification
Certified Scrum
Master
avec Kelley Oconnell

Fichiers d’exercice
Ces fichiers d’exercice sont un complément au cours « Préparer la certification
Certified Scrum Master » de https://www.linkedin.com/learning/.
Manifeste agile
Nous découvrons comment mieux développer des logiciels par la pratique en aidant les
autres à le faire. Ces expériences nous ont amenés à valoriser :
• Les individus et leurs interactions plus que les processus et les outils

• Des logiciels opérationnels plus qu’une documentation exhaustive

• La collaboration avec les clients plus que la négociation contractuelle

• L’adaptation au changement plus que le suivi d’un plan

Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.

Préparer la certification Certified Scrum Master


Manifeste agile 1 sur 1
Préparer la
certification
Certified Scrum
Master
avec Kelley Oconnell

Fichiers d’exercice
Ces fichiers d’exercice sont un complément au cours « Préparer la certification
Certified Scrum Master » de https://www.linkedin.com/learning/.
Guide de l’évaluation de sprint
Participants : équipe Scrum, ressources partagées comprises, et parties prenantes

Durée : de 1 à 4 heures, selon la durée du sprint

Fréquence : une fois par sprint, en général le dernier jour (c’est l’avant-dernier évènement
du sprint)

Objectif : inspecter l’incrément produit de façon collaborative et adapter le backlog produit

Structure :
L’évaluation de sprint est censée être une collaboration informelle concernant l’incrément
produit en cours et la mise à jour du backlog produit avec les informations (émanant des
parties prenantes) qui sont susceptibles d’influer sur son contenu.

Sujets abordés :
• Le PO fournit un aperçu de l’objectif du sprint ainsi que des EBP qui ont été sé-
lectionnés.
• Les développeurs font la démonstration de l’incrément produit et répondent aux
questions.
• Le PO partage le backlog produit et la projection de son achèvement en fonction
de l’avancement actuel.
• Le PO facilite un dialogue ouvert avec les parties prenantes et note le feedback
ainsi que les informations extérieures qui peuvent aider l’équipe Scrum.
• Le PO ajoute le feedback approprié au backlog.

Le Scrum Master veille à ce que cet évènement ait lieu et soit bien facilité. Le Scrum Master
s’assure également que la boîte de temps est respectée.

Préparer la certification Certified Scrum Master


Guide de l’évaluation de sprint 1 sur 1
Préparer la
certification
Certified Scrum
Master
avec Kelley Oconnell

Fichiers d’exercice
Ces fichiers d’exercice sont un complément au cours « Préparer la certification
Certified Scrum Master » de https://www.linkedin.com/learning/.
GLOSSAIRE
Utilisez les termes et définitions ci-dessous pour comprendre les concepts évoqués dans
la formation.

Recherche dans les transcriptions : notez que vous pouvez rechercher des termes direc-
tement dans la formation. Pour effectuer une recherche dans le texte de la vidéo, allez
dans l’onglet « Transcriptions », puis faites Ctrl + F sur votre clavier pour effectuer une
recherche dans la transcription affichée.

Terme Définition
Adaptation Modification des pratiques en vue de corriger les processus qui
n’aident pas à se rapprocher d’un objectif

Agile Adjectif utilisé pour qualifier tout cadre léger qui affiche les ob-
jectifs répertoriés dans le Manifeste Agile

Inspection Examen minutieux et continu du travail en cours visant à s’assu-


rer que le projet se rapproche de l’objectif prévu

Product Owner Seule personne à rendre compte du produit que l’équipe de


développement se charge de créer

Scrum Cadre simple, orienté vers une préparation juste suffisante,


juste à temps pour lancer le travail de développement

Scrum Master Personne qui gère le processus Scrum

Équipe Scrum Groupe composé du Product Owner, du Scrum Master et de


l’équipe de développement

Sprint Période durant laquelle l’équipe de développement est censée


créer un incrément produit potentiellement livrable

Transparence Notion selon laquelle tous les aspects d’un processus doivent
être visibles pour les personnes concernées

Vélocité Performances passées de l’équipe de développement

Préparer la certification Certified Scrum Master


GLOSSAIRE 1 sur 1
Préparer la
certification
Certified Scrum
Master
avec Kelley Oconnell

Fichiers d’exercice
Ces fichiers d’exercice sont un complément au cours « Préparer la certification
Certified Scrum Master » de https://www.linkedin.com/learning/.
Guide de la mêlée quotidienne
Participants : équipe Scrum, ressources partagées et parties intéressées comprises (mais
seuls les membres de l’équipe Scrum font une mise à jour)

Durée : 15 minutes

Fréquence : chaque jour du sprint

Objectif : inspecter et adapter afin de se rapprocher encore de l’objectif du sprint

Structure :
Chaque membre de l’équipe de développement
se posera tous les jours chacune des questions
suivantes.
• Qu’ai-je fait hier pour réaliser l’objectif du sprint ?
• Que ferai-je ce jour pour réaliser cet objectif ?
• Quels obstacles m’empêchent (ou empêchent l’équipe de développement) de
réaliser l’objectif du sprint ?

Après la mêlée, qui est limitée dans le temps, les membres de l’équipe peuvent poursuivre
le dialogue pour répondre aux questions, résoudre les problèmes, affiner la conception
ou adapter le travail restant durant le sprint.

Préparer la certification Certified Scrum Master


Guide de la mêlée quotidienne 1 sur 1
Préparer la
certification
Certified Scrum
Master
avec Kelley Oconnell

Fichiers d’exercice
Ces fichiers d’exercice sont un complément au cours « Préparer la certification
Certified Scrum Master » de https://www.linkedin.com/learning/.
Guide de perfectionnement
du backlog
Participants  : équipe Scrum, ressources partagées et experts du sujet compris, le cas
échéant

Durée : de 1 à 4 heures, selon la durée du sprint

Fréquence : une fois par sprint, en général à mi-parcours

Objectif : inspecter et adapter le backlog produit et les EBP pour s’assurer que les EBP
ciblés sont prêts pour le sprint suivant

Sujets abordés :
• Le PO présente le backlog en ordre et identifie les EBP qu’il souhaite pour le sprint
suivant.
• Les développeurs posent des questions et demandent à en savoir plus, si nécessaire.
• Tout EBP qui contient suffisamment d’informations est estimé par l’équipe de dé-
veloppement durant la séance.

Résultat :
• Liste des EBP à clarifier et questions en suspens

Le Scrum Master veille à ce que cet évènement ait lieu et soit bien facilité. Le Scrum Master
s’assure également que la boîte de temps est respectée.

Préparer la certification Certified Scrum Master


Guide de perfectionnement du backlog 1 sur 1
Préparer la
certification
Certified Scrum
Master
avec Kelley Oconnell

Fichiers d’exercice
Ces fichiers d’exercice sont un complément au cours « Préparer la certification
Certified Scrum Master » de https://www.linkedin.com/learning/.
Guide de la planification de sprint
Participants : équipe Scrum, ressources partagées comprises

Durée : de 2 à 8 heures, selon la durée du sprint

Fréquence : une fois par sprint, le premier jour

Éléments d’une planification réussie


• Backlog produit en ordre (hiérarchisé)
• Ce qui a été accompli durant le sprint précédent / incrément produit
• Performances passées de l’équipe de développement (vélocité)
• Capacité de l’équipe de développement pour le sprint

Sujets pour le dialogue de planification


• Qu’est-ce qui sera fait durant ce sprint ?

Les éléments de backlog produit (EBP) nécessaires pour créer un incrément pro-
duit seront sélectionnés. Cette décision appartient exclusivement à l’équipe de
développement.

Les EBP choisis influeront sur la définition de l’objectif du sprint par l’équipe Scrum.
• Comment effectuer les tâches sélectionnées afin de les finir ?

Connaissant l’objectif, l’équipe de développement décide de la façon d’intégrer


les fonctionnalités requises dans un incrément produit « fini ».

L’équipe de développement définit les tâches nécessaires pour achever l’incrément


produit, qui sont décomposées en plusieurs parties dont chacune prend un jour
au maximum.

Résultats d’une planification réussie


• Objectif du sprint et ce qui sera accompli (EBP)
• Façon dont le travail sera effectué (plan)
• Backlog du sprint

Préparer la certification Certified Scrum Master


Guide de la planification de sprint 1 sur 1
Préparer la
certification
Certified Scrum
Master
avec Kelley Oconnell

Fichiers d’exercice
Ces fichiers d’exercice sont un complément au cours « Préparer la certification
Certified Scrum Master » de https://www.linkedin.com/learning/.
Guide de la rétrospective
de sprint
Participants : équipe Scrum, ressources partagées comprises si elles ont travaillé avec
l’équipe durant le sprint

Durée : de 1 à 3 heures, selon la durée du sprint

Fréquence : une fois par sprint (c’est le dernier évènement du sprint)

Objectif : inspecter et adapter les processus de l’équipe et choisir des points à améliorer
particulièrement

Sujets abordés :
• Inspectez le déroulement du dernier sprint en ce qui concerne les individus, les
relations, la collaboration, les processus et les outils.
• Effectuez le classement des points principaux qui se sont bien passés et de ceux
qui sont perfectibles.
• Élaborez un plan pour mettre en œuvre des améliorations particulières quant au
fonctionnement de l’équipe.

Le Scrum Master veille à ce que cet évènement ait lieu et soit bien facilité. Le Scrum Mas-
ter s’assure également que la boîte de temps est respectée. En tant que responsable du
processus, le Scrum Master participe activement à cet évènement.

Préparer la certification Certified Scrum Master


Guide de la rétrospective de sprint 1 sur 1
EXAMEN PSM1 FOUNDATION

I. Les liens utiles :

• Lien vers la formation UDEMY → https://www.udemy.com/course/reussir-a-lexamen-psm1-foundation-du-premier-coups-fr


• Paiement du passage à la certification officielle → https://www.scrum.org/browse-certifications//psm1-foundation

II. Contacts utiles :

• Formateur : Wilfried FOALEM


• Mèl : Wilfriedfaoelm@gmail.com
• Tel : 07 69 83 40 74

Bon courage dans vos révisons et plein succès pour l’examen officiel !

WILFRIED FOALEM, INGENIEUR TELECOMS

Vous aimerez peut-être aussi