Académique Documents
Professionnel Documents
Culture Documents
Juillet 2013
2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-
Alike license of Creative Commons. Page | 2
Suivi de la progression dun Sprint ....................................................................................... 16
Incrment ................................................................................................................................. 16
La transparence des artfacts .................................................................................................. 16
Dfinition de termin ..................................................................................................... 17
Conclusion .................................................................................................................................... 17
Remerciements ............................................................................................................................ 17
Les personnes ........................................................................................................................... 17
Historique ................................................................................................................................. 18
Traduction ................................................................................................................................ 18
Changements entre les guides Scrum de 2011 et 2013 ................................................................ 19
2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-
Alike license of Creative Commons. Page | 3
Raison dtre du Guide Scrum
Scrum est un cadre de travail pour le dveloppement et la maintenance de produits
complexes. Ce guide dfinit Scrum; cette dfinition se compose des rles, des vnements
et des artfacts de Scrum, ainsi que des rgles qui les lient. La version originale du Guide
Scrum (Scrum Guide) est luvre de Ken Schwaber et Jeff Sutherland, les crateurs de
Scrum. Ce guide en est la traduction en franais.
Dfinition de Scrum
Scrum (n) : un cadre de travail permettant de rpondre des problmes complexes et
changeants, tout en livrant de manire productive et crative des produits de la plus grande
valeur possible.
Scrum est :
Lger
Simple comprendre
Difficile matriser
Scrum est utilis depuis le dbut des annes 1990 pour grer le dveloppement de produits
complexes. Scrum nest pas en soi un processus ni une mthode de dveloppement de
produits; cest un canevas pour lapplication de divers procds et techniques de
dveloppement. Scrum met en vidence lefficacit relative des pratiques de gestion et de
dveloppement de produit en place, de sorte que ces dernires puissent tre amliores.
Scrum se compose de plusieurs lments que sont lquipe Scrum et ses rles associs, les
vnements, les artfacts et les rgles. Chaque lment a une raison dtre spcifique qui le
rend indispensable la russite de lapplication de Scrum.
Les rgles de Scrum sont les modalits qui lient vnements, rles et artfacts entre eux.
Ces rgles sont dcrites tout au long de ce document.
Les diffrentes tactiques dutilisation de Scrum, qui sont nombreuses et varies, ne sont pas
couvertes par ce document.
Thorie de Scrum
Scrum se base sur la thorie du contrle empirique de processus, ou lempirisme.
Lempirisme soutient que les connaissances proviennent de lexprience et dune prise de
dcision base sur des faits connus. Scrum utilise une approche itrative et incrmentale
pour optimiser la prdictibilit et pour contrler le risque.
2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-
Alike license of Creative Commons. Page | 4
Transparence
Les aspects importants du processus doivent tre visibles ceux qui sont responsables des
retombes. La transparence requiert la dfinition dun standard commun pour ces aspects
afin que les observateurs partagent une comprhension commune de ce qui est observ.
titre dexemple :
Un langage commun dcrivant le processus doit tre partag par tous les
participants ; et,
Ceux qui effectuent le travail et ceux qui en acceptent le rsultat doivent partager
une dfinition commune de Termin .
Inspection
Les utilisateurs de Scrum doivent frquemment inspecter les artfacts Scrum et ltat
davancement par rapport un objectif de Sprint (Sprint Goal) afin de dtecter les carts
indsirables. La frquence de ces inspections ne devrait pas gner le travail en cours. Ces
inspections sont bnfiques lorsquelles sont effectues de manire diligente sur les lieux
du travail par les personnes qualifies.
Adaptation
Si un inspecteur dtermine quun ou plusieurs aspects du processus drivent hors des
limites acceptables, et que le produit qui en rsulte sera inacceptable, le processus ou le
matriel utilis par le processus doit tre ajust. Un ajustement doit tre fait ds que
possible afin de minimiser le risque dautres drives.
Scrum prescrit quatre occasions formelles dinspection et dadaptation, tel que dcrit dans
la section Evnements Scrum de ce document :
Lquipe Scrum
Lquipe Scrum comprend un propritaire de produit (Product Owner), une quipe de
Dveloppement (Development Team) et un Scrum Master. Les quipes Scrum (Scrum
Teams) sont auto-organises et pluridisciplinaires. Les quipes auto-organises choisissent
la meilleure faon daccomplir leur travail, au lieu dtre diriges par des personnes
externes lquipe. Les quipes pluridisciplinaires ont toutes les comptences ncessaires
pour effectuer le travail sans dpendre de personnes nappartenant pas lquipe. Scrum
dfinit un modle dquipe optimisant la flexibilit, la crativit et la productivit.
2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-
Alike license of Creative Commons. Page | 5
Les quipes Scrum livrent des produits de manire itrative et incrmentale, maximisant
ainsi les occasions de rtroaction. Les livraisons incrmentales dun produit Termin
assurent la disponibilit dune version fonctionnelle et potentiellement utile du produit.
Le Product Owner
Le Product Owner est responsable de maximiser la valeur du produit et du travail de
lquipe de Dveloppement. La faon de jouer ce rle peut varier grandement selon les
entreprises, les quipes Scrum et les individus.
Le Product Owner est la seule personne responsable de grer le carnet de produit (Product
Backlog). La gestion du Product Backlog comprend :
Le Product Owner peut lui-mme accomplir les tches susmentionnes ou les dlguer
lquipe de Dveloppement. Toutefois, le Product Owner demeure responsable de ces
dernires.
Le Product Owner est une personne, et non un comit. Le Product Owner peut reprsenter
les dsirs dun comit dans le Product Backlog, mais ceux qui veulent changer la priorit
dun item du Product Backlog doivent consulter le Product Owner.
Afin que le Product Owner russisse dans sa dmarche, tous les intervenants de lentreprise
doivent respecter ses dcisions. Les dcisions du Product Owner sont visibles dans le
contenu et lordonnancement du Product Backlog. Nul nest permis de demander lquipe
de Dveloppement de travailler partir dun autre ensemble de besoins, et il nest pas
permis lquipe de Dveloppement de suivre les instructions dune autre personne.
Lquipe de Dveloppement
Lquipe de Dveloppement est constitue de professionnels qui livrent chaque Sprint un
incrment termin et potentiellement livrable du produit. Seuls les membres de lquipe
de Dveloppement crent lincrment.
2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-
Alike license of Creative Commons. Page | 6
Elle est auto-organise. Nul (mme pas le Scrum Master) nindique lquipe de
Dveloppement comment transformer les items du Product Backlog en incrments
de fonctionnalits potentiellement livrables.
Elle est pluridisciplinaire, avec toutes les comptences ncessaires pour crer un
incrment du produit ;
Scrum ne reconnat aucun titre aux membres de lquipe de Dveloppement autre
que celui de dveloppeur, indpendamment du travail effectu par cette personne ;
il ny a pas dexception cette rgle ;
Scrum ne reconnat pas dquipes lintrieur de lquipe de Dveloppement
indpendamment des domaines spcifiques qui doivent tre couverts tels que
lexcution de tests ou lanalyse fonctionnelle ; il ny a pas dexception cette rgle ;
et,
Les membres de lquipe de Dveloppement peuvent dtenir individuellement des
comptences et des centres dintrt spcifiques, mais cest lquipe de
Dveloppement dans son ensemble qui est tenue responsable.
Le Scrum Master
Le Scrum Master est responsable de sassurer que Scrum est compris et mis en uvre. Les
Scrum Masters remplissent leur rle en sassurant que lquipe Scrum adhre la thorie,
aux pratiques et aux rgles de Scrum.
Le Scrum Master est un leader au service de lquipe Scrum. Le Scrum Master aide ceux qui
sont externes lquipe Scrum comprendre lesquelles de leurs interactions avec lquipe
Scrum sont bnfiques et lesquelles ne le sont pas. Le Scrum Master aide tout le monde
changer ces interactions pour maximiser la valeur cre par lquipe Scrum.
Mis part le Sprint, qui contient tous les autres vnements, chaque vnement de Scrum
est une occasion dinspecter et dadapter quelque chose. Ces vnements sont conus
spcifiquement pour permettre transparence et inspection. Le dfaut dinclure nimporte
lequel de ces vnements rsulte en une rduction de la transparence et constitue une
occasion rate dinspection et dadaptation.
Le Sprint
Au cur de Scrum, le Sprint a une dure dun mois ou moins au cours duquel une version
termine , utilisable et potentiellement livrable du logiciel est cre. Il est prfrable que
2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-
Alike license of Creative Commons. Page | 8
les Sprints gardent une dure constante tout au long de linitiative de dveloppement. Un
nouveau Sprint dbute immdiatement aprs la conclusion du prcdent.
Les Sprints contiennent et sont constitus de la planification du Sprint (Sprint Planning), des
mles quotidiennes (Daily Scrums), des activits de dveloppement, de la revue du Sprint
(Sprint Review) et de la rtrospective du Sprint (Sprint Retrospective).
Pendant le sprint :
Lobjectif du sprint est fixe; les changements qui le remettent en cause ne sont donc
pas permis ;
Les objectifs de qualit sont maintenus; ils ne sont jamais revus la baisse ; et,
Chaque Sprint peut tre considr comme un projet qui dure au maximum un mois.
linstar du projet, le Sprint est utilis pour raliser un objectif. La dfinition des
fonctionnalits dvelopper, la conception et le plan flexible qui guidera le dveloppement,
lactivit de dveloppement en soi et le produit rsultant sont associs au Sprint.
La dure dun Sprint est limite un mois calendaire. Lorsque lchance dun Sprint est
trop loigne, la dfinition de ce qui est dvelopper peut changer et cela peut accrotre la
complexit et le risque. Les Sprints amnent de la prvisibilit en forant une inspection et
adaptation du progrs vers latteinte dun objectif au moins mensuellement. Les Sprints
limitent galement le risque financier un mois calendaire.
On peut annuler un Sprint si lobjectif vis devient obsolte. Ceci peut se produire si
lorganisation change de direction ou si les conditions du march ou technologiques
changent. En gnral, un Sprint doit tre annul si son objectif na plus de sens compte tenu
des circonstances. Cependant, vu la courte dure dun Sprint, son annulation est rarement
justifiable.
Quand un Sprint est annul, tous les items termins et complts du Product Backlog sont
passs en revue. Si une partie du travail est potentiellement livrable, le Product Owner
laccepte. Tous les items non Termins sont estims nouveau et rinsrs dans le
Product Backlog. Le travail effectu en vue de complter les items du Product Backlog se
dprcie rapidement et doit tre frquemment r-estim.
Les annulations de Sprint consomment des ressources puisque tout le monde doit se
regrouper dans une autre rencontre de planification de Sprint afin de commencer un
2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-
Alike license of Creative Commons. Page | 9
nouveau Sprint. Les annulations de Sprint sont souvent bouleversantes pour lquipe Scrum
et sont trs peu frquentes.
Planification de Sprint
Le travail effectuer durant le Sprint est labor la runion de planification de Sprint. Ce
plan est cr de manire collaborative par tous les membres de lquipe Scrum.
La planification dun Sprint dun mois est limite 8 heures. Pour les sprints plus courts, elle
dure habituellement moins longtemps.
Le Scrum Master veille ce que lvnement ait lieu et que les participants en comprennent
le but. Le Scrum Master enseigne lquipe Scrum comment respecter la limite de temps
associe cet vnement.
Une fois que lquipe de Dveloppement a dtermin les items du Product Backlog quelle
prvoit de livrer, lquipe Scrum dtermine lobjectif du Sprint. Il sagit dun objectif qui,
travers limplmentation des items du Product Backlog choisis, sera atteint durant le Sprint
et qui fournit lquipe de Dveloppement la raison pour laquelle elle dveloppe
lincrment.
Le Product Owner peut aider clarifier les items du Product Backlog choisis et faire des
compromis. Si lquipe de Dveloppement dtermine quelle a trop ou pas assez de travail,
elle peut rengocier les items du Product Backlog choisis avec le Product Owner. Lquipe
de Dveloppement peut galement inviter dautres personnes la runion afin de recevoir
des conseils techniques ou lis au domaine.
Objectif du Sprint
Lobjectif du Sprint est un but fix pour le Sprint et peut tre ralis par limplmentation
dune partie du Product Backlog. Il fournit lquipe de Dveloppement la raison pour
laquelle elle construit lincrment du produit. Il est cr lors de la runion de planification
du Sprint. Lobjectif du Sprint fournit lquipe de Dveloppement une certaine flexibilit
quant la fonctionnalit implmente durant le Sprint. Les items du Product Backlog
slectionns offrent un fonctionnement cohrent, ce qui peut faire office dobjectif de
Sprint. Par ailleurs, lobjectif de sprint peut tre toute autre source de cohsion poussant
lquipe de Dveloppement travailler ensemble au lieu dentreprendre des initiatives
distinctes.
Mle quotidienne
La mle quotidienne (Daily Scrum) est un vnement limit 15 minutes au cours duquel
lquipe de Dveloppement synchronise ses activits et cre un plan pour les prochaines 24
heures. Pour ce faire, lquipe inspecte le travail effectu depuis la dernire mle
quotidienne et envisage le travail qui peut tre ralis dici la prochaine.
La mle a lieu tous les jours la mme heure et au mme endroit afin de rduire la
complexit. Durant la runion, les membres de lquipe de Dveloppement dcrivent :
2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-
Alike license of Creative Commons. Page | 11
Ce quils raliseront aujourdhui pour aider lquipe de Dveloppement atteindre
lobjectif du Sprint ;
Les obstacles qui, selon eux, les empchent ou empche lquipe de Dveloppement
datteindre lobjectif du Sprint.
Le Scrum Master sassure que la mle quotidienne a lieu, mais cest lquipe de
Dveloppement qui est responsable de son droulement. Le Scrum Master apprend
lquipe de Dveloppement comment limiter la mle quotidienne 15 minutes.
Le Scrum Master veille lapplication de la rgle stipulant que seuls les membres de
lquipe de Dveloppement participent la mle quotidienne.
Revue du Sprint
Une revue de Sprint est tenue la fin du Sprint pour inspecter lincrment ralis et adapter
le Product Backlog si ncessaire. Pendant la runion de revue de Sprint, l'quipe Scrum et
les parties prenantes changent sur ce qui a t fait durant le Sprint. En se basant l-dessus,
et en considrant les changements au Product Backlog effectus durant le Sprint, les
participants collaborent pour dterminer les prochains items ayant le plus de valeur qui
pourraient tre faits. Cette runion se veut informelle, pas une runion de pilotage, et la
prsentation de l'incrment est destine susciter des ractions et favoriser la
collaboration.
Cette runion est limite une bote de temps de quatre heures pour un Sprint dun mois.
Pour les Sprints moins long, la revue de Sprint dure gnralement moins longtemps. Le
Scrum Master sassure que la revue a lieu et que les participants en comprennent le but. Le
Scrum Master apprend tous comment respecter la bote de temps.
Les participants incluent lquipe Scrum et les parties prenantes cls que le Product
Owner a invit ;
2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-
Alike license of Creative Commons. Page | 12
Le Product Owner explique les items du Product Backlog qui ont t termins et
ceux qui ne lont pas t ;
Lquipe de Dveloppement discute de ce qui sest bien droul durant le Sprint,
quels problmes ont t rencontrs, et comment ces problmes ont t rsolus ;
L'quipe de Dveloppement dmontre le travail termin et rpond aux
questions sur l'incrment ;
Le Product Owner discute du Product Backlog tel qu'il est. Il dtermine des dates
probables dachvement en fonction des progrs ce jour ;
L'ensemble du groupe convient de ce qu'il faut faire pour la suite, de sorte que la
revue de Sprint fournisse une contribution prcieuse aux runions de planification
de Sprint subsquentes ;
Une revue de la faon dont les conditions de march ou un usage potentiel du
produit pourrait avoir dict ce quil conviendrait mieux de faire dornavant ;
Une revue des dlais, budget, fonctionnalits potentielles et conditions du march
pour la prochaine livraison du produit.
Le rsultat de la revue de Sprint est un Product Backlog rvis qui dfinit les items probables
pour le prochain Sprint. Le Product Backlog peut galement tre compltement revu pour
rpondre de nouvelles occasions daffaires.
Rtrospective de Sprint
La rtrospective de Sprint (Sprint Retrospective) est une occasion pour l'quipe Scrum de
s'inspecter et de crer un plan d'amlioration qui sera mis en place au cours du Sprint
suivant.
Dinspecter la manire dont le dernier Sprint s'est droul en ce qui concerne les
personnes, les relations, les processus et les outils ;
Didentifier et ordonner les lments majeurs qui se sont bien drouls et les
amliorations potentielles ;
De crer un plan pour amliorer les processus de travail de l'quipe Scrum.
Le Scrum Master encourage l'quipe Scrum amliorer, dans le cadre Scrum, son processus
de dveloppement et ses pratiques afin de les rendre plus efficaces et agrables pour le
prochain Sprint. Lors de chaque rtrospective de Sprint, l'quipe Scrum planifie des moyens
adquats d'accrotre la qualit du produit, en adaptant sa dfinition de termin .
2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-
Alike license of Creative Commons. Page | 13
la fin de la rtrospective de sprint, l'quipe Scrum devrait avoir identifi les amliorations
qu'elle mettra en uvre durant le prochain sprint. La mise en uvre de ces amliorations
au cours du prochain sprint est l'adaptation l'inspection de l'quipe de Dveloppement
elle-mme. Bien que des amliorations puissent tre mises en uvre tout moment, la
rtrospective de sprint fournit un vnement ddi et ax sur l'inspection et l'adaptation.
Product Backlog
Le Product Backlog est une liste ordonne de tout ce qui pourrait tre requis dans le produit
et est lunique source des besoins pour tous les changements effectuer sur le produit. Le
Product Owner est responsable du Product Backlog dans son contenu, sa disponibilit et son
ordonnancement.
Un Product Backlog nest jamais complet. Ses toutes premires moutures ne font
quesquisser les besoins tels quinitialement connus et compris. Le Product Backlog volue
au fur et mesure que le produit et le contexte dans lequel il sera utilis voluent. Le
Product Backlog est dynamique ; il change constamment pour identifier ce que le produit
requiert pour tre appropri, comptitif et utile. Tant et aussi longtemps quun produit
existe, son Product Backlog correspondant existe.
mesure quun produit est utilis, que sa valeur augmente et que lon commence
recevoir des retours sur son utilisation, le Product Backlog grossit et devient plus exhaustif.
Les besoins narrtent jamais de changer, ce qui fait du Product Backlog un document
vivant. Les changements au niveau des besoins utilisateurs, des conditions du march ou de
la technologie peuvent impacter le Product Backlog.
Il arrive souvent que plusieurs quipes Scrum travaillent sur le mme produit. Un seul
Product Backlog est utilis pour dcrire le travail faire sur ce produit. On peut alors ajouter
une proprit aux items du Product Backlog pour les regrouper.
Les premiers items du Product Backlog sont gnralement plus dtaills que les suivants.
Leur estimation est plus prcise d une plus grande clart et un niveau de dtail accru. Les
items qui sont placs plus loin dans le Product Backlog sont moins dtaills. Les items qui
occuperont lquipe de Dveloppement durant le prochain Sprint sont affins au point que
nimporte lequel peut tre raisonnablement Termin dans un Sprint. Ces items sont
rputs Prts pour leur slection dans une planification de Sprint. Les items du Product
Backlog acquirent ce degr de transparence grce aux activits daffinage dcrites plus
haut.
Diverses pratiques de projections des tendances telles que les burn-down , les burn-
ups ont t utilises afin de prvoir la progression. Ces pratiques ont prouv leur utilit.
Toutefois, elles ne remplacent pas limportance de lempirisme. Dans les environnements
complexes, ce qui se passera est inconnu. Seul ce qui sest pass peut tre utilis pour la
prise de dcision prospective.
Sprint Backlog
Le Sprint Backlog est lensemble des items slectionns pour le Sprint plus un plan pour
livrer lincrment du produit et raliser lobjectif du Sprint. Le Sprint Backlog est une
prvision que lquipe de Dveloppement fait de la fonctionnalit qui sera prsente dans le
prochain incrment et le travail ncessaire pour livrer cette fonctionnalit dans un
incrment termin .
Le Sprint Backlog rend visible tout le travail que lquipe de Dveloppement identifie
comme ncessaire pour atteindre lobjectif du Sprint.
Le Sprint Backlog est un plan suffisamment dtaill pour que la progression soit
comprhensible lors de la mle quotidienne. Lquipe modifie le Sprint Backlog tout au
long du Sprint et le Sprint Backlog merge durant le Sprint. Cette mergence a lieu alors
2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-
Alike license of Creative Commons. Page | 15
mme que lquipe de Dveloppement excute le plan et dcouvre le travail ncessaire
pour atteindre le but du Sprint.
Incrment
L'incrment est constitu des lments du Product Backlog termins pendant le sprint ainsi
que de la valeur cumulative des incrments livrs dans les sprints prcdents. A la fin dun
Sprint, le nouvel incrment doit tre termin , ce qui implique quil doit tre dans un tat
utilisable et quil correspond la dfinition de termin de lquipe de Dveloppement. Il
doit tre dans un tat utilisable, sans gard la dcision du Product Owner de le rendre
disponible ou non.
Le Scrum Master doit travailler avec le Product Owner, lquipe de Dveloppement et les
autres parties impliques afin de dterminer si les artfacts sont compltement
transparents. Il y a des pratiques pour faire face une transparence incomplte ; le Scrum
Master doit aider tout le monde appliquer les pratiques les plus appropries dans
labsence dune transparence complte. Un Scrum Master peut dtecter une transparence
incomplte en inspectant les artfacts, en identifiant certains usages rcurrents, en
coutant attentivement ce qui est dit et en dtectant des diffrences entre les rsultats
attendus et les rsultats rels.
Chaque incrment sadditionne tous les incrments prcdents et fait lobjet de tests
approfondis, assurant ainsi que tous les incrments fonctionnent ensemble.
Au fur et mesure que les quipes Scrum prennent de la maturit, on sattend ce que leur
dfinition de termin inclue progressivement des critres plus rigoureux, permettant un
niveau de qualit plus lev. Tout systme ou produit devrait avoir une dfinition de
termin standard pour tous les travaux effectus.
Conclusion
Scrum est gratuit et offert dans ce guide. Ses rles, artfacts, vnements et rgles sont
immuables et bien quune mise en uvre partielle de Scrum soit possible, le rsultat ne sera
pas Scrum. Scrum n'existe que dans son intgralit et fonctionne bien en tant que
conteneur pour d'autres techniques, mthodologies et pratiques.
Remerciements
Les personnes
Parmi les milliers de personnes qui ont contribu Scrum, nous devrions distinguer ceux qui
ont contribu aux dix premires annes. D'abord il y a Jeff Sutherland, travaillant avec Jeff
2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-
Alike license of Creative Commons. Page | 17
McKenna, et Ken Schwaber, en collaboration avec Mike Smith et Chris Martin. Plusieurs
autres ont contribu au cours des annes suivantes et sans leur aide, Scrum ne serait pas
aussi raffin aujourd'hui. David Starr a fourni des informations cls et des comptences
rdactionnelles dans la formulation de cette version du Scrum Guide.
Historique
Ken Schwaber et Jeff Sutherland ont conjointement prsent Scrum pour la premire fois
la confrence OOPSLA en 1995. Cette prsentation documente essentiellement
l'apprentissage que Ken et Jeff ont fait au cours des annes prcdentes passes mettre
en application Scrum.
L'histoire de Scrum est dj considre comme longue. Pour honorer les premiers endroits
o Scrum a t essay et raffin, nous reconnaissons Individual Inc, Fidelity Investments, et
IDX (maintenant GE Medical).
Traduction
L'utilisation du genre masculin a t adopte afin de faciliter la lecture et n'a aucune
intention discriminatoire.
Ce guide a t traduit de la version originale anglaise, fournie par Ken Schwaber et Jeff
Sutherland. Les contributeurs la traduction incluent Olivier Dugas, Pascal Roy, Vincent
Tenc et Ernst Perpignand.
2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-
Alike license of Creative Commons. Page | 18
Changements entre les guides Scrum de 2011 et 2013
1. Les Artfacts doivent tre transparents afin que les mcanismes dinspection et
dadaptation de Scrum soient efficaces. Une discussion ce sujet a t ajoute.
2. La mle quotidienne est une activit de planification juste--temps de Scrum.
Lentre de cette activit devrait tre la progression de lquipe de Dveloppement
vers lobjectif du Sprint ; la sortie devrait tre une rvision ou un tout nouveau plan
qui optimise les efforts de lquipe de Dveloppement pour atteindre lobjectif du
Sprint. Toutes les conversations ont lieu dans un ton de nous, lquipe... au lieu
de je, le dveloppeur ....
3. La planification du Sprint est maintenant un vnement au lieu dtre divis en deux
sous vnements : Quoi/Comment . Elle dbute par la formulation dun objectif
de Sprint, sensuit la comparaison de ce qui est ncessaire pour atteindre lobjectif
du Sprint avec ce qui est prvu prochainement et la capacit disponible, et
finalement llaboration dun plan pour rencontrer lobjectif du Sprint durant le
Sprint.
4. Le Product Backlog est affin (NdT : lexpression Backlog Grooming est
abandonne). Les items affins du Product Backlog sont transparents, suffisamment
compris et granulaires pour tre considrs la planification de Sprint et tre choisis
pour le Sprint. Les items du Product Backlog ainsi transparents sont dits Prts .
5. Tous les vnements sont soumis une bote de temps. Le temps indiqu est le
maximum de temps allou. Les Sprints de moins dun mois ne ncessitent pas la
dure maximale.
6. Lissue de la revue de Sprint est un Product Backlog potentiellement rorganis de
manire ce que les items ayant le plus de valeur soient probablement slectionns
lors de la prochaine planification de Sprint.
7. La planification de Sprint dfinit les fonctionnalits prsentes dans lincrment
planifi et dcrit comment lquipe de Dveloppement va crer cet incrment. Un
objectif de Sprint est conu pour rsumer laboutissement de ce travail.
2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-
Alike license of Creative Commons. Page | 19