Le guide Scrum, développé par Ken Schwaber et Jeff Sutherland, présente Scrum comme un cadre léger et flexible pour développer et livrer des produits complexes. Il définit les rôles, événements et artefacts indispensables à la mise en œuvre de Scrum tout en mettant l'accent sur la transparence, l'inspection et l'adaptation. Les valeurs Scrum, telles que la focalisation, le respect et l'engagement, sont essentielles pour créer une équipe efficace et autonome.

1. Le Guide Scrum
Le guide de référence de Scrum :
les règles du jeu
Novembre 2017
Développé et maintenu par les créateurs de Scrum :
Ken Schwaber et Jeff Sutherland
Traduction non officielle par Les Traducteurs Agiles

2. Table des matières
Objectif du Guide Scrum..............................................................................................................3
Définition de Scrum......................................................................................................................3
Utilisation de Scrum.....................................................................................................................4
Théorie de Scrum.........................................................................................................................5
Transparence............................................................................................................................5
Inspection.................................................................................................................................5
Adaptation................................................................................................................................5
Valeurs Scrum...............................................................................................................................6
L'Équipe Scrum.............................................................................................................................6
Le Product Owner.....................................................................................................................6
L'Équipe de Développement.....................................................................................................7
Le Scrum Master.......................................................................................................................8
Événements Scrum.......................................................................................................................9
Le Sprint.................................................................................................................................10
Abandonner un Sprint............................................................................................................10
Planification du Sprint............................................................................................................11
Mêlée Quotidienne................................................................................................................13
Revue de Sprint......................................................................................................................14
Rétrospective du Sprint..........................................................................................................15
Artefacts Scrum..........................................................................................................................16
Backlog de Produit..................................................................................................................16
Backlog de Sprint....................................................................................................................17
Incrément...............................................................................................................................18
Transparence des Artefacts........................................................................................................18
Définition de « Fini »..............................................................................................................19
Conclusion..................................................................................................................................20
Remerciements..........................................................................................................................20
Personnes...............................................................................................................................20
Histoire...................................................................................................................................20
Traduction..............................................................................................................................21
©2017 Ken Schwaber and Jeff Sutherland. Cette œuvre est mise à disposition sous les termes de la licence Attribution-Partage
dans les mêmes conditions consultables sur http://creativecommons.org/licenses/by-sa/4.0/legalcode et résumées sur
http://creativecommons.org/licenses/by-sa/4.0/. En utilisant ce Guide Scrum, vous reconnaissez que vous l’avez lu et que vous
avez accepté de respecter les termes de la licence Attribution-Partage dans les mêmes conditions de Creative Commons.
Page | 2

3. Objectif du Guide Scrum
Scrum est un cadre pour développer, livrer et maintenir des produits complexes de nature. Ce
Guide contient la définition de Scrum. Cette définition comporte des rôles, des événements et
des artefacts de Scrum ainsi que les règles les reliant. Scrum a été développé par Ken
Schwaber et Jeff Sutherland qui ont ensemble écrit et proposé le Guide Scrum. Ils soutiennent
tous les deux le Guide Scrum.
Définition de Scrum
Scrum (nom) : Cadre à l'intérieur duquel des personnes peuvent aborder des problèmes
évolutifs complexes, tout en livrant d’une manière productive et créative des produits ayant 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 organiser l’activité autour des produits
complexes depuis le début des années 1990. Scrum n'est ni un processus, ni une technique, ni
une méthode de référence. Il s'agit plutôt d'un cadre à l'intérieur duquel vous pouvez
employer différents processus et techniques. Scrum rend transparent l'efficacité relative de
votre gestion de produits et de vos techniques de travail afin que vous puissiez améliorer en
permanence le produit, l’équipe et l’environnement de travail.
Le cadre Scrum est constitué des Équipes Scrum et des rôles, évènements, artefacts et règles
associés. Chaque composant de ce cadre sert un but spécifique et est essentiel à l'utilisation
et au succès de Scrum.
Les règles de Scrum relient ensemble les évènements, rôles et artefacts, elles gouvernent
leurs relations et leurs interactions. Les règles de Scrum sont décrites tout au long de ce
document.
Il existe de nombreuses manières d’utiliser le cadre Scrum ; elles sont présentées dans
d’autres documents que celui-ci.
©2017 Ken Schwaber and Jeff Sutherland. Cette œuvre est mise à disposition sous les termes de la licence Attribution-Partage
dans les mêmes conditions consultables sur http://creativecommons.org/licenses/by-sa/4.0/legalcode et résumées sur
http://creativecommons.org/licenses/by-sa/4.0/. En utilisant ce Guide Scrum, vous reconnaissez que vous l’avez lu et que vous
avez accepté de respecter les termes de la licence Attribution-Partage dans les mêmes conditions de Creative Commons.
Page | 3

4. Utilisation de Scrum
Scrum a été initialement développé pour gérer et développer des produits. Dès le début des
années 1990, Scrum a été utilisé de manière intensive dans le monde entier pour :
1. Rechercher et identifier des marchés, des technologies et des fonctionnalités produit
qui sont viables.
2. Développer des produits et les améliorer.
3. Livrer des produits et leurs améliorations, à un rythme pouvant aller jusqu’à plusieurs
fois par jour.
4. Développer et maintenir des environnements de type Cloud (en ligne, sécurisé, à la
demande) et tout autre environnement opérationnel ad-hoc permettant l’utilisation de
produit quel qu’il soit.
5. Maintenir et renouveler les produits.
Scrum a été utilisé dans les domaines logiciels, matériel informatique, logiciels embarqués,
réseaux de fonctions, véhicules autonomes, de l’éducation, des instances gouvernementales,
de services marketing, la direction des opérations des organisations et presque tout ce qui
nous sert dans notre vie de tous les jours, aussi bien en tant que personnes physiques que
personnes morales.
Les technologies, les marchés, les environnements et leurs interactions devenant de plus en
plus complexes rapidement, Scrum prouve jour après jour son utilité pour y faire face.
Scrum s’est révélé particulièrement efficace dans le transfert itératif et incrémental de
connaissances. Scrum est désormais largement utilisé pour les produits, les services et la
gestion des entreprises.
L’essence de Scrum repose sur une petite équipe de personnes. Une équipe seule sait faire
preuve de beaucoup de souplesse et de capacité d’adaptation. Ces points forts s’appliquent de
la même manière, que ce soit au niveau d’une équipe seule, de plusieurs équipes, de
beaucoup d’équipes, de réseaux d’équipes qui développent, livrent, font fonctionner et
maintiennent des produits à l’usage de milliers de personnes. Elles collaborent, interagissent
au travers d’architectures de développement sophistiquées et ont pour objectif de livrer en
environnement de production.
Les mots « développer » et « développement » utilisés dans le Guide Scrum font référence à
des travaux de nature complexe tels que ceux évoqués précédemment, ils désignent un type
de travail complexe, comme mentionné ci-dessus.
©2017 Ken Schwaber and Jeff Sutherland. Cette œuvre est mise à disposition sous les termes de la licence Attribution-Partage
dans les mêmes conditions consultables sur http://creativecommons.org/licenses/by-sa/4.0/legalcode et résumées sur
http://creativecommons.org/licenses/by-sa/4.0/. En utilisant ce Guide Scrum, vous reconnaissez que vous l’avez lu et que vous
avez accepté de respecter les termes de la licence Attribution-Partage dans les mêmes conditions de Creative Commons.
Page | 4

