Scrum Guide (FR)

Novembre 2020
Scrum
Le Guide
Ken Schwaber & Jeff Sutherland
Le guide de Référence de Scrum : Les règles du jeu
This document is copyright protected and made available to EMMANUEL DEILLER, emmanuel.deiller@gmail.com
Unauthorized use, duplication, or sharing of this material without written permission from the author/owner is strictly prohibited and considered a copyright breach.
But du guide Scrum
Nous avons développé Scrum au début des années 1990. Nous avons écrit la première version du Guide
Scrum en 2010 pour aider les gens du monde entier à comprendre Scrum. Depuis, nous avons fait évoluer
le Guide grâce à de petites mises à jour fonctionnelles. Ensemble, nous le soutenons (Ensemble, nous
sommes derrière le Guide Scrum).
Le Guide Scrum contient la définition de Scrum. Chaque élément du cadre de travail (Framework) sert un
objectif spécifique qui est essentiel à la valeur globale et aux résultats obtenus avec Scrum. Changer la
conception ou les idées de base de Scrum, omettre des éléments, ou ne pas suivre les règles de Scrum,
dissimule les problèmes et limite les avantages de Scrum, le rendant même potentiellement inutile.
Nous suivons l'utilisation croissante de Scrum dans un monde de plus en plus complexe. Nous sommes
honorés de voir Scrum adopté dans de nombreux domaines comportant un travail essentiellement
complexe, au‐delà du développement de produits logiciels où Scrum trouve ses racines. Au fur et à mesure
que l'utilisation de Scrum se propage, les développeurs, chercheurs, analystes, scientifiques et autres
spécialistes font le travail. Nous utilisons le mot «Developers» dans Scrum non pas pour exclure, mais pour
simplifier. Si vous obtenez de la valeur de Scrum, considérez‐vous comme inclus.
Dans la même mesure que Scrum est utilisé, des modèles, des processus et des idées qui correspondent
au Framework Scrum tel que décrit dans ce document peuvent être trouvés, appliqués et conçus. Leur
description dépasse l'objectif du Guide Scrum car ils sont sensibles au contexte et diffèrent largement
entre les utilisations de Scrum. Ces tactiques à utiliser dans le Framework de Scrum varient
considérablement et sont décrites ailleurs.
Ken Schwaber & Jeff Sutherland Novembre 2020
© 2020 Ken Schwaber and Jeff Sutherland
This publication is offered for license under the Attribution Share‐Alike license of Creative Commons,
accessible at https://creativecommons.org/licenses/by‐sa/4.0/legalcode and also described in summary
form at https://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.
2
But du guide Scrum ....................................................................................................................................... 2
Définition de Scrum ...................................................................................................................................... 4
Théorie Scrum ............................................................................................................................................... 4
Transparence ............................................................................................................................................. 4
Inspection ................................................................................................................................................. 5
Adaptation ................................................................................................................................................ 5
Valeurs Scrum ............................................................................................................................................... 5
Scrum Team................................................................................................................................................... 5
Developers ................................................................................................................................................ 6
Product Owner .......................................................................................................................................... 6
Scrum Master ............................................................................................................................................ 7
Événements Scrum ....................................................................................................................................... 8
Sprint ......................................................................................................................................................... 8
Sprint Planning .......................................................................................................................................... 8
Daily Scrum ............................................................................................................................................... 9
Sprint Review .......................................................................................................................................... 10
Sprint Retrospective ................................................................................................................................ 10
Les Artefacts de Scrum................................................................................................................................ 11
Product Backlog ...................................................................................................................................... 11
Engagement : Objectif de Produit ....................................................................................................... 11
Sprint Backlog ......................................................................................................................................... 12
Engagement : Objectif de Sprint ......................................................................................................... 12
Increment ................................................................................................................................................ 12
Engagement : Definition of Done (Définition de Fini) ......................................................................... 12
Note de fin .................................................................................................................................................. 14
Remerciements ....................................................................................................................................... 14
Personnes ............................................................................................................................................ 14
Historique du guide Scrum.................................................................................................................. 14
Traduction ........................................................................................................................................... 14
Changements entre les versions 2017 et 2020 du Guide Scrum ............................................................ 15
3
Définition de Scrum
Scrum est un Framework léger qui aide les personnes, les équipes et les organisations à générer de la
valeur grâce à des solutions adaptatives pour des problèmes complexes.
En bref, Scrum a besoin d'un Scrum Master pour favoriser un environnement où :

