Le Guide Scrum

Le guide dfinitif de Scrum :

les rgles du jeu











Juillet 2013


Dvelopp and maintenu par Ken Schwaber et Jeff Sutherland

1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved Page | 2

Table des matires
Raison dtre du Guide Scrum ......................................................................................................... 4
Dfinition de Scrum ......................................................................................................................... 4
Thorie de Scrum ............................................................................................................................ 4
Transparence ............................................................................................................................... 5
Inspection .................................................................................................................................... 5
Adaptation ................................................................................................................................... 5
Lquipe Scrum ................................................................................................................................ 5
Le Product Owner ........................................................................................................................ 6
Lquipe de dveloppement ........................................................................................................ 6
Taille de lquipe de dveloppement ...................................................................................... 7
Le Scrum Master .......................................................................................................................... 7
Le Scrum Master au service du Product Owner ...................................................................... 7
Le Scrum Master au service de lquipe de dveloppement .................................................. 8
Le Scrum Master au service de lorganisation ......................................................................... 8
Les vnements Scrum .................................................................................................................... 8
Le Sprint ....................................................................................................................................... 8
Annulation dun Sprint ............................................................................................................ 9
Planification de Sprint ................................................................................................................. 9
Premier Sujet: Quest-ce qui peut tre termin au cours de ce sprint ? .............................. 10
Deuxime sujet: comment sera effectu le travail choisi ? .................................................. 10
Objectif du Sprint .................................................................................................................. 11
Mle quotidienne .................................................................................................................... 11
Revue du Sprint ......................................................................................................................... 12
Rtrospective de Sprint ............................................................................................................. 13
Les artfacts de Scrum .................................................................................................................. 14
Product Backlog ......................................................................................................................... 14
Suivi de la progression vers un objectif de dveloppement ................................................. 15
Sprint Backlog ............................................................................................................................ 15
Suivi de la progression dun Sprint ........................................................................................ 16
1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved Page | 3
Incrment .................................................................................................................................. 16
La transparence des artfacts ................................................................................................... 16
Dfinition de termin ...................................................................................................... 16
Conclusion ..................................................................................................................................... 17
Remerciements ............................................................................................................................. 17
Les personnes ............................................................................................................................ 17
Historique .................................................................................................................................. 17
Traduction ................................................................................................................................. 18
Changements entre les guides Scrum de 2011 et 2013 ................................................................ 19