5. Théorie de Scrum
Scrum est fondé sur la théorie du contrôle de processus empirique, ou empirisme.
L'empirisme affirme que la connaissance provient de l'expérience et que la prise de décision
se base sur ce qui est connu. Scrum utilise une approche itérative et incrémentale pour
optimiser la prédictibilité et maîtriser les risques.
Trois piliers soutiennent chaque implémentation de ce contrôle de processus empirique :
transparence, inspection et adaptation.
Transparence
Les aspects importants du processus doivent être visibles de ceux qui sont responsables de
son résultat. La transparence exige que ces aspects soient définis par un standard commun
afin que les observateurs partagent une compréhension commune de ce qui est vu.
Par exemple :
 Un langage commun faisant référence au processus doit être partagé par tous les
participants.
 Ceux accomplissant les travaux et ceux vérifiant l’incrément qui en résulte doivent
partager une définition commune du « Fini ».
Inspection
Les utilisateurs Scrum doivent fréquemment inspecter les artefacts Scrum et l’avancement par
rapport à l'Objectif du Sprint afin de détecter des dérives indésirables. La fréquence de leurs
inspections ne devrait pas être trop élevée pour ne pas perturber le travail. Les inspections les
plus bénéfiques sont celles qui sont exécutées au bon moment et consciencieusement par des
experts qualifiés.
Adaptation
Si un expert détermine qu'un ou plusieurs aspects d'un processus dépassent les limites
acceptables, et que le produit résultant devient inacceptable, le processus ou les éléments
utilisés doivent être ajustés. Un ajustement doit être fait dès que possible pour minimiser
toute future dérive.
Scrum prescrit quatre évènements formels, pour l'inspection et l'adaptation, décrits dans la
section Évènements du présent document :
 Planification de Sprint
 Mêlée Quotidienne
 Revue de Sprint
 Rétrospective de Sprint
©2017 Ken Schwaber and Jeff Sutherland. Cette œuvre est mise à disposition sous les termes de la licence Attribution-Partage
dans les mêmes conditions consultables sur http://creativecommons.org/licenses/by-sa/4.0/legalcode et résumées sur
http://creativecommons.org/licenses/by-sa/4.0/. En utilisant ce Guide Scrum, vous reconnaissez que vous l’avez lu et que vous
avez accepté de respecter les termes de la licence Attribution-Partage dans les mêmes conditions de Creative Commons.
Page | 5

6. Valeurs Scrum
Une fois que l'Équipe Scrum s'approprie et incarne les valeurs Scrum (focalisation, ouverture,
respect, courage, engagement), alors les piliers de Scrum (transparence, inspection et
adaptation) prennent vie et permettent d'instaurer une confiance mutuelle. Les membres de
l’Équipe Scrum apprennent et approfondissent ces valeurs au fur et à mesure qu'ils travaillent
avec les évènements, rôles et artefacts Scrum.
Une utilisation réussie de Scrum repose sur la montée en compétence des personnes à travers
la pratique de ces cinq valeurs. Les personnes s’engagent personnellement pour atteindre les
objectifs de l’Équipe Scrum. Les membres de l’Équipe Scrum ont le courage de faire la chose
juste et de s’attaquer aux problèmes difficiles. Tout le monde se focalise sur le travail du Sprint
et sur les objectifs de l’Équipe Scrum. L’Équipe Scrum et ses parties prenantes s'accordent à
garder l’esprit ouvert sur l’ensemble du travail et sur les défis rencontrés lors de la réalisation
de ce travail. Les membres de l’Équipe Scrum se respectent les uns les autres comme étant
des personnes capables et autonomes.
L'Équipe Scrum
L'Équipe Scrum comprend un Product Owner, l'Équipe de Développement et un Scrum
Master. Les Équipes Scrum sont auto-organisées et pluridisciplinaires. Les équipes auto-
organisées choisissent le meilleur moyen d'accomplir leur travail plutôt qu'être dirigées par
des personnes extérieures à l'équipe. Les équipes pluridisciplinaires possèdent toutes les
compétences nécessaires pour accomplir le travail sans dépendre d'autres personnes ne
faisant pas partie de l'équipe. Le modèle d'équipe dans Scrum est conçu pour optimiser la
souplesse, la créativité et la productivité. Il a fait ses preuves quant à son efficacité sans cesse
croissante sur l’ensemble des usages précités et pour tout type de travail complexe.
Les Équipes Scrum livrent les produits de manière itérative et incrémentale, maximisant les
opportunités de feedback. Les livraisons incrémentales d’un produit « Fini » garantissent
qu'une version potentiellement utilisable du produit opérationnel est toujours disponible.
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 manière dont cela est réalisé peut largement varier d'une
organisation à l’autre, d'une Équipe Scrum à l’autre, d'une personne à l’autre.
Le Product Owner est la seule personne responsable de la gestion du Backlog de Produit. La
gestion du Backlog de Produit inclut les activités suivantes :
 Définir clairement les éléments du Backlog de Produit.
 Trier dans le Backlog de Produit les éléments les plus appropriés pour réaliser au mieux
les objectifs et les missions.
©2017 Ken Schwaber and Jeff Sutherland. Cette œuvre est mise à disposition sous les termes de la licence Attribution-Partage
dans les mêmes conditions consultables sur http://creativecommons.org/licenses/by-sa/4.0/legalcode et résumées sur
http://creativecommons.org/licenses/by-sa/4.0/. En utilisant ce Guide Scrum, vous reconnaissez que vous l’avez lu et que vous
avez accepté de respecter les termes de la licence Attribution-Partage dans les mêmes conditions de Creative Commons.
Page | 6

7.  Optimiser la valeur du travail réalisé par l'Équipe de Développement.
 S'assurer de la visibilité, de la transparence, et de la compréhension par tous du
Backlog de Produit, et montrer ce sur quoi l'Équipe Scrum travaillera prochainement.
 S'assurer que l'Équipe de Développement comprend les éléments du Backlog de
Produit.
Le Product Owner peut réaliser les activités indiquées ci-dessus, ou les faire réaliser par
l'Équipe de Développement. Toutefois, le Product Owner en reste responsable.
Le rôle de Product Owner est incarné par une seule personne, pas un comité. Le Product
Owner peut faire figurer dans le Backlog de Produit les demandes d'un comité, mais ceux qui
veulent changer la priorité d'un élément du Backlog de Produit doivent s'adresser au Product
Owner.
Pour que le Product Owner puisse réussir, toute l'organisation doit respecter ses décisions. Les
décisions du Product Owner sont visibles par l'ordre et le contenu du Backlog de Produit.
Personne ne peut forcer l'Équipe de Développement à travailler sur un autre ensemble
d'exigences.
L'Équipe de Développement
L'Équipe de Développement est composée de professionnels qui travaillent pour livrer
l’incrément potentiellement déployable d’un produit « Fini » à la fin de chaque Sprint. Un
incrément « Fini » est exigé pour la Revue de Sprint. Seuls les membres de l'Équipe de
Développement créent un incrément.
Les Équipes de Développement sont structurées et soutenues par l'organisation pour gérer et
organiser leur propre travail. La synergie qui en résulte optimise l'efficience et l'efficacité
globales de l'Équipe de Développement.
Les Équipes de Développement possèdent les caractéristiques suivantes :
 Elles sont auto-organisées. Personne (pas même le Scrum Master) ne peut dire à