1. Un Product Owner ordonne le travail pour un problème complexe dans le Product Backlog.
2. La Scrum Team transforme une sélection de travail en un Increment de valeur lors d'un Sprint.
3. La Scrum Team et ses parties prenantes inspectent les résultats et s'adaptent pour le prochain
Sprint.
4. Répéter
Scrum est simple. Essayez‐le tel qu'il est et déterminez si sa philosophie, sa théorie et sa structure aident
à atteindre les objectifs et à créer de la valeur. Le Framework Scrum est volontairement incomplet, ne
définissant que les parties nécessaires à la mise en œuvre de la théorie Scrum. Scrum repose sur
l'intelligence collective des personnes qui l'utilisent. Plutôt que de fournir aux gens des instructions
détaillées, les règles de Scrum guident leurs relations et leurs interactions.
Divers processus, techniques et méthodes peuvent être employés dans ce Framework. Scrum englobe les
pratiques existantes ou les rend inutiles. Scrum rend visible l'efficacité relative du management actuel, de
l'environnement et des techniques de travail, afin que des améliorations puissent être apportées.
Théorie Scrum
Scrum est fondé sur l'empirisme et le Lean Thinking. L'empirisme affirme que la connaissance vient de
l'expérience et de la prise de décisions est basée sur des faits observés. Le Lean Thinking réduit le
gaspillage et se focalise sur l'essentiel.
Scrum utilise une approche itérative et incrémentale pour optimiser la prédictibilité et le contrôle de
risque. Scrum engage des groupes de personnes qui ont collectivement toutes les compétences et
l'expertise pour faire le travail et partager ou acquérir ces compétences selon les besoins.
Scrum combine quatre événements formels pour l'inspection et l'adaptation dans un événement
contenant, le Sprint. Ces événements fonctionnent parce qu'ils mettent en œuvre les piliers empiriques
de Scrum qui sont la transparence, l'inspection et l'adaptation.
Transparence
Le processus et le travail émergents doivent être visibles pour ceux qui effectuent le travail ainsi que pour
ceux qui reçoivent le travail. Avec Scrum, les décisions importantes sont fondées sur l'état perçu de ses
trois artefacts formels. Des artefacts peu transparents peuvent mener à des décisions qui diminuent la
valeur et augmentent le risque.
La transparence permet l'inspection. L'inspection sans transparence est fallacieuse et inefficace.
4
Inspection
Les artefacts Scrum et les progressions vers les objectifs convenus doivent être inspectés fréquemment et
avec diligence pour détecter des écarts ou des problèmes potentiellement indésirables. Pour faciliter
l'inspection, Scrum fournit la cadence sous la forme de ses cinq événements.
L'inspection permet l'adaptation. Une inspection sans adaptation est considérée comme infructueuse. Les
événements Scrum sont conçus pour provoquer le changement.
Adaptation
Si certains aspects d'un processus s'écartent des limites acceptables ou si le produit résultant est
inacceptable, le processus appliqué ou les éléments produits doivent être adaptés. L'adaptation doit être
effectuée le plus rapidement possible afin de minimiser tout éventuel écart supplémentaire.
L'adaptation devient plus difficile lorsque les personnes impliquées ne sont pas autonomes ou autogérées.
Une Scrum Team est censée s'adapter dès qu'elle apprend quelque chose de nouveau lors d'une
inspection.
Valeurs Scrum
L'utilisation réussie de Scrum dépend de la capacité des personnes à mieux vivre ces cinq valeurs :
Engagement, focus, ouverture, respect et courage
La Scrum Team s'engage à atteindre ses objectifs et à se soutenir mutuellement. Leur objectif principal est
le travail du Sprint pour progresser le plus possible vers ces objectifs. La Scrum Team et ses parties
prenantes sont ouvertes sur le travail et les défis à relever. Les membres de la Scrum Team se respectent
mutuellement pour être des personnes compétentes et indépendantes, et sont respectés en tant que tels
par les personnes avec lesquelles ils travaillent. Les membres de la Scrum Team ont le courage de faire ce
qu'il faut, de travailler sur des problèmes difficiles.
Ces valeurs orientent la Scrum Team en ce qui concerne son travail, ses actions et son comportement. Les
décisions qui sont faites, les mesures prises et la façon dont Scrum est utilisé devraient renforcer ces
valeurs, et non les diminuer ou les miner. Les membres de la Scrum Team apprennent et explorent les
valeurs en travaillant avec les événements et les artefacts Scrum. Lorsque ces valeurs sont incarnées par
la Scrum Team et les personnes avec lesquelles elle travaille, les piliers empiriques de Scrum de
transparence, d'inspection et d'adaptation émergent en consolidant la confiance.
Scrum Team
L'élément fondamental de Scrum est une petite équipe de personnes, une Scrum Team. La Scrum Team se
compose d'un Scrum Master, d'un Product Owner et de Developers (Développeurs). Au sein de cette
5
équipe, il n'y a pas de sous‐équipes ou de hiérarchies. Il s'agit d'un groupe uni de professionnels focalisés
sur un seul objectif à la fois, l'Objectif de Produit.
Les Scrum Teams sont pluridisciplinaires, ce qui signifie que les membres ont toutes les compétences
nécessaires pour créer de la valeur à chaque Sprint. Ils sont également autogérés, ce qui signifie qu'ils
décident en interne qui fait quoi, quand et comment.
La Scrum Team doit être suffisamment petite pour rester réactive et assez grande pour accomplir un travail
significatif durant le Sprint, habituellement pas plus que de dix personnes. En général, nous avons constaté
que les petites équipes communiquent mieux et sont plus productives. Si les Scrum Teams deviennent
trop grandes, elles devraient envisager de se réorganiser en plusieurs Scrum Teams cohérentes, chacune
axée sur le même produit. Par conséquent, ils doivent partager le même Objectif de Produit, le même
Product Backlog et le même Product Owner.
La Scrum Team est responsable de toutes les activités liées aux produits : collaboration des parties
prenantes, vérification, maintenance, exploitation, expérimentation, recherche et développement, et tout
ce qui pourrait être nécessaire. Ils sont structurés et habilités par l'organisation à gérer leur propre travail.
Travailler dans les Sprints à un rythme soutenable améliore la concentration et la cohérence de l’équipe
Scrum.
Toute la Scrum Team est responsable de la création d'un Increment de valeur et utile durant chaque Sprint.
Scrum définit trois responsabilités spécifiques au sein de la Scrum Team : les Developers (développeurs),
le Product Owner et le Scrum Master.
Developers
Les Developers (développeurs) sont les membres de la Scrum Team qui s'engagent à traiter n'importe quel
aspect utile pour un Increment durant chaque Sprint.
Les compétences spécifiques requises par les Developers sont souvent larges et varient selon le domaine
de travail. Toutefois, les Developers sont toujours responsables de :
● Créer un plan de Sprint, un Sprint Backlog ;
● Inculquer la notion de qualité en adhérant à une Definition of Done ;
● Adapter leur plan chaque jour par rapport à l'Objectif de Sprint ; et,
● Se tenir mutuellement responsables en tant que professionnels.
Product Owner
Le Product Owner est responsable de maximiser la valeur du produit résultant du travail de la Scrum Team.
La manière de procéder peut varier considérablement selon les organisations, les Scrum Teams et les
individus.
Le Product Owner est également responsable de la gestion efficace du Product Backlog, qui comprend :
● Développer et communiquer explicitement l'Objectif de Produit ;
● Créer et communiquer clairement les éléments du Product Backlog ;
● Ordonner les éléments dans le Product Backlog ; et,
● S'assurer que le Product Backlog est transparent, visible et compréhensible.
6
Le Product Owner peut effectuer le travail ci‐dessus ou peut déléguer la responsabilité à d'autres. De toute
façon, le Product Owner en demeure responsable.
Pour que les Product Owners réussissent, toute l'organisation doit respecter leurs décisions. Ces décisions
sont visibles dans le contenu et l'ordre du Product Backlog, et via un Increment vérifiable lors de la Sprint
Review.
Le Product Owner est une personne, et non un comité. Le Product Owner peut représenter les besoins de
nombreuses parties prenantes dans le Product Backlog. Ceux qui souhaitent modifier le Product Backlog
peuvent le faire en essayant de convaincre le Product Owner.
Scrum Master
Le Scrum Master est chargé de mettre en place 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 et la pratique Scrum, à la
fois au sein de la Scrum Team et de l'organisation.
Le Scrum Master est responsable de l’efficacité de l’équipe Scrum. Les Scrum Masters remplissent leur rôle
en permettant à la Scrum Team d'améliorer ses pratiques liées à Scrum.
Les Scrum Masters sont de véritables leaders qui servent la Scrum Team et l'ensemble de l'organisation.
Le Scrum Master sert la Scrum Team de plusieurs façons, y compris :
● Coacher les membres de l'équipe en matière d'autogestion et de pluridisciplinarité ;
● Aider la Scrum Team à se focaliser sur la création d'Increments de grande valeur qui répondent à
la Definition of Done ;
● Supprimer les obstacles liés à la progression de la Scrum Team ; et,
● S'assurer que tous les événements Scrum ont lieu et sont positifs, productifs et gardés dans la
boîte de temps (timeboxés).
Le Scrum Master sert le Product Owner de plusieurs façons, y compris :
● Aider à trouver des techniques pour une définition efficace de l'Objectif de Produit et une gestion
efficace du Product Backlog ;
● Aider la Scrum Team à comprendre le besoin de clarté et concision des éléments du Product
Backlog ;
● Aider à établir la planification de produit dans un contexte empirique dans un environnement
complexe ; et,
● Faciliter la collaboration des parties prenantes, en cas de demande ou nécessité.
Le Scrum Master sert l'organisation de plusieurs façons, y compris :