1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved Page | 4
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.
Trois piliers soutiennent limplmentation dun contrle empirique de processus : la
transparence, linspection et ladaptation.
1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved Page | 5
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 :
Planification de Sprint (Sprint Planning)
Mle quotidienne (Daily Scrum)
Revue de Sprint (Sprint Review)
Rtrospective de Sprint (Sprint Retrospective)
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.
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.
1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved Page | 6
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 :
Exprimer clairement les items du Product Backlog ;
Ordonner les items du Product Backlog pour mieux raliser les objectifs et missions ;
Optimiser la valeur du travail effectu par lquipe de Dveloppement ;
Sassurer que le Product Backlog est visible, transparent, et clair pour tous, et quil
montre ce sur quoi lquipe de Dveloppement travaillera prochainement ; et,
Sassurer que lquipe de Dveloppement comprend adquatement les items du
Product Backlog.
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.
Les quipes de dveloppement sont structures et habilites par lentreprise organiser et
grer leur propre travail. La synergie rsultante optimise lefficience et lefficacit globale
des quipes de dveloppement.
Lquipe de Dveloppement possde les caractristiques suivantes :
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 ;
1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved Page | 7
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.
Taille de lquipe de Dveloppement
La taille optimale de lquipe de Dveloppement est suffisamment petite pour que lquipe
soit flexible et ractive tout en tant suffisamment grande pour quelle soit en mesure
daccomplir un travail significatif durant le sprint. Lorsque lquipe de Dveloppement est
compose de moins de trois personnes le niveau dinteraction est rduit et les gains de
productivit moins importants. Une telle quipe peut rencontrer des difficults livrer un
incrment de logiciel en raison de comptences limites. loppos, une quipe de plus de
neuf membres implique trop de coordination. Les grandes quipes de dveloppement
engendrent des interactions trop complexes pour tre gres efficacement par un
processus empirique. moins quils ne fassent galement partie de lquipe de
Dveloppement, le Scrum Master et le Product Owner ne sont pas pris en compte dans la
taille de lquipe.
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.
Le Scrum Master au service du Product Owner
Le Scrum Master sert le Product Owner de plusieurs faons. Ses services consistent :
Trouver des techniques de gestion efficace du Product Backlog ;
Aider lquipe Scrum comprendre la ncessit davoir des items de Product
Backlog clairs et concis ;
Comprendre la planification de produit dans un contexte empirique ;
Sassurer que le Product Owner sait comment constituer le Product Backlog pour
maximiser la valeur du produit ;
Comprendre et mettre en uvre lagilit ; et,
Faciliter les vnements Scrum lorsque requis ou demand.
1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved Page | 8
Le Scrum Master au service de lquipe de Dveloppement
Le Scrum Master est au service de lquipe de Dveloppement. Ses services consistent :
Aider lquipe de Dveloppement dvelopper son auto-organisation et sa
pluridisciplinarit ;
Aider lquipe de Dveloppement crer des produits de grande valeur ;
liminer les obstacles au progrs de lquipe de Dveloppement ;
Faciliter les vnements Scrum lorsque demand ou requis ; et,
Accompagner lquipe de Dveloppement dans les environnements organisationnels
o Scrum nest pas encore entirement adopt et compris.
Le Scrum Master au service de lorganisation
Le Scrum Master rend service lorganisation de plusieurs faons. Ses services consistent :
Accompagner lorganisation dans son adoption de Scrum ;
Planifier les mises en uvre de Scrum dans lorganisation ;
Aider les employs et parties prenantes comprendre et mettre en uvre Scrum
et le dveloppement empirique de produit ;
Causer des changements qui augmentent la productivit de lquipe Scrum ; et,
Collaborer avec dautres Scrum Master pour amliorer lefficacit de lutilisation de
Scrum dans lorganisation.
Les vnements Scrum
Les vnements prescrits par Scrum crent de la rgularit et minimisent la ncessit
dautres runions non prvues. Tous les vnements sont limits dans le temps, de telle
sorte que chaque vnement ait une dure maximale. Une fois le Sprint commenc, sa
dure est fixe et ne peut tre courte ou prolonge. Les autres vnements peuvent se
terminer une fois les objectifs de ceux-ci atteints, dans la mesure o suffisamment de temps
a t allou sans que du gaspillage ait lieu dans le processus.
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
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).
1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved Page | 9
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,
Le primtre peut tre clarifi et rengoci entre le Product Owner et lquipe de
Dveloppement selon ce que lquipe Scrum apprend.
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.
Annulation dun Sprint
Un Sprint peut tre annul avant chance. Seul le Product Owner a la capacit dannuler le
Sprint, bien quil ou elle puisse se faire influencer dans cette dcision par les parties
prenantes, lquipe de Dveloppement ou le Scrum Master.
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
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.
1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved Page | 10
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.
La planification de Sprint rpond aux questions suivantes :
Quest-ce qui peut tre termin au cours de ce Sprint ?
Comment sera effectu le travail choisi ?
Premier Sujet: Quest-ce qui peut tre termin au cours de ce sprint ?
Lquipe de Dveloppement collabore pour envisager la fonctionnalit qui sera dveloppe
durant le Sprint. Le Product Owner discute de lobjectif qui devrait tre atteint durant le
Sprint et des items du Product Backlog qui, sils sont termins, permettront datteindre cet
objectif. Lquipe Scrum dans son ensemble collabore pour comprendre le travail requis.
La planification de Sprint a comme lments de dpart le Product Backlog, le dernier
incrment produit, la capacit de lquipe de Dveloppement pour le prochain sprint et
lhistorique de performance de lquipe de Dveloppement. La quantit ditems du
Product Backlog choisis pour le Sprint dpend uniquement de lquipe de Dveloppement.
Seule lquipe de Dveloppement peut dterminer ce quelle peut accomplir durant le
prochain Sprint.
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.
Deuxime sujet: comment sera effectu le travail choisi ?
Une fois lobjectif du sprint fix et les items du Product Backlog choisis, lquipe de
Dveloppement planifie le travail pour transformer cette fonctionnalit en un incrment
termin du produit durant le Sprint. Ainsi, les items du Product Backlog choisis et le plan
conu par lquipe constituent le Sprint Backlog.
L'quipe de Dveloppement commence gnralement par concevoir le systme et le travail
ncessaire afin de transformer le Product Backlog en un incrment fonctionnel du produit.
La taille ou leffort estim du travail peut varier. Cependant, lors de la runion de
planification, lquipe de Dveloppement doit envisager suffisamment de travail pour
quelle ait une bonne ide de ce qu'elle pense pouvoir accomplir durant le Sprint. Avant la
fin de la runion, lquipe de Dveloppement dcompose le travail prvu pour les premiers
jours du Sprint, souvent jusqu' une granularit d'une journe ou moins. L'quipe de
Dveloppement s'auto-organise pour entreprendre le travail consign au Sprint Backlog, la
fois lors de la runion de planification de Sprint et quand cela est ncessaire tout au long du
Sprint.
1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved Page | 11
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.
la fin de la planification du Sprint, lquipe de Dveloppement devrait tre en mesure
dexpliquer au Product Owner et au Scrum Master comment elle entend sorganiser pour
raliser lobjectif du Sprint et crer lincrment prvu.
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.
Tout en effectuant son travail, lquipe de Dveloppement garde lesprit lobjectif du
Sprint. Afin datteindre lobjectif du Sprint, lquipe implmente la fonctionnalit et la
technologie ncessaire. Si le travail se rvle diffrent de ce qui a t prvu, lquipe de
Dveloppement collabore avec le Product Owner et ngocie le primtre du Sprint Backlog
durant le sprint.
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 :
Ce quils ont ralis hier qui a aid lquipe de Dveloppement atteindre
lobjectif du Sprint ;
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.
Lquipe de Dveloppement utilise la mle quotidienne pour inspecter sa progression vers
lobjectif du Sprint et lachvement du travail prvu au Sprint Backlog. La mle quotidienne
augmente les chances que lquipe de Dveloppement atteindra lobjectif du Sprint. Chaque
jour, lquipe de Dveloppement doit comprendre comment elle sauto-organise pour
1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved Page | 12
atteindre lobjectif du Sprint et crer lincrment anticip dici la fin du Sprint. Lquipe de
Dveloppement ou un sous-ensemble de celle-ci se rencontre souvent juste aprs la mle
quotidienne pour des discussions plus dtailles ou pour adapter, ou planifier nouveau le
travail restant.
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.
Les mles quotidiennes amliorent la communication, liminent les autres runions,
rvlent les obstacles qui perturbent le dveloppement afin quils soient supprims,
mettent en avant et encouragent la prise de dcision rapide et amliorent le niveau de
connaissance de lquipe de Dveloppement. Il sagit dun point cl dinspection et
dadaptation.
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.
La revue du Sprint comprend les lments suivants :
Les participants incluent lquipe Scrum et les parties prenantes cls que le Product
Owner a invit ;
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 ;
1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved Page | 13
L'ensemble du groupe convient de ce qu'il faut faire pour la suite, de sorte que la
revue de Sprint fournisse une contribution 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.
La rtrospective de Sprint survient aprs la revue de Sprint et avant la prochaine runion de
planification de Sprint. Cest une runion limite trois heures pour les Sprints dun mois.
Pour les Sprints moins longs, la runion dure habituellement moins longtemps. Le Scrum
Master sassure que la runion a lieu et que les participants en comprennent le but. Le
Scrum Master apprend tous comment respecter la bote de temps. Le Scrum Master
participe en tant que membre de lquipe Scrum et y amne le point de vue du responsable
du processus Scrum.
Le but de la rtrospective de Sprint est :
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 .
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.
1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved Page | 14
Les artfacts de Scrum
Les artfacts de Scrum reprsentent soit du travail soit de la valeur fournissant ainsi de la
transparence et des opportunits pour l'inspection et l'adaptation. Les artfacts de Scrum
sont spcialement conus pour maximiser la transparence dinformations essentielles afin
que tous en aient la mme comprhension.
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.
Le Product Backlog liste toutes les fonctionnalits, besoins, amliorations et correctifs
correspondant aux changements devant tre appliqus au produit lors de livraisons futures.
Les items du Product Backlog incluent une description, un ordre, une estimation de leffort
et de la valeur.
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.
Laffinage du Product Backlog consiste en lajout de dtails, destimations et de
lordonnancement des items du Product Backlog. Il sagit dune activit rgulire dans
laquelle le Product Owner et lquipe de Dveloppement collaborent pour dtailler les
items du Product Backlog. Durant laffinage du Product Backlog, les items sont revisits et
rviss. Lquipe Scrum dcide comment et quand laffinage est effectu. Laffinage
noccupe gnralement pas plus de 10% de la capacit de lquipe de Dveloppement.
Toutefois, les items du Product Backlog peuvent tre modifis nimporte quel moment par
le Product Owner ou sa discrtion.
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
1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved Page | 15
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.
Lquipe de Dveloppement est responsable de toutes les estimations. Le Product Owner
peut influencer lquipe de Dveloppement en laidant dans sa comprhension et le choix
des compromis, mais les personnes qui effectueront le travail ont le mot final sur les
estimations.
Suivi de la progression vers lobjectif du sprint
tout moment, la somme de travail restant pour atteindre un objectif de dveloppement
peut tre calcule. Le Product Owner suit lvolution de cette somme de travail restant au
moins chaque revue de Sprint. Il compare cette quantit la somme de travail restant lors
des revues de Sprint prcdentes afin dvaluer le progrs vers lachvement du travail
prvu dans les dlais voulus par l'objectif. Cette information est rendue transparente pour
toutes les parties prenantes.
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
mme que lquipe de Dveloppement excute le plan et dcouvre le travail ncessaire
pour atteindre le but du Sprint.
mesure que du nouveau travail est ncessaire, lquipe de Dveloppement lajoute au
Sprint Backlog. Lorsque le travail est effectu ou complt, les estimations du travail restant
sont mises jour. Lorsque des items du plan sont jugs comme ntant plus ncessaires, ils
sont carts. Seule lquipe de Dveloppement peut changer son Sprint Backlog durant un
Sprint. Le Sprint Backlog est une vue en temps-rel et trs visible du travail que lquipe
planifie daccomplir durant le Sprint et il appartient uniquement lquipe de
Dveloppement.
1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved Page | 16
Suivi de la progression dun Sprint
nimporte quel moment dun sprint, la somme totale de travail restant dans le Sprint
Backlog peut tre calcule. Lquipe de Dveloppement fait le suivi de cette somme de
travail restant au moins chaque mle quotidienne pour valuer la probabilit datteindre
lobjectif du Sprint. En effectuant le suivi du travail restant tout au long du sprint, lquipe
de Dveloppement peut grer sa progression.
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.
La transparence des artfacts
Scrum repose sur la transparence. Les dcisions pour optimiser la valeur et contrler le
risque sont prises en se basant sur ltat peru des artfacts. Dans la mesure o la
transparence est complte, ces dcisions ont une base solide. Dans la mesure o les
artfacts ne sont pas totalement transparents, ces dcisions peuvent tre fausses, la valeur
moindre et le risque accru.
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.
La responsabilit du Scrum Master consiste travailler avec lquipe de Dveloppement et
lentreprise pour accrotre la transparence des artfacts. Ce travail implique gnralement
de la formation, de la persuasion et du changement. La transparence ne se produit du jour
au lendemain, mais est plutt un cheminement.
Dfinition de termin
Quand un item du Product Backlog ou un incrment est dit termin , tout le monde doit
comprendre ce que termin signifie. Mme si le sens varie de faon importante dune
quipe Scrum une autre, les membres doivent avoir une comprhension commune de ce
que signifie un travail termin, afin dassurer la transparence. Ceci est la dfinition de
termin pour lquipe Scrum et celle-ci est utilise pour valuer si le travail est termin
dans un incrment de produit.
Cette mme dfinition aide lquipe de Dveloppement savoir combien ditems du
Product Backlog elle peut choisir durant la planification du Sprint. Le but de chaque Sprint
1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved Page | 17
est de produire des incrments de fonctionnalits potentiellement livrables qui
correspondent la dfinition de termin en vigueur de lquipe Scrum.
Les quipes de dveloppement livrent un incrment de fonctionnalit de produit chaque
Sprint. Cet incrment est utilisable, de telle sorte que le Product Owner peut choisir de
mettre celui-ci en production immdiatement. Si la dfinition de termin dun incrment
fait partie des conventions, standards ou lignes directrices de lorganisation de
dveloppement, toutes les quipes doivent au minimum la respecter. Si la dfinition de
termin nest pas une convention de lorganisation de dveloppement, lquipe de
Dveloppement de lquipe Scrum doit tablir une dfinition de termin approprie
pour le produit. Si plusieurs quipes Scrum travaillent sur le systme ou la livraison du
produit, les quipes de dveloppement de toutes les quipes Scrum doivent mutuellement
tablir la dfinition de termin .
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
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.
1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved Page | 18
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.
Les traducteurs dsirent remercier spcialement Christian Lapointe et Emmanuel Etasse
pour leur relecture et prcieux commentaires.



1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved Page | 19
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.