l'Équipe de Développement comment transformer le Backlog de Produit en incrément
de fonctionnalités potentiellement déployables.
 Les Équipes de Développement sont pluridisciplinaires, avec toutes les compétences
dont une équipe a besoin pour créer un incrément de produit.
 Scrum ne reconnaît pas d'autres titres au sein de l'Équipe de Développement que celui
de Développeur, quel que soit le travail réalisé par la personne.
 Scrum ne reconnaît aucune sous-équipe dans l'Équipe de Développement, sans
distinction des domaines ayant besoin d'être abordés tels que le test, l’architecture, le
support ou l'analyse métier.
©2017 Ken Schwaber and Jeff Sutherland. Cette œuvre est mise à disposition sous les termes de la licence Attribution-Partage
dans les mêmes conditions consultables sur http://creativecommons.org/licenses/by-sa/4.0/legalcode et résumées sur
http://creativecommons.org/licenses/by-sa/4.0/. En utilisant ce Guide Scrum, vous reconnaissez que vous l’avez lu et que vous
avez accepté de respecter les termes de la licence Attribution-Partage dans les mêmes conditions de Creative Commons.
Page | 7

8.  Chaque membre de l'Équipe de Développement peut avoir des compétences et des
centres d'intérêts spécifiques, mais la responsabilité en incombe à l'Équipe de
Développement dans son ensemble.
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 suffisamment grande pour réaliser un travail significatif pendant un Sprint. En-
dessous de 3, les membres de l'Équipe de Développement perdent en interaction et cela
génère de faibles gains de productivité. Avec des petites Équipes de Développement, des
manques de compétences peuvent apparaître pendant le Sprint, rendant ainsi impossible la
fourniture d’un incrément potentiellement déployable. Avoir plus de neuf membres demande
trop de coordination. De grandes Équipes de Développement génèrent trop de complexité
pour conserver un processus empirique utile. Les rôles de Product Owner et de Scrum Master
ne sont pas inclus dans ce nombre, à moins qu'ils n'exécutent des travaux du Backlog de Sprint.
Le Scrum Master
Le Scrum Master a la responsabilité de promouvoir et appuyer l’utilisation de Scrum tel qu’il
est décrit dans le Guide Scrum. Les Scrum Masters le font en apportant à quiconque leur aide
quant à la compréhension de la théorie, des pratiques, des règles et des valeurs de Scrum.
Le Scrum Master a un rôle de leader au service de l’Équipe Scrum (servant-leader). Le Scrum
Master aide les personnes extérieures à l'Équipe Scrum à comprendre quelles interactions avec
celle-ci sont bénéfiques et lesquelles ne le sont pas. Le Scrum Master aide chacun à modifier
ces interactions afin de maximiser la valeur créée par l'Équipe Scrum.
Le Scrum Master au service du Product Owner
Le Scrum Master sert le Product Owner de plusieurs façons, notamment :
 En s’assurant que les objectifs, le périmètre et le domaine produit soient, autant que
possible, bien compris par chaque membre de l’Équipe Scrum.
 En trouvant des techniques pour gérer efficacement le Backlog de Produit.
 En aidant l'Équipe Scrum à comprendre le besoin pour obtenir des éléments du Backlog
de Produit clairs et précis.
 En comprenant ce qu’est la planification de produit dans un environnement empirique.
 En s'assurant que le Product Owner sache comment organiser le Backlog de Produit
pour maximiser la valeur.
 En comprenant et en pratiquant l'agilité.
 En facilitant les évènements Scrum attendus ou nécessaires.
©2017 Ken Schwaber and Jeff Sutherland. Cette œuvre est mise à disposition sous les termes de la licence Attribution-Partage
dans les mêmes conditions consultables sur http://creativecommons.org/licenses/by-sa/4.0/legalcode et résumées sur
http://creativecommons.org/licenses/by-sa/4.0/. En utilisant ce Guide Scrum, vous reconnaissez que vous l’avez lu et que vous
avez accepté de respecter les termes de la licence Attribution-Partage dans les mêmes conditions de Creative Commons.
Page | 8

9. Le Scrum Master au service de l'Équipe de Développement
Le Scrum Master est au service de l'Équipe de Développement de plusieurs façons,
notamment :
 En coachant l'Équipe de Développement vers l'auto-organisation et la
pluridisciplinarité.
 En aidant l'Équipe de Développement à créer des produits de grande valeur.
 En supprimant les obstacles empêchant l'avancée de l'Équipe de Développement.
 En facilitant les évènements Scrum attendus ou nécessaires. .
 En coachant l'Équipe de Développement dans des organisations où Scrum n'est pas
encore complètement compris et adopté.
Le Scrum Master au service de l'Organisation
Le Scrum Master sert l'organisation de plusieurs façons, notamment :
 En guidant et en coachant l'organisation dans son adoption de Scrum.
 En planifiant les mises en œuvre de Scrum dans l'organisation.
 En aidant les employés et les parties prenantes à comprendre et à promouvoir Scrum
et le développement empirique de produit.
 En provoquant des changements pour augmenter la productivité de l'Équipe Scrum.
 En travaillant avec d'autres Scrum Masters pour accroître l'efficacité de l'application de
Scrum dans l'organisation.
Événements Scrum
Les événements prescrits ci-après sont utilisés en Scrum pour créer de la régularité et pour
minimiser la nécessité de réunions non définies dans Scrum. Tous les évènements ont une
durée déterminée (time-box), de telle façon que chaque événement ait une durée maximale.
Une fois qu'un Sprint a commencé, sa durée est fixée et elle ne pourra être ni raccourcie ni
allongée. Les autres évènements peuvent se terminer n'importe quand, dès lors que l'objectif
de cet événement est atteint, assurant ainsi que le temps passé n’a pas entraîné de gaspillage
dans le processus.
A part le Sprint lui-même, qui est le conteneur des autres évènements, chaque événement
dans Scrum est une opportunité formelle pour inspecter et adapter quelque chose. Ces
évènements sont spécifiquement conçus pour permettre une transparence et une inspection
critiques. Ne pas mettre en place un de ces évènements réduit la transparence et c’est une
occasion perdue d'inspection et d'adaptation.
©2017 Ken Schwaber and Jeff Sutherland. Cette œuvre est mise à disposition sous les termes de la licence Attribution-Partage
dans les mêmes conditions consultables sur http://creativecommons.org/licenses/by-sa/4.0/legalcode et résumées sur
http://creativecommons.org/licenses/by-sa/4.0/. En utilisant ce Guide Scrum, vous reconnaissez que vous l’avez lu et que vous
avez accepté de respecter les termes de la licence Attribution-Partage dans les mêmes conditions de Creative Commons.
Page | 9

10. Le Sprint
Le cœur de Scrum est le Sprint, une période fixe (time-box) d'un mois ou moins durant lequel
un Incrément « Fini », utilisable, potentiellement déployable est créé. Les Sprints ont une
durée constante tout au long de l'effort de développement. Un nouveau Sprint commence
immédiatement après la fin du Sprint précédent.
Les Sprints englobent la Planification de Sprint, les Mêlées Quotidiennes, les travaux de
développement, la Revue de Sprint, et la Rétrospective de Sprint.
Pendant le Sprint:
 Aucun changement n'est fait qui puisse mettre en danger l'Objectif du Sprint.
 Les objectifs de qualité ne sont jamais réduits.
 Le périmètre peut être clarifié et renégocié entre le Product Owner et l'Équipe de