● Diriger, former et encadrer l'organisation dans son adoption de Scrum ;
● Planifier et conseiller les implémentations de Scrum au sein de l’organisation ;
● Aider les employés et les parties prenantes à comprendre et adopter une approche empirique
pour un travail complexe ; et,
● Supprimer les barrières entre les parties prenantes et les Scrum Teams.
7
Événements Scrum
Le Sprint est un conteneur pour tous les autres événements. Chaque événement dans Scrum est une
occasion formelle d'inspecter et d'adapter les artefacts Scrum. Ces événements sont spécifiquement
conçus pour permettre la transparence requise. Ne pas faire fonctionner les événements comme prescrit
constitue une occasion perdue d'inspection et d'adaptation. Les événements sont utilisés dans Scrum pour
créer la régularité et minimiser le besoin de réunions non définies par Scrum.
Idéalement, tous les événements se tiennent à la même heure et au même lieu pour réduire la complexité.
Sprint
Les Sprints modulent le rythme de Scrum, là où les idées sont transformées en valeur.
Ce sont des événements d'une durée fixe, d'un mois ou moins pour créer une cohérence. Un nouveau
Sprint commence immédiatement après la fin du Sprint précédent.
Tout le travail nécessaire pour atteindre l'Objectif de Produit, y compris la Sprint Planning, les Daily Scrums,
la Sprint Review et la Sprint Retrospective ; se fait dans le cadre des Sprints.
Pendant le Sprint :
● Les changements remettant en cause l'Objectif de sprint ne sont pas permis ;
● Les objectifs de qualité sont maintenus, ils ne sont jamais revus à la baisse ;
● Le Product Backlog est affiné si nécessaire ; et,
● Le périmètre peut être clarifié et renégocié avec le Product Owner selon ce que l’équipe Scrum
apprend.
Les Sprints permettent la prédictibilité en assurant l'inspection et l'adaptation de la progression vers
l'Objectif de Produit au moins tous les mois calendaires. Lorsque l’horizon d’un Sprint est trop long,
l’Objectif de Sprint peut devenir invalide, la complexité peut augmenter et le risque peut s'accroître. Des
Sprints plus courts peuvent être utilisés pour générer plus de cycles d'apprentissage et limiter le risque de
coûts et d'efforts à un délai plus court. Chaque Sprint peut être considéré comme un projet court.
Diverses pratiques telles que les « burn‐downs », les « burn‐ups » ou les « cummulative flows » 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.
Un Sprint peut être annulé si l'Objectif de Sprint devient obsolète. Seul le Product Owner a le pouvoir
d'annuler le Sprint.
Sprint Planning
La Sprint Planning initie le Sprint en présentant le travail à effectuer pour ce Sprint. Ce plan résultant est
créé par un travail collaboratif de toute la Scrum Team.
8
Le Product Owner veille à ce que les participants soient prêts à discuter des éléments du Product Backlog
les plus importants et de la manière dont ils correspondent à l'Objectif de Produit. La Scrum Team peut
également inviter d'autres personnes à participer à la Sprint Planning pour donner des conseils.
La Sprint Planning aborde les thèmes suivants :
Thème 1 : Pourquoi ce Sprint est‐il important ?