Développement du fait de l'approfondissement des connaissances.
Chaque Sprint peut être considéré comme un projet ayant un horizon d'un mois au plus.
Comme les projets, les Sprints sont utilisés pour accomplir quelque chose. Chaque Sprint a un
objectif de ce qui est à construire, un planning flexible pour piloter sa réalisation, le travail et
l’incrément produit qui en résultera.
Les sprints sont limités à un mois calendaire. Lorsque l'horizon d'un Sprint est trop lointain, la
définition de ce qui est construit peut changer, la complexité peut augmenter, et le risque
peut s'accroître. Les Sprints favorisent la prédictibilité en assurant l’inspection et l’adaptation
de l’atteinte des Objectifs du Sprint au moins une fois par mois calendaire. Les Sprints limitent
aussi les risques financiers à un mois budgétaire.
Abandonner un Sprint
Un Sprint peut être abandonné avant que la fin de la période fixe (time-box) soit atteinte. Seul
le Product Owner a l'autorité pour abandonner un Sprint, même s'il peut le faire sous
l'influence des parties prenantes, de l'Équipe de Développement, ou du Scrum Master.
Un Sprint peut être abandonné si l'Objectif du Sprint devient obsolète. Cela peut arriver si
l'entreprise change de direction ou si les conditions du marché ou technologiques changent.
En général, un Sprint peut être abandonné s'il n'a plus aucun sens compte tenu des
circonstances. Mais, étant donné la courte durée des Sprints, l'abandon a rarement du sens.
Quand un Sprint est abandonné, tous les éléments complétés et « Finis » du Backlog de
Produit font l'objet d'une revue. Si une partie des travaux est potentiellement déployable, le
Product Owner l'accepte généralement. Tous les éléments incomplets du Backlog de Produit
sont ré-estimés et remis dans le Backlog de Produit. Le travail réalisé sur ces éléments se
déprécie rapidement et doit fréquemment être ré-estimé (NdT : compte tenu de l'avancée
rapide des travaux ou des priorités courantes sur le Sprint en cours).
©2017 Ken Schwaber and Jeff Sutherland. Cette œuvre est mise à disposition sous les termes de la licence Attribution-Partage
dans les mêmes conditions consultables sur http://creativecommons.org/licenses/by-sa/4.0/legalcode et résumées sur
http://creativecommons.org/licenses/by-sa/4.0/. En utilisant ce Guide Scrum, vous reconnaissez que vous l’avez lu et que vous
avez accepté de respecter les termes de la licence Attribution-Partage dans les mêmes conditions de Creative Commons.
Page | 10

11. Les abandons de Sprint consomment des ressources, tout le monde étant amené à se
regrouper pour une nouvelle Planification de Sprint afin de commencer un autre Sprint. Les
abandons de Sprint sont souvent traumatisants pour l'Équipe Scrum, et sont très rares.
Planification du Sprint
Le travail à accomplir pendant le Sprint est planifié lors de la Planification de Sprint. Ce plan
est construit grâce à la collaboration de l’Équipe Scrum dans son ensemble.
La Planification de Sprint a une durée (time-box) maximale de huit heures pour un Sprint d’un
mois. Pour des Sprints plus courts, la durée est normalement plus courte. Le Scrum Master
s’assure que cet événement a lieu et que les participants en comprennent l’objectif. Le Scrum
Master éduque l’Équipe Scrum au respect de cette durée fixe.
La Planification de Sprint répond aux questions suivantes :
 Qu’est-ce qui pourrait être livré dans l’incrément résultant du prochain Sprint ?
 Comment sera accompli le travail nécessaire pour réaliser l'incrément ?
Premier sujet : qu'est-ce qui peut être fini durant ce Sprint ?
L'Équipe de Développement travaille pour estimer la fonctionnalité qui sera développée
pendant le Sprint. Le Product Owner présente l'objectif que le Sprint devrait atteindre et les
éléments du Backlog de Produit qui, s'ils sont réalisés, devraient permettre d'accomplir
l'Objectif du Sprint. Toute l'Équipe Scrum travaille alors ensemble sur la compréhension du
travail à effectuer dans le Sprint.
Les éléments requis pour cette réunion sont le Backlog de Produit, le dernier Incrément de
produit, la capacité prévue de l'Équipe de Développement pour le Sprint, ainsi que sa
performance passée. Le choix du nombre d'éléments sélectionnés dans le Backlog de Produit
pour le Sprint relève entièrement de l'Équipe de Développement. Seule l'Équipe de
Développement est en mesure d'évaluer ce qu'elle peut accomplir durant le prochain Sprint.
Pendant la Planification du Sprint, l'Équipe Scrum élabore un Objectif de Sprint. L'Objectif de
Sprint est un objectif qui sera atteint durant le Sprint par la réalisation du Backlog de Produit.
Cet objectif donne à l'Équipe de Développement du sens à la réalisation de l'Incrément.
©2017 Ken Schwaber and Jeff Sutherland. Cette œuvre est mise à disposition sous les termes de la licence Attribution-Partage
dans les mêmes conditions consultables sur http://creativecommons.org/licenses/by-sa/4.0/legalcode et résumées sur
http://creativecommons.org/licenses/by-sa/4.0/. En utilisant ce Guide Scrum, vous reconnaissez que vous l’avez lu et que vous
avez accepté de respecter les termes de la licence Attribution-Partage dans les mêmes conditions de Creative Commons.
Page | 11

12. Deuxième sujet : comment le travail sélectionné sera-t-il accompli ?
Après avoir défini l’Objectif du Sprint et choisi les éléments du Backlog de Produit pour le
Sprint, l'Équipe de Développement décide comment elle va réaliser, durant le Sprint, un
Incrément de produit « Fini ». L'ensemble comprenant les éléments du Backlog de Produit
sélectionnés pour ce Sprint et le plan d’actions pour les livrer est appelé le Backlog de Sprint.
L'Équipe de Développement commence généralement par concevoir le système et le travail
nécessaire pour convertir le Backlog de Produit en un Incrément fonctionnel livrable. La taille
ou l’effort estimé du travail peut varier. Cependant, suffisamment de travail doit être prévu
lors de la Planification de Sprint pour que l'Équipe de Développement puisse prévoir ce qu'elle
pense pouvoir accomplir durant le Sprint à venir. Le travail prévu pour les premiers jours du
Sprint est décomposé, avant la fin de la réunion, en tâches souvent d'une journée ou moins.
L'Équipe de Développement s'auto-organise pour consigner les travaux dans le Backlog de
Sprint, à la fois lors de la Planification de Sprint et tout au long du Sprint quand c'est
nécessaire.
Le Product Owner peut aider à clarifier les éléments du Backlog de Produit sélectionnés et
faire des compromis. Si l'Équipe de Développement estime qu'elle a trop ou pas assez de
travail, elle peut renégocier avec le Product Owner les éléments du Backlog de Produit
sélectionnés. L'Équipe de Développement peut également inviter d'autres personnes à la
réunion afin qu’elles fournissent des conseils d’ordre technique ou portant sur le domaine.
À la fin de la Planification de Sprint, l'Équipe de Développement devrait être en mesure
d'expliquer au Product Owner et au Scrum Master comment elle entend travailler en tant
qu'équipe auto-organisée pour atteindre l'Objectif de Sprint et livrer l’Incrément prévu.
Objectif du Sprint
L’Objectif de Sprint est un objectif défini pour le Sprint qui peut être atteint par
l’implémentation du Backlog de Produit. Il fournit à l’Équipe de Développement la raison pour
laquelle elle construit l’Incrément. Il est défini lors de la Planification de Sprint. L’Objectif du
Sprint laisse à l’Équipe de Développement de la latitude sur la fonctionnalité à implémenter
dans le Sprint. Les éléments du Backlog de Produit sélectionnés livrent une fonctionnalité
cohérente, qui peut être l’Objectif du Sprint. L’Objectif du Sprint peut être n’importe quelle
autre chose cohérente permettant d'amener l’équipe de Développement à travailler ensemble
plutôt que sur des initiatives séparées.
Tout au long du Sprint, l’Équipe de Développement garde l’Objectif de Sprint en tête. Cet
objectif guide le travail de l’équipe, tant au niveau fonctionnel que technologique. Si l’Équipe
de Développement découvre pendant le Sprint que le travail à faire pour atteindre cet objectif
diffère du travail envisagé, alors elle collabore avec le Product Owner pour redéfinir le
périmètre du Backlog de Sprint.
©2017 Ken Schwaber and Jeff Sutherland. Cette œuvre est mise à disposition sous les termes de la licence Attribution-Partage
dans les mêmes conditions consultables sur http://creativecommons.org/licenses/by-sa/4.0/legalcode et résumées sur
http://creativecommons.org/licenses/by-sa/4.0/. En utilisant ce Guide Scrum, vous reconnaissez que vous l’avez lu et que vous
avez accepté de respecter les termes de la licence Attribution-Partage dans les mêmes conditions de Creative Commons.
Page | 12

13. Mêlée Quotidienne
La Mêlée Quotidienne est un événement à durée fixe (time-box) de 15 minutes pour l’Équipe
de Développement. La Mêlée Quotidienne se tient tous les jours du Sprint. L’Équipe de
Développement y planifie ses activités pour les prochaines 24 heures. Elle optimise la
collaboration et la performance de l’équipe en lui permettant d’inspecter le travail effectué
depuis la dernière Mêlée Quotidienne et de prévoir le travail à venir dans le Sprint. Pour se
simplifier la vie, la Mêlée Quotidienne se tient à la même heure et au même endroit tous les
jours.
L’Équipe de Développement utilise la Mêlée Quotidienne pour inspecter sa progression vers
l’Objectif du Sprint et pour inspecter si ces progrès aident à finir le travail contenu dans le
Backlog de Sprint. La Mêlée Quotidienne augmente la probabilité pour l’Équipe de
Développement d’atteindre l’Objectif du Sprint. Chaque jour, les membres de l’Équipe de
Développement sont amenés à comprendre la façon dont ils ont l’intention de travailler
ensemble en tant qu’équipe auto-organisée pour atteindre l’Objectif du Sprint et créer
l’incrément d’ici la fin du Sprint.
La structure de cette réunion est définie par l’Équipe de Développement et peut être menée
de différentes manières du moment qu’elle reste concentrée sur la progression vers l’Objectif
du Sprint. Certaines Équipes de Développement utiliseront des questions, d’autres auront des
discussions. Voici un exemple de questions pouvant être utilisées :
 Qu’ai-je fait hier qui aide l’Équipe de Développement à atteindre l’Objectif du Sprint ?
 Que vais-je faire aujourd’hui qui aide l’Équipe de Développement à atteindre l’Objectif
du Sprint ?
 Est-ce que je vois un obstacle qui m’empêche ou empêche l’Équipe de Développement
d’atteindre l’Objectif du Sprint ?
L’Équipe de Développement ou certains membres de l’équipe se voient souvent
immédiatement juste après la Mêlée Quotidienne pour discuter de manière détaillée de
certains points, pour adapter, ou pour replanifier le reste du travail contenu dans le Sprint.
Le Scrum Master s’assure que l’Équipe de Développement a bien cette réunion, mais c’est
l’Équipe de Développement qui est responsable de mener la Mêlée Quotidienne. Le Scrum
Master éduque l’Équipe de Développement à conserver une Mêlée Quotidienne dans une
durée fixe de 15 minutes (time-box).
La Mêlée Quotidienne est une réunion interne à 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, remplacent d’autres réunions,
identifient les obstacles au développement à supprimer, mettent en lumière et promeuvent
les décisions rapides, et améliorent le niveau de connaissance de l’Équipe de Développement.
C’est une réunion clé d’inspection et d’adaptation.
©2017 Ken Schwaber and Jeff Sutherland. Cette œuvre est mise à disposition sous les termes de la licence Attribution-Partage
dans les mêmes conditions consultables sur http://creativecommons.org/licenses/by-sa/4.0/legalcode et résumées sur
http://creativecommons.org/licenses/by-sa/4.0/. En utilisant ce Guide Scrum, vous reconnaissez que vous l’avez lu et que vous
avez accepté de respecter les termes de la licence Attribution-Partage dans les mêmes conditions de Creative Commons.
Page | 13

14. Revue de Sprint
Une Revue de Sprint se tient à la fin du Sprint pour inspecter l’Incrément et adapter le Backlog
de Produit si nécessaire. Pendant la Revue de Sprint, l’Équipe Scrum et les parties-prenantes
collaborent au sujet de ce qui a été fini pendant le Sprint. En fonction de cela et des
changements du Backlog de Produit intervenus pendant le Sprint, les participants collaborent
sur les prochaines choses à faire pour optimiser la valeur. Il s’agit d’une réunion informelle,
pas d’une réunion de suivi d'avancement, et la démonstration de l’Incrément doit inciter le
feedback et favoriser la collaboration.
Pour cette réunion, il faut compter au plus une durée de quatre heures pour un Sprint d’un
mois. Pour des sprints plus courts, la durée est généralement plus courte. Le Scrum Master
s’assure que cette réunion a lieu et que les participants en comprennent l’objectif. Le Scrum
Master éduque tout le monde à respecter la durée fixée pour cette réunion.
La Revue de Sprint inclut les points suivants :
 Les participants sont l’Équipe Scrum et les parties-prenantes clés invitées par le Product
Owner.
 Le Product Owner explique quels éléments du Backlog de 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 sont
les problèmes auxquels ils ont dû faire face, et comment ils les ont résolus.
 L’Équipe de Développement fait la démonstration du travail qui est « Fini » et répond aux
questions au sujet de l’Incrément.
 Le Product Owner discute du Backlog de Produit tel qu’il est. Il ou elle envisage la cible et
les dates de livraison probables en fonction des progrès réalisés à ce jour (si nécessaire).
 Le groupe entier collabore sur ce qui doit être fait ensuite, fournissant des informations de
valeur pour la prochaine Planification de Sprint.
 Prendre en considération la manière dont le marché ou l’utilisation potentielle du produit
ont pu changer les choses qui sont dorénavant les plus importantes.
 Examiner le calendrier, le budget, les capacités potentielles, et le marché pour les