Le Product Owner propose comment le produit pourrait augmenter sa valeur et son utilité durant le Sprint
actuel. L'ensemble de la Scrum Team collabore ensuite à la définition d'un Objectif de Sprint qui
communique aux parties prenantes les raisons pour lesquelles le Sprint est utile. L'Objectif de Sprint doit
être finalisé avant la fin de la Sprint Planning.
Thème 2 : Que peut‐on faire ce Sprint ?

En discutant avec le Product Owner, les Developers choisissent des éléments du Product Backlog à inclure
dans le Sprint en cours. La Scrum Team peut affiner ces éléments au cours de ce processus, ce qui renforce
la compréhension et la confiance.
Il peut être difficile de déterminer la quantité de travail qui peut être effectuée durant un Sprint.
Cependant, plus les Developers en savent sur leurs performances passées, leurs capacités à venir et leur
Definition of Done, plus ils seront confiants dans leurs prévisions de Sprint.
Thème 3 : Comment le travail choisi sera‐t‐il réalisé ?

Pour chaque élément choisi du Product Backlog, les Developers planifient le travail nécessaire pour créer
un Increment qui répond à la Definition of Done. Cela se fait souvent en décomposant les éléments du
Product Backlog en éléments de travail d'une journée ou moins. La façon de procéder est laissée à la seule
discrétion des Developers. Personne d'autre ne leur dit comment transformer les éléments du Product
Backlog en Increments de valeur.
L'Objectif de Sprint, les éléments choisis du Product Backlog pour le Sprint, ainsi que le plan pour les livrer
sont appelés ensemble le Sprint Backlog.
La Sprint Planning est limitée dans le temps, en boîte de temps (timeboxée), à un maximum de huit heures
pour un Sprint d'un mois. Pour les Sprints plus courts, l'événement est généralement plus court.
Daily Scrum
L'objectif du Daily Scrum est d'inspecter la progression vers l'Objectif de Sprint et d'adapter le Sprint
Backlog si nécessaire, en ajustant les futurs travaux planifiés.
Le Daily Scrum est un événement de 15 minutes pour les Developers de la Scrum Team. Pour réduire la
complexité, il est tenu à la même heure et au même lieu chaque jour ouvré du Sprint. Si le Product Owner
ou Scrum Master travaille activement sur des éléments du Sprint Backlog, ils participent en tant que
Developers.
9
Les Developers peuvent sélectionner la structure et les techniques de leur choix, à condition que leur Daily
Scrum se focalise sur la progression vers l'Objectif de Sprint et produise un plan d'action pour la prochaine
journée de travail. Cela permet de se focaliser et d'améliorer l'autogestion.
Les Daily Scrums améliorent la communication, identifient les obstacles, favorisent la prise de décision
rapide et, par conséquent, éliminent la nécessité de faire d'autres réunions.
Le Daily Scrum n'est pas le seul moment où les Developers sont autorisés à ajuster leur plan. Ils se
réunissent souvent tout au long de la journée pour des discussions plus détaillées sur l’adaptation ou la
replanification du reste du travail du Sprint.
Sprint Review
L'objectif de la Sprint Review (revue de Sprint) est d'inspecter le résultat du Sprint et de déterminer les
adaptations futures. La Scrum Team présente les résultats de son travail aux principales parties prenantes
et les progressions vers l'Objectif de Produit sont discutés.
Pendant l'événement, la Scrum Team et les parties prenantes passent en revue ce qui a été accompli
durant le Sprint et ce qui a changé dans leur environnement. Sur la base de ces informations, les
participants collaborent sur la marche à suivre. Le Product Backlog peut également être ajusté pour
répondre à de nouvelles opportunités. La Sprint Review est une session de travail et la Scrum Team doit
éviter de la limiter à une session de présentation.
La Sprint Review est l'avant‐dernier événement du Sprint et est limitée dans le temps, en boîte de temps
(timeboxée), à un maximum de quatre heures pour un Sprint d'un mois. Pour les Sprints plus courts,
l'événement est généralement plus court.
Sprint Retrospective
L'objectif de la Sprint Retrospective (rétrospective de Sprint) est de planifier de moyens et méthodes
permettant d'accroître la qualité et l'efficacité.
La Scrum Team inspecte le déroulement du dernier Sprint en ce qui concerne les individus, les interactions,
les processus, les outils et leur Definition of Done. Les éléments inspectés varient souvent selon le
domaine de travail. Les hypothèses qui les ont fait dévier sont identifiées et leurs origines explorées. La
Scrum Team discute de ce qui s'est bien passé pendant le Sprint, des problèmes rencontrés et de la
manière dont ces problèmes ont été (ou n'ont pas été) résolus.
La Scrum Team identifie les changements les plus utiles pour améliorer son efficacité. Les améliorations
ayant le plus d'impact sont abordées dès que possible. Elles peuvent même être ajoutées au Sprint Backlog
pour le prochain Sprint.
La Sprint Retrospective conclut le Sprint. Elle est limitée dans le temps, en boîte de temps (timeboxée), à
un maximum de trois heures pour un Sprint d'un mois. Pour les Sprints plus courts, l'événement est
généralement plus court.
10
Les Artefacts de Scrum
Les artefacts de Scrum représentent un travail ou une valeur. Ils sont conçus pour maximiser la
transparence des informations clés. Ainsi, tous ceux qui les inspectent ont la même base d'adaptation.
Chaque artefact contient un engagement assurant la fourniture des informations qui améliorent la
transparence et le focus par rapport auxquelles les progressions peuvent être mesurées :
● Pour le Product Backlog, il s'agit de l'Objectif de Produit.

● Pour le Sprint Backlog, c'est l'Objectif de Sprint.
● Pour l'Increment, c'est la Definition of Done (définition de Fini).
Ces engagements existent pour renforcer l'empirisme et les valeurs Scrum au sein de la Scrum Team et ses
parties prenantes.
Product Backlog
Le Product Backlog est une liste ordonnée et émergente de ce qui est nécessaire pour améliorer le produit.
C'est la seule source du travail accompli par la Scrum Team.
Les éléments du Product Backlog qui peuvent être traités par la Scrum Team durant un Sprint sont
considérés comme prêts pour la sélection dans un événement de Sprint Planning. Ils acquièrent
généralement ce degré de transparence après avoir été affinés. L'affinement du Product Backlog consiste
à décomposer et à définir davantage les éléments du Backlog en éléments plus fins et plus précis. Il s'agit
d'une activité continue visant à ajouter des détails, tels qu'une description, un ordre et une taille. Les
attributs varient souvent en fonction du domaine de travail.
Les Developers qui effectueront le travail sont responsables du dimensionnement. Le Product Owner peut
influencer les Developers en les aidant à comprendre et trouver des compromis.
Engagement : Objectif de Produit

L'Objectif de Produit décrit un état futur du produit qui peut servir de cible à la Scrum Team pour planifier.
L'Objectif de Produit est dans le Product Backlog. Le reste du Product Backlog émerge pour définir « ce
qui » permettra d'atteindre l'Objectif de Produit.
Un produit est un moyen de créer de la valeur. Il a une frontière claire, des parties prenantes
connues, des utilisateurs ou des clients bien définis. Un produit peut être un service, un produit
physique ou quelque chose plus abstraite.
L'Objectif de Produit est l'objectif à long terme de la Scrum Team. Ils doivent atteindre (ou abandonner)
un objectif avant de s'attaquer au suivant.
11
Sprint Backlog
Le Sprint Backlog est composé de l'Objectif de Sprint (pourquoi), de l'ensemble des éléments du Product
Backlog choisis pour le Sprint (quoi), ainsi que d'un plan d'action pour la réalisation de l'Increment
(comment).
Le Sprint Backlog est un plan élaboré par et pour les développeurs. Il s'agit d'une image très visible et en
temps réel du travail que les Developers prévoient d'accomplir durant le Sprint afin d'atteindre l'Objectif
de Sprint. Par conséquent, le Sprint Backlog est mis à jour tout au long du Sprint selon ce qu'on en apprend.
Il devrait être suffisamment détaillé pour que les Developers puissent inspecter leur progression durant le
Daily Scrum.
Engagement : Objectif de Sprint

L'Objectif de sprint est le seul but du Sprint. Bien que l'Objectif de Sprint soit un engagement fait par les
Developers, il offre une certaine flexibilité en termes de travail nécessaire pour atteindre cet objectif.
L'Objectif de Sprint crée également de la cohérence et du focus, tout en encourageant la Scrum Team à
travailler ensemble plutôt que sur des initiatives séparées.
L'Objectif de Sprint est créé lors l'événement de Sprint Planning, puis ajouté au Sprint Backlog. Pendant
que les Developers travaillent durant le Sprint, ils gardent l'Objectif de Sprint à l'esprit. Si le travail s'avère
être différent de ce à quoi ils s'attendaient, ils collaborent avec le Product Owner pour négocier le
périmètre du Sprint Backlog au sein du Sprint sans affecter l'Objectif de Sprint.
Increment
Un Increment est une première étape concrète vers l'Objectif de Produit. Chaque Increment s'ajoute à
tous les Increments précédents et fait l'objet d'une vérification approfondie, ce qui garantit que tous les
Increments fonctionnent ensemble. Afin de fournir une valeur, l'Increment doit être utilisable.
Plusieurs Increments peuvent être créés durant un Sprint. La somme des Increments est présentée lors de
la Sprint Review, ce qui permet ainsi de soutenir l'empirisme. Toutefois, un Increment peut être livré aux
parties prenantes avant la fin du Sprint. La Sprint Review ne doit jamais être considérée comme une porte
d'accès à la délivrance de la valeur.
Le travail ne peut être considéré comme faisant partie d'un Increment que s'il satisfait à la Definition of
Done.
Engagement : Definition of Done (Définition de Fini)

La Definition of Done (Définition de Fini) est une description formelle de l'état de l'Increment lorsqu'il
satisfait aux mesures de qualité requises pour le produit.
Dès qu'un élément du Product Backlog satisfait à la Definition of Done, un Increment est né.
La Definition of Done crée de la transparence en permettant à chacun de comprendre le travail accompli
dans le cadre de l'Increment. Si un élément du Product Backlog n’est pas conforme à la Definition of Done,
12
il ne peut pas être publié ni même présenté lors de la Sprint Review. Il est alors renvoyé au Product Backlog
pour un examen ultérieur.
Si la Definition of Done pour un Increment fait partie des standards de l'organisation, toutes les Scrum
Teams doivent la suivre au minimum. S'il ne s'agit pas d'une norme de l'organisation, la Scrum Team doit
créer une Definition of Done appropriée pour le produit.
Les Developers sont tenus de se conformer à la Definition of Done. Si plusieurs Scrum Teams travaillent
ensemble sur un produit, elles doivent définir mutuellement et se conformer à la même Definition of
Done.
13
Note de fin
Scrum est gratuit et offert dans ce guide. Le Framework Scrum, tel que décrit ici, est immuable. 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 comme un conteneur pour d'autres techniques, méthodologies et
pratiques.
Remerciements
Personnes
Parmi les milliers de personnes qui ont contribué à Scrum, nous devons distinguer ceux qui ont joué un
rôle déterminant dès le début : 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 affiné comme il l'est
aujourd'hui.
Historique du guide Scrum
Ken Schwaber et Jeff Sutherland ont co‐présenté Scrum pour la première fois à la conférence OOPSLA en
1995. Elle a essentiellement documenté l'apprentissage que Ken et Jeff ont acquis au cours des dernières
années et a rendu publique la première définition formelle de Scrum.
Le Guide Scrum documente Scrum tel qu'il a été développé, évolué et soutenu pendant plus de 30 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.
L'histoire complète de Scrum est décrite ailleurs. Pour honorer les premiers endroits où il a été essayé et
affiné, nous reconnaissons Individual Inc., Newspage, Fidelity Investments et IDX (maintenant GE Medical).
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.
Informations Importantes : L'utilisation du genre masculin et/ou féminin a été adoptée afin de faciliter la
lecture et n'a aucune intention discriminatoire. Conformément aux directives de Scrum.org, les termes
suivants (Scrum, Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, Scrum Team,
Scrum Master, Product Owner, Developer, Product Backlog, Sprint Backlog et Increment) ne doivent pas
être traduits dans le document final. Il a été décidé de fournir un glossaire à la demande.
14
Changements entre les versions 2017 et 2020 du Guide Scrum
Encore moins normatif
Au fil du temps, le Guide Scrum a commencé à devenir un peu plus normatif. La version 2020 visait à
ramener Scrum à un cadre minimalement suffisant en supprimant ou en adoucissant le langage prescriptif.
Par exemple, la suppression des questions Daily Scrum, l’adoucissement du langage autour des attributs
PBI (Product Backlog Items – les éléments du Backlog Produit), l’adoucissement du langage autour des
éléments rétro dans un Sprint Backlog, le raccourcissement de la section d'annulation de Sprint, etc.
Une seule équipe, focalisée sur un seul produit

L'objectif était d'éliminer le concept d'une équipe distincte au sein d'une équipe qui a conduit à un
comportement « proxy » ou « nous et eux » entre le PO et l'équipe de développement. Il n'y a maintenant
qu'une seule équipe Scrum concentrée sur le même objectif, avec trois différents ensembles de
responsabilités : PO, SM et développeurs.
Introduction de l'Objectif de Produit

Le Guide Scrum 2020 introduit le concept de l’Objectif de Produit pour permettre à la Scrum Team de se
focaliser sur un objectif plus important. Chaque Sprint devrait rapprocher le produit de son objectif global.
Un sens pour l'Objectif de Sprint, la Definition of Done et l'Objectif de Produit

Les précédents guides Scrum décrivaient l'Objectif de Sprint et la Definition of Done sans vraiment les
donner une identité. Ils n'étaient pas tout à fait des artefacts, mais étaient quelque peu attachés à des
artefacts. Avec l'ajout du concept de l'Objectif de Produit, la version 2020 apporte plus de clarté à ce sujet.
Chacun des trois artefacts contient désormais des « engagements » à leur égard. Pour le Product Backlog,
il s'agit de l'Objectif de Produit, le Sprint Backlog a un Objectif de Sprint et l'Increment a une Definition of
Done (maintenant sans les guillemets). Ils existent pour apporter de la transparence et se focaliser sur la
progression de chaque artefact.
Autogérée plutôt qu’auto‐organisée

Les guides Scrum précédents appelaient les équipes de développement auto‐organisées, choisissant qui
et comment travailler. En se focalisant davantage sur la Scrum Team, la version 2020 met l'accent sur une
Scrum Team autogérée, en choisissant qui, comment et sur quoi travailler.
Trois thèmes liés à la Sprint Planning

En plus des thèmes « Quoi » et « Comment » de la Sprint Planning, le Guide Scrum 2020 met l'accent sur
un troisième thème, « Pourquoi », faisant référence à l'Objectif de Sprint.
Simplification globale de la langue pour un public plus large

Le Guide Scrum 2020 a mis l'accent sur l'élimination des déclarations redondantes et complexes ainsi que
la suppression de toute déduction éventuelle au travail informatique (par exemple, les tests, le système,
la conception, les exigences, etc.). Le Guide Scrum compte désormais moins de 13 pages.
15

Scrum Guide (FR)

Transféré par

Droits d'auteur :

Formats disponibles

Scrum Guide (FR)

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Scrum Guide (FR)

Transféré par

Droits d'auteur :

Formats disponibles

Novembre 2020

Le guide de Référence de Scrum : Les règles du jeu

© 2020 Ken Schwaber and Jeff Sutherland

En bref, Scrum a besoin d'un Scrum Master pour favoriser un environnement où :

Le Scrum Master sert l'organisation de plusieurs façons, y compris :

La Sprint Planning aborde les thèmes suivants :

Thème 1 : Pourquoi ce Sprint est‐il important ?

Thème 2 : Que peut‐on faire ce Sprint ?

Thème 3 : Comment le travail choisi sera‐t‐il réalisé ?

● Pour le Product Backlog, il s'agit de l'Objectif de Produit.

Engagement : Objectif de Produit

Engagement : Objectif de Sprint

Engagement : Definition of Done (Définition de Fini)

Historique du guide Scrum

Une seule équipe, focalisée sur un seul produit

Introduction de l'Objectif de Produit

Un sens pour l'Objectif de Sprint, la Definition of Done et l'Objectif de Produit

Autogérée plutôt qu’auto‐organisée

Trois thèmes liés à la Sprint Planning

Simplification globale de la langue pour un public plus large

Vous aimerez peut-être aussi