prochaines livraisons du produit ou de certaines fonctionnalités.
Le résultat de la Revue de Sprint est un Backlog de Produit révisé, précisant les éléments du
Backlog de Produit potentiels pour le Sprint suivant. Le Backlog de Produit peut être aussi
ajusté dans son ensemble pour répondre à de nouvelles opportunités.
©2017 Ken Schwaber and Jeff Sutherland. Cette œuvre est mise à disposition sous les termes de la licence Attribution-Partage
dans les mêmes conditions consultables sur http://creativecommons.org/licenses/by-sa/4.0/legalcode et résumées sur
http://creativecommons.org/licenses/by-sa/4.0/. En utilisant ce Guide Scrum, vous reconnaissez que vous l’avez lu et que vous
avez accepté de respecter les termes de la licence Attribution-Partage dans les mêmes conditions de Creative Commons.
Page | 14

15. Rétrospective du Sprint
La Rétrospective de Sprint est une occasion pour l'Équipe Scrum de s'inspecter elle-même et
de créer un plan d'améliorations qui sera mis en place au cours du Sprint suivant.
La Rétrospective de Sprint intervient après la Revue de Sprint et avant la prochaine Réunion
de Planification de Sprint. Il faut compter au plus une durée de trois heures pour cette
réunion pour un Sprint d’un mois. Pour des sprints plus courts, la durée est généralement
réduite. Le Scrum Master s’assure que cette réunion a lieu et que les participants en
comprennent l’objectif.
Le Scrum Master s’assure que la réunion reste positive et productive. Le Scrum Master
éduque tout le monde à respecter la durée fixée pour cette réunion. Le Scrum Master
participe à cette réunion en tant que membre de l’équipe au même titre que les autres avec
les mêmes responsabilités sur le processus Scrum.
L’objectif de la Rétrospective de Sprint est de :
 Inspecter le dernier Sprint pour voir comment il s’est déroulé au regard des personnes, des
relations, du processus, et des outils.
 Identifier et ordonner les éléments les plus importants qui se sont bien déroulés et les
améliorations potentielles.
 Créer un plan pour mettre en œuvre les améliorations sur la manière qu’a l’Équipe Scrum
de faire son travail.
Le Scrum Master encourage l’Équipe Scrum, dans le cadre du processus Scrum, à améliorer
son processus et ses pratiques de développement pour les rendre plus efficaces et agréables
pour le prochain Sprint. Lors de chaque Rétrospective de Sprint, l’Équipe Scrum prévoit des
moyens d’accroître la qualité du produit en améliorant le processus de travail ou en adaptant
la définition de « Fini », si c’est approprié, et en restant cohérent avec les standards du
produit et de l’organisation.
A la fin de la Rétrospective de Sprint, l’Équipe Scrum doit avoir identifié les améliorations qui
seront mises en œuvre dans le Sprint suivant. Mettre en œuvre ces améliorations dans le
prochain Sprint est l’adaptation répondant à l’inspection de l’Équipe Scrum par et pour elle-
même. Bien que des améliorations puissent être mises en œuvre à tout moment, la
Rétrospective de Sprint fournit une occasion formelle dédiée à l’inspection et l’adaptation.
©2017 Ken Schwaber and Jeff Sutherland. Cette œuvre est mise à disposition sous les termes de la licence Attribution-Partage
dans les mêmes conditions consultables sur http://creativecommons.org/licenses/by-sa/4.0/legalcode et résumées sur
http://creativecommons.org/licenses/by-sa/4.0/. En utilisant ce Guide Scrum, vous reconnaissez que vous l’avez lu et que vous
avez accepté de respecter les termes de la licence Attribution-Partage dans les mêmes conditions de Creative Commons.
Page | 15

16. Artefacts Scrum
Les artefacts de Scrum représentent du travail ou de la valeur apportant de la transparence et
des opportunités pour l'inspection et l'adaptation. Les artefacts définis par Scrum sont
spécifiquement élaborés pour maximiser la transparence sur les informations essentielles
permettant à toute personne d’avoir le même niveau de compréhension au sujet de ces
artefacts.
Backlog de Produit
Le Backlog de Produit est une liste ordonnée de tous les éléments connus nécessaires pour le
produit. Il est la source unique des exigences pour tous les changements à effectuer sur le
produit. Le Product Owner est responsable du Backlog de Produit, de son contenu, de sa
disponibilité ainsi que de son ordonnancement.
Le Backlog de Produit n’est jamais terminé. Ses premières versions contiennent uniquement
les exigences identifiées initialement et les mieux comprises. Le Backlog de Produit évolue au
fur et à mesure que le produit et l’environnement dans lequel il sera utilisé évoluent. Le
Backlog de Produit est dynamique ; il change constamment pour refléter ce que le produit
requiert pour être compétitif et utile. Si un produit existe, son Backlog de Produit existe aussi.
Le Backlog de Produit liste toutes les caractéristiques, fonctions, exigences, améliorations et
correctifs qui correspondent aux changements qui doivent être appliqués au produit lors de
livraisons futures. Les éléments du Backlog de Produit possèdent une description, un ordre,
une estimation et une valeur. Les éléments du Backlog de Produit incluent souvent la
description des tests qui prouveront sa complétude lorsqu’il est considéré « Fini ».
Du fait qu’un produit est utilisé et gagne en valeur, et que le marché fournit du feedback, le
Backlog de Produit grandit et devient plus exhaustif. Les exigences n’arrêtent jamais d’évoluer,
le Backlog de Produit devient un artefact vivant. Les changements dans les exigences métier,
les conditions du marché ou la technologie peuvent faire évoluer le Backlog de Produit.
Plusieurs équipes Scrum travaillent souvent ensemble sur le même produit. Un seul Backlog
de Produit est utilisé pour décrire le travail à faire sur le produit. Il peut alors être utile
d’ajouter un attribut au Backlog de Produit pour regrouper les éléments.
L’affinage du Backlog de Produit est l’action consistant à ajouter du détail, des estimations, un
ordre aux éléments du Backlog de Produit. C’est un processus continu dans lequel le Product
Owner et l’Équipe de Développement collaborent pour détailler les éléments du Backlog de
Produit. Lors de l’affinage du Backlog de Produit, les éléments sont revus et corrigés. L’Équipe
Scrum décide de la manière et du moment où l’affinage doivent être faits. L'affinage ne prend
généralement pas plus de 10% de la capacité de l’Équipe de Développement. Cependant, les
éléments du Backlog de Produit peuvent être mis à jour à tout moment par le Product Owner
ou à la discrétion du Product Owner.
©2017 Ken Schwaber and Jeff Sutherland. Cette œuvre est mise à disposition sous les termes de la licence Attribution-Partage
dans les mêmes conditions consultables sur http://creativecommons.org/licenses/by-sa/4.0/legalcode et résumées sur
http://creativecommons.org/licenses/by-sa/4.0/. En utilisant ce Guide Scrum, vous reconnaissez que vous l’avez lu et que vous
avez accepté de respecter les termes de la licence Attribution-Partage dans les mêmes conditions de Creative Commons.
Page | 16

17. Les éléments figurant en premier dans l’ordre du Backlog de Produit sont généralement plus
clairs et détaillés que les éléments avec un rang moins élevé. Des estimations plus précises
sont élaborées grâce à une plus grande clarté et un niveau de détail accru ; plus l'élément est
bas dans le backlog, moins il y a de détail. Les éléments du Backlog de Produit qui vont
occuper l’Équipe de Développement dans le prochain Sprint sont affinés afin que chacun
puisse être raisonnablement « Fini » dans la durée du Sprint. Les éléments du Backlog de
Produit qui peuvent être « finis » par l’Équipe de Développement en un Sprint sont qualifiés
de « Prêt », c'est-à-dire sélectionnables lors d'une Planification de Sprint. Les éléments du
Backlog de Produit acquièrent ce degré de transparence au travers des activités d’affinage
décrites ci-dessus.
L’Équipe de Développement est responsable de l’ensemble des estimations. Le Product Owner
peut influencer l’Équipe de Développement en l’aidant à comprendre et à choisir des
compromis, mais ce sont les personnes qui feront le travail qui fourniront l’estimation finale.
Suivre la progression vers des objectifs
A tout moment, le travail global restant à faire pour atteindre un objectif peut être calculé. Le
Product Owner suit la somme du travail restant à faire au moins à chaque Revue de Sprint. Le
Product Owner compare cette quantité au travail restant à faire lors des Revues de Sprint
précédentes pour évaluer les progrès vers l'achèvement des travaux prévus dans le temps
souhaité pour l'objectif. Cette information est rendue transparente pour toutes les parties
prenantes.
Diverses techniques ont été utilisées pour suivre et projeter l'avancement des travaux comme
les burn-downs, burn-ups ou diagrammes de flux cumulés. Elles ont prouvé leur utilité.
Cependant, elles ne remplacent pas l'importance de l'empirisme. Dans des environnements
complexes, ce qui va se passer est inconnu. Seul ce qui s'est déjà passé peut être utilisé pour
la prise de décision prospective.
Backlog de Sprint
Le Backlog de Sprint est l’ensemble des éléments du Backlog de Produit choisis pour le Sprint
ainsi que le plan pour les réaliser dans le cadre d’un Incrément de produit qui concrétisera
l’Objectif du Sprint. Le Backlog de Sprint est une prévision de l’Équipe de Développement sur
des fonctionnalités qui seront présentes dans le prochain Incrément et sur le travail qui devra
être fait pour arriver à livrer ces fonctionnalités dans le cadre d’un Incrément « Fini ».
Le Backlog de Sprint rend visible tout le travail que l’Équipe de Développement identifie
comme nécessaire à l’atteinte de l’Objectif du Sprint. Pour garantir l’amélioration continue, il
inclut au minimum une amélioration du processus de plus haute priorité identifiée lors de la
dernière Rétrospective.
Le Backlog de Sprint est un plan suffisamment détaillé pour que la progression de l’équipe soit
claire lors de la Mêlée Quotidienne. L'Équipe de Développement modifie le Backlog de Sprint
tout au long du Sprint, il prend forme et émerge pendant le Sprint.
©2017 Ken Schwaber and Jeff Sutherland. Cette œuvre est mise à disposition sous les termes de la licence Attribution-Partage
dans les mêmes conditions consultables sur http://creativecommons.org/licenses/by-sa/4.0/legalcode et résumées sur
http://creativecommons.org/licenses/by-sa/4.0/. En utilisant ce Guide Scrum, vous reconnaissez que vous l’avez lu et que vous
avez accepté de respecter les termes de la licence Attribution-Partage dans les mêmes conditions de Creative Commons.
Page | 17

18. Cette émergence se produit lorsque l’équipe exécute le plan et découvre ce qui est nécessaire
pour atteindre l’Objectif du Sprint.
À mesure que du nouveau travail est découvert, l’Équipe de Développement l’ajoute au
Backlog de Sprint. Lorsque le travail est effectué ou fini, le travail estimé restant à faire est mis
à jour. Lorsque des éléments du plan sont considérés comme n’étant plus nécessaires, ils sont
retirés. Seule l’Équipe de Développement peut changer le Backlog de Sprint pendant un
Sprint. Le Backlog de Sprint est une vue en temps-réel et très visible du travail que l’Équipe de
Développement projette d'accomplir durant le Sprint. L’Équipe de Développement en est la
seule propriétaire.
Suivi de la Progression du Sprint
A n’importe quel moment d’un Sprint, la quantité totale de travail restant dans le Backlog de
Sprint peut être calculée. L’Équipe de Développement fait le suivi de ce reste à faire, au moins
à chaque Mêlée Quotidienne, afin de vérifier la probabilité d’atteindre l’Objectif du Sprint. En
faisant le suivi du reste à faire tout au long du Sprint, l’Équipe de Développement peut gérer
sa progression.
Incrément
L’Incrément est la somme de tous les éléments du Backlog de Produit terminés pendant un
Sprint et la valeur des incréments de tous les sprints précédents. A la fin d’un Sprint, le nouvel
Incrément doit être « Fini », ce qui signifie qu’il doit être dans un état utilisable et être en
accord avec la Définition de « Fini » de l’Équipe Scrum. Un incrément est le fruit d’un travail
fini, inspectable qui viendra alimenter l’expérience acquise (l’empirisme) à la fin du Sprint.
L’incrément est un pas en avant vers la vision ou l’objectif. Il doit être dans un état utilisable,
quelle que soit la décision du Product Owner de le mettre en service ou non.
Transparence des Artefacts
Scrum repose sur la transparence. Les décisions visant à optimiser la valeur et contrôler le
risque sont prises en fonction de l'état perçu des artefacts. Dans la mesure où la transparence
est complète, ces décisions ont une base solide. Si les artefacts ne sont pas complètement
transparents, ces décisions peuvent être faussées, la valeur peut diminuer et le risque
augmenter.
Le Scrum Master doit travailler avec le Product Owner, l'Équipe de Développement, et les
autres parties concernées, pour comprendre si les artefacts sont totalement transparents. Il
existe des pratiques pour faire face à une transparence incomplète ; le Scrum Master doit
aider chacun à appliquer les pratiques les plus appropriées en l'absence d’une totale
transparence. Un Scrum Master peut détecter une transparence partielle en inspectant les
artefacts, par la détection de schémas récurrents, par l'écoute attentive de ce qui est dit, et
par la détection des différences entre les résultats prévus et réels.
©2017 Ken Schwaber and Jeff Sutherland. Cette œuvre est mise à disposition sous les termes de la licence Attribution-Partage
dans les mêmes conditions consultables sur http://creativecommons.org/licenses/by-sa/4.0/legalcode et résumées sur
http://creativecommons.org/licenses/by-sa/4.0/. En utilisant ce Guide Scrum, vous reconnaissez que vous l’avez lu et que vous
avez accepté de respecter les termes de la licence Attribution-Partage dans les mêmes conditions de Creative Commons.
Page | 18

19. Le rôle du Scrum Master est de travailler avec l'Équipe Scrum et l'organisation afin d'accroître
la transparence des artefacts. Ce travail implique généralement de l’apprentissage, de la
persuasion, et du changement. La transparence n’émerge pas seule, c’est un chemin.
Définition de « Fini »
Quand un élément de Backlog de Produit ou un Incrément est qualifié de « Fini », tous
doivent comprendre ce que « Fini » signifie. Même si le sens varie de façon importante d’une
Équipe Scrum à une autre, les membres doivent avoir une compréhension commune de ce
que signifie un travail terminé, afin d’assurer la transparence. Cette compréhension commune
constitue la définition de « Fini » pour l’Équipe Scrum ; elle est utilisée pour évaluer que le
travail est terminé sur un Incrément de produit.
La même définition aide l’Équipe de Développement à savoir combien d’éléments du Backlog
de Produit elle peut choisir durant la Planification du Sprint. Le but de chaque Sprint est de
produire des Incréments de fonctionnalités potentiellement déployables qui correspondent à
la définition actuelle de « Fini » de l’Équipe Scrum.
Les Équipes de Développement livrent un Incrément de fonctionnalités de produit à chaque
Sprint. Cet Incrément est utilisable, de telle sorte que le Product Owner puisse choisir de le
mettre immédiatement en production. Si la Définition de « Fini » d’un Incrément fait partie
des conventions, des standards ou des règles de l’organisation en charge du développement,
toutes les équipes doivent la respecter au minimum.
Si « Fini » pour un Incrément n’est pas une convention de l’organisation en charge des
développements, l’Équipe de Développement de l’Équipe Scrum doit définir une Définition de
« Fini » appropriée au produit. S’il y a plusieurs équipes Scrum travaillant sur un même
système ou version de produit, les Équipes de Développement de toutes les Équipes Scrum
doivent mutuellement définir une définition de « Fini ».
Chaque Incrément s’additionne à tous les incréments précédents et fait l’objet de tests
approfondis, assurant ainsi que tous les Incréments fonctionnent ensemble.
Au fur et à mesure de la maturité des Équipes Scrum, on s’attend à ce que leur définition de
« Fini » s’étende progressivement pour inclure des critères plus rigoureux, permettant un
niveau de qualité plus élevé. Les nouvelles définitions découlent de la découverte de travail à
faire sur la base des incréments précédents « Finis ». Tout produit ou système doit avoir une
définition de « Fini » qui est standard pour tout travail effectué dessus.
©2017 Ken Schwaber and Jeff Sutherland. Cette œuvre est mise à disposition sous les termes de la licence Attribution-Partage
dans les mêmes conditions consultables sur http://creativecommons.org/licenses/by-sa/4.0/legalcode et résumées sur
http://creativecommons.org/licenses/by-sa/4.0/. En utilisant ce Guide Scrum, vous reconnaissez que vous l’avez lu et que vous
avez accepté de respecter les termes de la licence Attribution-Partage dans les mêmes conditions de Creative Commons.
Page | 19

20. Conclusion
Scrum est libre et il vous est offert dans ce guide. Les rôles, les artefacts, les évènements et les
règles de Scrum sont immuables, et bien qu'une mise en œuvre partielle de Scrum soit
possible, le résultat ne serait pas pour autant Scrum. Scrum n'existe que dans son intégralité
et fonctionne bien en tant que conteneur d'autres techniques, méthodologies et pratiques.
Remerciements
Personnes
Parmi les milliers de personnes qui ont contribué à Scrum, nous devrions distinguer celles qui
ont contribué dès le début : Jeff Sutherland, travaillant avec Jeff McKenna et John
Scumniotales, et Ken Schwaber, en collaboration avec Mike Smith et Chris Martin, puis tous
ensemble. Plusieurs autres ont contribué au cours des années suivantes et, sans leur aide,
Scrum ne serait pas aussi raffiné aujourd'hui.
Histoire
Ken Schwaber et Jeff Sutherland ont travaillé sur Scrum jusqu’en 1995, année lors de laquelle
ils ont co-présenté Scrum pour la première fois à la conférence OOPSLA. Cette présentation
documente essentiellement l'apprentissage que Ken et Jeff ont fait au cours des années
précédentes en mettant Scrum en application, et a rendu publique la première définition
formelle de Scrum.
L'histoire de Scrum est décrite dans d’autres documents. Nous sommes particulièrement
reconnaissants envers Individual Inc, Newspage, Fidelity Investments et IDX (maintenant GE
Medical), où Scrum a été essayé et raffiné pour la première fois.
Le Guide Scrum documente Scrum tel qu’il a été développé, a évolué et a été maintenu
depuis plus de 20 ans par Jeff Sutherland and Ken Schwaber. D’autres sources vous proposent
des patterns, des processus ainsi que des idées complétant le cadre Scrum. Ces compléments
peuvent permettre de gagner en productivité, valeur, créativité et satisfaction au vu des
résultats.
©2017 Ken Schwaber and Jeff Sutherland. Cette œuvre est mise à disposition sous les termes de la licence Attribution-Partage
dans les mêmes conditions consultables sur http://creativecommons.org/licenses/by-sa/4.0/legalcode et résumées sur
http://creativecommons.org/licenses/by-sa/4.0/. En utilisant ce Guide Scrum, vous reconnaissez que vous l’avez lu et que vous
avez accepté de respecter les termes de la licence Attribution-Partage dans les mêmes conditions de Creative Commons.
Page | 20

21. Traduction
Version 2017
En plus des ajouts inhérents à ceux du texte original, la traduction de cette version 2017 a fait
l'objet d'une relecture complète de la part de Fabrice Aimetti, Claude Aubry, Laurent
Carbonnaux et Nicolas Mereaux des Traducteurs Agiles (http://www.les-traducteurs-
agiles.org). La 1ère version de cette nouvelle traduction a été publiée le 12 novembre 2017.
Suite à relecture de Bertrand Uhrig, une 2ème version a vu le jour le 19 décembre 2017.
Version 2016
En plus des ajouts inhérents à ceux du texte original, la traduction de cette version 2016 a fait
l'objet d'une relecture complète de la part de Fabrice Aimetti, Claude Aubry, Laurent
Carbonnaux et Nicolas Mereaux des Traducteurs Agiles (http://www.les-traducteurs-
agiles.org).
Version 2013
Cette version 2013 a été traduite en mars 2014 par Nicolas Mereaux, Laurent Carbonnaux,
Fabien Bataille et Claude Aubry des Traducteurs Agiles (http://www.les-traducteurs-
agiles.org). Nous sommes repartis des travaux de la première traduction en 2011 et des
traductions non officielles qui nous ont précédées. Nous avons remis certains termes anglais,
leur usage étant devenu courant, même en France, grâce à la Communauté Agile française.
Version 2011
L'utilisation du genre masculin a été adoptée afin de faciliter la lecture et n'a aucune intention
discriminatoire. Ce guide a été traduit de la version originale anglaise, fourni par Ken
Schwaber et Jeff Sutherland. Les contributeurs à la traduction incluent : Nathalie
Beauguerlange, Bruno Bouchard, David Beaumier, Félix-Antoine Bourbonnais, Emmanuel
Etasse, Nicolas Desjardins, Jean-François Gilbert, Olivier Gourment, Martin Goyette, Philippe
Hertzog, Christine Lambert, Éric Mignot, Pierre Neis, Timothée Pourbaix, Jean-François Proulx,
Pascal Roy et Vincent Tencé.
©2017 Ken Schwaber and Jeff Sutherland. Cette œuvre est mise à disposition sous les termes de la licence Attribution-Partage
dans les mêmes conditions consultables sur http://creativecommons.org/licenses/by-sa/4.0/legalcode et résumées sur
http://creativecommons.org/licenses/by-sa/4.0/. En utilisant ce Guide Scrum, vous reconnaissez que vous l’avez lu et que vous
avez accepté de respecter les termes de la licence Attribution-Partage dans les mêmes conditions de Creative Commons.
Page | 21