Scrum

Fvrier 2010

Scrum : Cadre dvelopp et maintenu par Ken Schwaber et Jeff Sutherland

REMERCIEMENTS
GNRALITS
Scrum est bas sur les meilleures pratiques de lindustrie, des pratiques qui sont utilises et valides depuis plusieurs dcennies. Ces meilleures pratiques ont ensuite t prouves de manire empirique. Comme la dj mentionn Jim Coplien : Tout le monde va aimer Scrum; cest dailleurs ce que nous faisons naturellement lors dune situation critique. 1

INDIVIDUS
Plus de mille personnes ont contribu Scrum. Il nous apparat appropri de mentionner tout dabord celles qui ont jou un rle-cl au cours des dix premires annes. Il y eu au dpart Jeff Sutherland, qui a travaill avec Jeff McKenna et John Scumniotales, ainsi que Ken Schwaber, avec Mike Smith et Chris Martin. Scrum a t prsent et publi officiellement lors de la confrence internationale OOPSLA 1995. Au cours des cinq annes suivantes, Mike Beedle et Martine Devos ont apport dimportantes contributions. Ensuite, nous aimerions remercier tous les autres, sans qui Scrum ne serait pas ce quil est devenu aujourdhui.

HISTOIRE
Lhistoire de Scrum est dj longue lchelle de lindustrie du dveloppement logiciel. Nous aimerions honorer les premiers utilisateurs, ceux qui ont essay Scrum et qui ont permis son raffinement : Individual, Inc., Fidelity Investments ainsi que IDX (maintenant GE Medical).

TRADUCTION
Le prsent document est une adaptation franaise du guide originalement crit en anglais par Ken Schwaber et Jeff Sutherland. Les traducteurs tent den prserver lesprit et non den faire une traduction mot mot. Les personnes suivantes ont particip la prparation de la version franaise : Pascal Roy, David Beaumier, Georges Saad, Olivier Gourment, Franois Beauregard, et Louis-Philippe Carignan.

Citation originale: Everyone will like Scrum; it is what we already do when our back is against the wall.

Page 2

BUT
Scrum est utilis pour dvelopper des produits complexes depuis le dbut des annes 1990. Ce document dcrit comment utiliser Scrum pour construire des produits. Scrum nest pas une mthodologie pour construire des produits; cest plutt un cadre lintrieur duquel il est possible dutiliser diffrents processus et techniques. Le rle de Scrum est de faire ressortir lefficacit relative de vos pratiques de dveloppement dans le but de les amliorer tout en fournissant un cadre bien dfini lintrieur duquel des produits complexes peuvent tre dvelopps.

LA THORIE DE SCRUM
Scrum se base sur la thorie du contrle empirique de processus. Il emploie une approche itrative et incrmentale dans le but de rendre le processus plus prvisible et de contrler le risque. Il y a trois piliers qui soutiennent la mise en uvre dun contrle empirique de processus.

PREMIER PILIER : LA TRANSPARENCE

La transparence permet de sassurer que les aspects du processus qui affectent les rsultats sont visibles ceux qui grent ces rsultats. Non seulement ces aspects doivent tre transparents, il faut aussi que ce qui est vu soit conforme la ralit. C'est--dire que quand une personne inspecte le processus et croit quune activit est complte , il faut que ltat de cette activit corresponde la dfinition donne du terme complt .

DEUXIME PILIER : LINSPECTION

Les diffrents aspects du processus doivent tre inspects une frquence suffisante pour que tout cart inacceptable soit dtect rapidement. Pour tablir la frquence des inspections, il faut prendre en considration que tous les processus sont immanquablement modifis directement ou indirectement par le fait mme de les inspecter. Un problme se pose lorsque la frquence des inspections excde le niveau de tolrance du processus quant aux inspections. Heureusement, ce problme ne semble pas se poser en dveloppement logiciel. Lautre facteur est lhabilit et lassiduit des individus qui inspectent les rsultats.

TROISIME PILIER : LADAPTATION

Si, la suite de linspection, linspecteur dtermine quun ou plusieurs aspects du processus sont en dehors de limites acceptables et que le produit rsultant sera par consquent inacceptable, il doit ajuster le processus ou le matriel trait. Il faut apporter les ajustements le plus rapidement possible afin dviter tout autre cart. Scrum comporte trois activits en ce qui concerne le mcanisme dinspection et dadaptation. Tout dabord, il y a la mle quotidienne (Daily Scrum), qui permet de vrifier lavancement en regard latteinte du but pour le sprint et dadapter ce quil y a faire de manire optimiser la valeur produite au jour le jour. La runion de planification du sprint (Sprint Planning Meeting) et la runion de revue du sprint (Sprint Review
Page 3

Meeting) sont utilises pour valider ltat davancement quant lobjectif de la livraison courante et pour faire les adaptations qui optimiseront le processus de ralisation du prochain sprint. Finalement, la rtrospective du sprint (Sprint Retrospective) permet de passer en revue le sprint qui vient de se terminer et de dterminer les changements apporter pour que le prochain sprint soit plus productif, enrichissant et agrable pour toute lquipe.

CONTENU DE SCRUM
Scrum est un cadre qui consiste en plusieurs lments : des quipes Scrum et leurs rles connexes, des blocs de temps (Time-Boxes), des artfacts ainsi que des rgles. Les quipes Scrum sont conues pour optimiser la flexibilit et la productivit. cette fin, elles sorganisent elles-mmes, elles possdent toutes les comptences ncessaires la ralisation du produit (pluridisciplinarit). De plus, elles travaillent de faon itrative. Chaque quipe Scrum comporte trois rles distincts : 1) le ScrumMaster, qui sassure que tous les intervenants comprennent et suivent le processus; 2) le propritaire de produit (Product Owner), qui est responsable de maximiser la valeur du travail accompli par lquipe Scrum; et 3) lquipe (Team), qui effectue le travail. Cette dernire est compose de dveloppeurs ayant toutes les connaissances et comptences ncessaires pour transformer les besoins du propritaire de produit en un sous-ensemble potentiellement livrable du produit la fin de chaque sprint. Scrum utilise des blocs de temps pour crer une cadence rgulire. Les lments de Scrum utilisant des blocs de temps incluent la runion de planification de livraison (Release Planning Meeting), la runion de planification de sprint, le sprint, la mle quotidienne, la revue de sprint (Sprint Review) ainsi que la rtrospective du sprint. Le sprint constitue le cur de Scrum : il sagit dune itration dun mois ou moins dont la dure est fixe pendant tout le projet. Tous les sprints utilisent le mme cadre de Scrum. Chaque sprint permet de dvelopper un sous-ensemble potentiellement livrable du produit final. Les sprints se succdent, dbutant immdiatement les uns aprs les autres. Scrum comporte quatre principaux artfacts. Le SUGGESTION carnet du produit (Product Backlog) est une liste Quand les rgles ne sont pas dfinies, priorise de tout ce qui pourrait tre ncessaire les utilisateurs de Scrum ont la pour le produit. Le carnet de sprint (Sprint responsabilit de dcider par euxBacklog) est une liste de toutes les tches mmes comment procder. Ne tentez ncessaires pour raliser un sous-ensemble pas de trouver la solution parfaite parce que les problmatiques changent potentiellement livrable du produit. Le graphique habituellement trs rapidement. de progression (Burndown Chart) permet de Essayez plutt quelque chose et voyez mesurer ce quil reste accomplir dans le carnet si a fonctionne. Laissez-vous guider au fil du temps. Le graphique de progression de par le mcanisme dinspection et livraison (Release Burndown Chart) mesure ce dadaptation qui est au cur de lapproche empirique de Scrum. quil reste faire au niveau du carnet du produit dans le contexte dun plan de livraison donn. Un graphique de progression de sprint (Sprint Burndown Chart) permet de mesurer lavancement des tches devant tre ralises en cours de sprint.
Page 4

Les rgles de Scrum lient les blocs de temps, les rles et les artfacts en un tout cohrent. Ces rgles sont dcrites tout au long de ce document. Par exemple, une des rgles de Scrum prcise que seuls les membres de lquipe cest--dire les individus qui se sont engags transformer le carnet du produit en un sous-ensemble potentiellement livrable du produit peuvent parler durant la mle quotidienne. Les faons de faire qui ne sont pas des rgles de Scrum sont dcrites dans les encadrs intituls Suggestions .

RLES DE SCRUM
Lquipe Scrum comprend le ScrumMaster, le propritaire de produit et lquipe de dveloppeurs. Les membres de lquipe Scrum sont appels les cochons . Le propritaire de produit, cest le cochon du carnet de produit. Les membres de lquipe de dveloppeurs sont les cochons du sprint. Le ScrumMaster, cest le cochon du processus Scrum. Tous les autres sont des poules . Les poules ne peuvent dire aux cochons comment faire leur travail. Lutilisation des termes poules et cochons dcoule de lhistoire suivante :
Une poule et un cochon sont ensemble. La poule suggre : Ouvrons un restaurant ensemble! Le cochon y rflchit et dit : Et comment allons-nous appeler ce restaurant? La poule de dire : Coco-bacon! Le cochon de rpliquer : Pas question! Je serais totalement engag dans cette entreprise, alors que tu serais seulement implique!

Page 5

SCRUMMASTER
Le ScrumMaster sassure que lquipe Scrum SUGGESTION adhre aux valeurs, pratiques et rgles de Scrum. Le ScrumMaster travaille avec les Il aide lquipe et lorganisation adopter Scrum. clients et la direction pour identifier un Le ScrumMaster forme lquipe Scrum en propritaire de produit. Le lencadrant et en la guidant pour la rendre plus ScrumMaster explique au propritaire productive et pour quelle produise des produits de produit comment remplir son rle et de meilleure qualit. Le ScrumMaster aide faire son travail. Les propritaires de lquipe Scrum comprendre et tirer profit de produit doivent tre en mesure de maximiser la valeur de ce que lquipe lauto-organisation et de la pluridisciplinarit. Le produit en utilisant Scrum. Sils ny ScrumMaster aide galement lquipe Scrum parviennent pas, on attribue la faire du mieux quelle peut lintrieur dun responsabilit au ScrumMaster. environnement organisationnel qui peut ne pas encore tre adapt au dveloppement de produits complexes. Dans ce rle, le ScrumMaster limine les obstacles (impediments) pour permettre lquipe de mieux performer. Le rle du ScrumMaster est celui de leader au service de lquipe (Servant Leader).
SUGGESTION Le ScrumMaster peut tre un membre de lquipe; par exemple, un dveloppeur qui a des tches excuter durant le sprint. Toutefois, cela amne souvent des conflits lorsque le ScrumMaster doit choisir entre enlever des obstacles et raliser ses propres tches. Le ScrumMaster ne devrait jamais tre le propritaire de produit.

Page 6

Propritaire du produit

Le propritaire de produit est lunique responsable de grer le carnet du produit et de sassurer de la valeur du travail de lquipe. Cette personne maintient le carnet du produit et sassure quil soit bien visible tous. Comme tout le monde sait quels sont les lments ayant la plus haute priorit, tous savent ce sur quoi lquipe devra travailler.

SUGGESTION Dans le cadre dun dveloppement commercial, le propritaire du produit peut tre le gestionnaire de produit. Dans un dveloppement maison, le propritaire du produit pourrait tre le gestionnaire de la fonction daffaires qui doit tre automatise.

Le propritaire du produit est une seule et unique personne, et non pas un comit. Les comits peuvent exister pour conseiller et influencer la personne exerant ce rle, mais quiconque veut changer la priorit des lments du carnet du produit devra en convaincre le propritaire du produit. Les entreprises qui adoptent Scrum raliseront que cela influence fortement leur faon dtablir les besoins et les priorits dans le temps. Pour quun propritaire du produit russisse, tous SUGGESTION les membres de lorganisation devront respecter ses Le propritaire de produit peut aussi dcisions. Personne ne doit dire lquipe de tre un membre de lquipe, faisant lui travailler sur des priorits diffrentes que celles aussi du dveloppement logiciel. Cette tablies par le propritaire du produit. Les quipes responsabilit supplmentaire peut toutefois affecter ses capacits bien ne doivent pas couter qui que ce soit qui dirait le communiquer avec les autres parties contraire. Les dcisions prises par le propritaire du prenantes. En aucun cas le propritaire produit sont reprsentes dans la slection et la de produit ne doit tre ScrumMaster. priorisation des lments du carnet du produit. Cest cette visibilit accrue qui rend la tche du propritaire de produit la fois exigeante, mais aussi trs satisfaisante.

QUIPE
La responsabilit de lquipe de dveloppement est de transformer le contenu du carnet du produit en un sous-ensemble de fonctionnalits potentiellement livrable la fin de chaque sprint. Comme lquipe est pluridisciplinaire, elle possde toutes les comptences ncessaires pour produire un sous-ensemble livrable du produit final. Les membres de lquipe possdent souvent des comptences spcialises telles que la programmation, le contrle de la qualit, lanalyse daffaires, larchitecture, la conception dinterfaces utilisateurs, ou bien la conception de base de donnes. Toutefois, la comptence quils partagent, soit dtre en mesure de transformer un besoin en un produit utilisable, a plus dimportance que les autres comptences. Un individu qui refuse de programmer parce quil est un architecte ou un concepteur ne serait pas utile dans lquipe. Tous contribuent, mme sils doivent pour ce faire acqurir de nouvelles comptences ou sen remmorer de lointaines. Il ny a pas de titres dans lquipe et aucune exception cette rgle nest tolre. Lquipe nest pas non plus divise en sous-groupes ddis un domaine de comptence comme les tests ou bien lanalyse daffaires.

Page 7

Lquipe sorganise elle-mme. Personne, pas mme le ScrumMaster, ne peut dire lquipe comment transformer le contenu du carnet du produit en sous-ensemble de fonctionnalits livrable. Cest lquipe de dterminer le comment. Elle utilise son exprience et son expertise pour rsoudre les problmes auxquels elle fait face. La synergie rsultante amliore lefficacit et le rendement de toute lquipe. La taille optimale dune quipe est de sept personnes, plus ou moins deux. Quand lquipe est plus petite, il y a moins dinteractions entre les membres, ce qui entrane une rduction du gain de productivit. De plus, lquipe peut rencontrer des contraintes au niveau des comptences requises, rsultant en une incapacit de livrer un sous-ensemble du produit la fin du sprint. linverse, sil y a plus de neuf personnes, le travail de coordination devient tout simplement trop laborieux. Une grande quipe gnre trop de complexit pour tre gre de faon empirique. Toutefois, nous avons rencontr des quipes qui ont russi malgr leur taille non optimale (dpassement des limites recommandes). La taille de lquipe ninclut pas les rles de ScrumMaster et de propritaire du produit moins que ces derniers ne soient galement des cochons qui travaillent sur des tches du carnet de sprint. La composition de lquipe peut changer la fin dun sprint. Toutefois, chaque changement apport lquipe engendre une rduction du gain de productivit provenant de lauto-organisation. Il faut donc porter une attention particulire tout changement la composition de lquipe.

BLOCS DE TEMPS
Les activits de Scrum qui sont dans des blocs de temps sont la runion de planification de livraison, le sprint, la runion de planification de sprint, la revue de sprint, la rtrospective de sprint ainsi que la mle quotidienne.

RUNION DE PLANIFICATION DE LIVRAISON

Le but de la runion de planification de livraison est de dresser un plan et des objectifs clairs que lquipe Scrum et le reste de lorganisation peuvent comprendre et communiquer. La planification de livraison vise rpondre aux questions suivantes : Comment pouvons-nous transformer notre vision en un produit gagnant le plus efficacement possible? Comment pouvons-nous rencontrer et mme surpasser les attentes de nos clients tout en ayant un excellent retour sur linvestissement? . Le plan de livraison tablit les objectifs dune livraison, indique les lments les plus prioritaires du carnet du produit, dnote les principaux risques et produit une vue densemble des caractristiques et des fonctionnalits que le produit devrait contenir pour cette livraison. Il indique galement une date probable de livraison ainsi quune estimation du cot en se basant sur lhypothse que rien ne changera en cours de route. Lorganisation peut ensuite surveiller la progression et ajuster le plan aprs chaque sprint. La planification de livraison est tout fait optionnelle. Si une quipe Scrum commence travailler sans cette crmonie, labsence des artfacts associs celle-ci sera vite

Page 8

apparente et deviendra rapidement un obstacle lavancement. Une activit de haute priorit devra alors tre ajoute au carnet du produit pour carter cet obstacle. Les produits tant dvelopps de faon itrative avec Scrum, chaque sprint cre un sousensemble du produit final en commenant par ce qui a le plus de valeur ou qui est le plus risqu. Chaque sprint subsquent rajoute de la fonctionnalit. Quand la succession de sprints a permis de crer un produit dune valeur suffisante aux yeux des investisseurs, le produit peut alors tre livr officiellement. La plupart des organisations ont dj leur propre processus de livraison en place. Dans la majorit des cas, la planification est faite au tout dbut et demeure inchange au fil du temps. Durant la planification de livraison Scrum, un objectif et des rsultats probables sont dtermins. Typiquement, la planification de livraison ne prend pas plus de quinze vingt pourcent du temps requis pour faire une planification de livraison traditionnelle. Toutefois, le plan est revu continuellement chaque revue et planification de sprint et mme potentiellement la suite de la mle quotidienne. De fait, il est probable que la planification de livraison avec lapproche Scrum requiert mme un peu plus defforts que dans une planification de livraison traditionnelle. La planification de livraison requiert lestimation et la priorisation du carnet du produit pour une livraison spcifique. Il existe plusieurs techniques pour y arriver. Ces techniques ne sont pas dfinies par Scrum, mais elles peuvent tre trs utiles lorsquelles sont utilises dans son contexte.

Page 9

SPRINT
Le sprint est une itration. Les sprints sont limits dans le temps (bloc de temps). Pendant un sprint, le ScrumMaster sassure quaucun changement qui viendrait modifier lobjectif du sprint nest apport. La composition de lquipe de mme que les objectifs de qualit demeurent les mmes pendant la dure complte du sprint. Les activits dun sprint sont les suivantes : la runion de planification de sprint, le dveloppement, la revue et la rtrospective du sprint. Les sprints se succdent dans le temps. Il ny a aucun temps mort entre chacun des sprints.

SUGGESTION Si lquipe sent quelle sest engage au-del de ses capacits, elle doit rencontrer le propritaire du produit afin dliminer certains lments du carnet de sprint ou de rduire leur porte. loppos, si lquipe croit avoir du temps disponible, elle peut travailler de concert avec le propritaire du produit pour ajouter au carnet de sprint dautres lments du carnet du produit.

Un projet est ralis dans le but datteindre un objectif. En dveloppement logiciel, lobjectif est de construire un produit ou un systme. Chaque projet est constitu de la dfinition de ce qui doit tre construit, dun plan pour le construire, du travail fait pour le construire et du produit en rsultant. Il faut considrer quun plan nest valide que pour un horizon de temps dfini. Si lhorizon est trop long, SUGGESTION la dfinition peut changer, trop de variables Lorsquune quipe dbute son peuvent entrer en ligne de compte, le risque peut apprentissage de Scrum, lutilisation de tre trop grand, etc. Scrum est un cadre pour des sprints dune dure de deux semaines projets dont lhorizon est dun mois au maximum facilite lapprentissage tout en limitant et o il y a suffisamment de complexit pour quun lincertitude. Des sprints de cette dure horizon plus long soit trop risqu. La prvisibilit peuvent tre synchroniss avec les dun projet doit tre contrle au moins chaque autres quipes en combinant le rsultat de deux sprints conscutifs mois; le risque que le projet drape ou devienne (pour obtenir un cycle dun mois). imprvisible est donc limit cette priode. Un sprint peut tre annul avant quil ne soit termin. Seul le propritaire du produit a lautorit ncessaire pour annuler un sprint, bien quil puisse avoir t influenc par dautres parties prenantes, lquipe ou le ScrumMaster. Dans quelles circonstances est-il judicieux dannuler un sprint? La direction peut annuler un sprint si lobjectif du sprint na plus de sens. Ceci pourrait se produire si lentreprise changeait de direction ou bien si les conditions du march ou technologiques changeaient. En gnral, un sprint devrait tre annul si des circonstances faisaient quil na plus de sens. Toutefois, vue la dure limite des sprints, cela se produit rarement. Lorsquun sprint est annul, il y a revue de tous les lments du carnet du produit qui sont complts. Seuls les lments qui sont potentiellement livrables sont accepts. Les autres lments sont remis dans le carnet avec leurs estimations initiales. Tout le travail fait sur les lments non complts est considr comme perdu. Lannulation dun sprint est une
Page 10

activit qui requiert un effort significatif puisque toute lquipe doit se regrouper pour effectuer une autre planification de sprint avant de pouvoir dbuter le sprint suivant. Les annulations de sprint sont gnralement des vnements perturbants pour lquipe. Elles sont toutefois trs peu frquentes.

RUNION DE PLANIFICATION DE SPRINT

Il sagit en fait de la runion qui permet de planifier litration (sprint). Sa dure est limite huit heures pour un sprint dun mois. Pour un sprint plus court, le temps allou cette runion doit tre au prorata de la dure totale du sprint (ex. : quatre heures pour un sprint de deux semaines). La runion se divise en deux parties gales (c.--d. dune dure de quatre heures chacune pour un sprint dun mois). Pendant la premire priode, lquipe dcide de ce qui va tre fait au cours du sprint. Dans la seconde partie, lquipe dtermine comment elle va dvelopper les fonctionnalits slectionnes au cours de la premire partie. Il arrive que certaines quipes combinent les deux parties. En somme, la premire partie de la runion permet de rpondre la question Quoi? et la seconde au Comment ? . Dans la partie couvrant le Quoi? , le propritaire du produit prsente lquipe les lments du carnet de produit ayant la plus haute priorit. Ils travaillent ensuite ensemble pour dterminer les fonctionnalits qui seront dveloppes lors du prochain sprint. Pour pouvoir procder la runion, il est ncessaire que le carnet du produit soit dfini et prioris adquatement et que le plus rcent sous-ensemble complt du produit soit disponible. Aussi, la capacit prvue de lquipe de mme que la performance antrieure de celle-ci (vlocit) sont passes en revue. Le nombre dlments du carnet qui seront couverts au cours du sprint est entirement laiss la discrtion de lquipe. Seule lquipe est en mesure de savoir ce quelle peut accomplir lintrieur dun sprint. la suite de la slection des lments du carnet du produit, il faut fixer lobjectif du sprint. Cest cet objectif que lquipe tentera datteindre tout au long du sprint. Il reprsente typiquement la raison pour laquelle un nouveau sous-ensemble du produit est dvelopp et sert de guide lquipe tout au long du sprint. Lobjectif permet lquipe de se donner un peu de jeu en regard de la fonctionnalit dvelopper. Par exemple, un objectif de sprint pourrait tre Informatiser lentre de nos comptes de dpenses. Lorsque lquipe travaille, elle garde cet objectif lesprit. Pour satisfaire lobjectif, elle dveloppe la fonctionnalit en utilisant la technologie ncessaire. Si le travail est plus ardu que ce quoi lquipe sattendait, cette dernire collabore avec le propritaire du produit pour mettre en uvre une partie de la fonctionnalit prvue initialement. Dans la seconde partie de la runion de planification de sprint, lquipe sattaque au Comment? . Elle rflchit ce quelle devrait faire pour transformer les lments du carnet du produit qui ont t choisis au cours de la premire partie de la runion (le Quoi? ) en un sous-ensemble livrable du produit. La premire tape consiste habituellement en une sance de conception o lquipe dtermine diffrentes tches de ralisation. Ces tches reprsentent le dtail de ce qui doit tre fait pour convertir les
Page 11

lments du carnet du produit en logiciel fonctionnel. Idalement, une tche ne devrait pas schelonner sur plus dune journe de travail. La liste des tches est ce quon appelle le carnet de sprint. Lquipe sorganise par ellemme en ce qui concerne la ralisation des tches du carnet de sprint. Elle peut le faire durant la planification du sprint ou tout au long du sprint. Le propritaire du produit participe la seconde SUGGESTION partie de la runion afin de clarifier les lments Habituellement, seulement environ 60du carnet du produit et didentifier des compromis 70% des tches du Carnet de Sprint si cest ncessaire. Si lquipe dtermine quelle a sont prcises en dtail dans la trop faire ou pas assez, elle peut rengocier le runion. Le reste peut tre estim sommairement et dtaill au cours du carnet de sprint avec le propritaire du produit. Sprint. Lquipe peut galement inviter cette runion dautres individus qui pourraient apporter des contributions grce leur expertise technique ou leur forte connaissance du domaine daffaires. Cest au cours de la runion de planification du sprint que la plupart des nouvelles quipes ralisent que Scrum est centre essentiellement sur le travail dquipe, que lquipe ne doit compter que sur ellemme. Cest en simprgnant de cette ralit que lquipe peut commencer sautoorganiser et adopter les caractristiques et le comportement dune vraie quipe.

REVUE DE SPRINT
la fin de chaque sprint, on organise une runion de revue de sprint. Cest une runion dont la dure est limite quatre heures pour un sprint dun mois. Pour des sprints plus courts, le temps allou la runion doit tre calcul au prorata de la dure totale du sprint (ex. : deux heures pour un sprint de deux semaines). Pendant la revue de sprint, lquipe Scrum et les parties prenantes discutent de ce qui a t fait pendant le sprint. partir de cette information et des changements apports au carnet du produit, ils discutent galement de ce qui devra tre fait au cours du prochain sprint. Cest une runion informelle dont le but est de favoriser un environnement de collaboration tout en renforant la notion dquipe. La runion de revue de sprint inclut au moins les activits ci-dessous. Le propritaire de produit indique clairement ce qui a t complt mais aussi ce qui na pas t complt. Lquipe discute de ce qui a bien t durant le sprint, des problmes quelle a rencontrs et de la faon quils ont t rsolus. Lquipe dmontre ensuite le travail qui a t fait en prsentant les fonctionnalits dveloppes au cours de litration et rpond aux questions. Le propritaire du produit discute ensuite de ltat actuel du carnet du produit et prsente les dates probables de ralisation en se basant sur la vlocit de lquipe. Finalement, le groupe discute franchement des implications de ce qui a t ralis sur la suite des choses. Cette rencontre fournit un prcieux apport la prochaine runion de planification de sprint.

RTROSPECTIVE DE SPRINT
Aprs la revue de sprint mais avant la planification du sprint suivant, lquipe organise une runion de rtrospective de sprint. Durant cette runion de trois heures (pour un sprint
Page 12

dun mois), le ScrumMaster encourage lquipe Scrum revoir, lintrieur du cadre et des pratiques de Scrum, son processus de dveloppement pour le rendre plus efficace et agrable. Plusieurs livres documentent des techniques facilitant la tenue de rtrospectives efficaces. Lobjectif de la rtrospective est dinspecter le droulement du dernier sprint du point de vue des individus, des relations interpersonnelles, des processus et des outils. Linspection devrait dterminer et prioriser les lments du sprint qui ont t un succs, mais aussi ceux qui pourraient tre amliors. Les lments considrer sont la composition de lquipe Scrum, la logistique des runions, les outils, la dfinition du terme complt , les mthodes de communication et tous les processus utiliss pour transformer les lments du carnet du produit en fonctionnalits compltes . la fin de la rtrospective, lquipe Scrum devrait avoir tabli une liste des actions mesurables entreprendre et raliser au cours du prochain sprint. Ces changements reprsentent une adaptation base sur linspection empirique du processus.

MLE QUOTIDIENNE
Lquipe se rencontre chaque jour pour une runion dinspection et dadaptation du processus. Cette rencontre, quon appelle la mle quotidienne, est limite quinze minutes. Elle se droule chaque jour au mme endroit et la mme heure pendant toute la dure du sprint. Durant cette runion, chaque membre de lquipe prsente ce qui suit : 1. ce quil ou elle a accompli depuis la dernire mle; 2. ce quil ou elle va faire dici la prochaine mle; 3. les obstacles surmonter, sil y a lieu. La mle quotidienne amliore la communication et limine la ncessit de tenir dautres runions. Elle permet de dceler les obstacles rapidement et de les supprimer. Elle favorise la prise de dcision rapide et permet tous davoir une meilleure vision du projet dans son ensemble. Le ScrumMaster sassure de la tenue de la mle quotidienne, mais cest la responsabilit de lquipe de tenir cette runion. Le ScrumMaster enseigne lquipe comment garder la runion la plus courte possible. Il sassure que les gens suivent les rgles et parlent brivement. Le ScrumMaster sassure que les poules ninterrompent pas la runion puisquils nont pas droit de parole. La mle quotidienne nest pas en soit une runion sur ltat davancement. Elle ne sadresse quaux membres de lquipe, ceux qui se sont engags transformer les lments du carnet du produit en fonctionnalits livrables. Elle doit plutt tre vue comme une inspection de la progression vers lobjectif commun du sprint (les trois questions). Dautres runions peuvent dcouler de la mle quotidienne afin dapporter des modifications au travail faire pendant le sprint. Le but est doptimiser la probabilit que lquipe atteigne lobjectif du sprint. Il sagit dune rencontre cruciale permettant linspection et ladaptation au niveau du contrle empirique du processus utilis par Scrum.
Page 13

ARTFACTS DE SCRUM
Les artfacts de Scrum incluent le carnet du produit, le graphique de progression de livraison, le carnet de sprint et le graphique de progression de sprint.

CARNET DU PRODUIT ET GRAPHIQUE DE PROGRESSION DE LA LIVRAISON

La liste des fonctionnalits du produit que doit dvelopper la ou les quipes se trouve dans le carnet du produit. Le propritaire du produit est responsable de ce carnet, de son contenu, de sa publication ainsi que de la priorisation des lments quil contient. Le carnet du produit nest jamais complet. La version prliminaire du carnet du produit contient gnralement les besoins que lon connat actuellement et ceux que lon comprend le mieux. Le carnet est dynamique; il volue au fur et mesure que le produit et lenvironnement dans lequel il sera utilis voluent. Il change constamment et reflte notre comprhension de ce que devrait tre un produit utile et comptitif. Tant que le produit existera, le carnet du produit connexe existera. Le carnet du produit contient tout ce qui est ncessaire pour dvelopper et livrer un produit qui sera un succs. Il sagit de la liste des fonctionnalits, technologies, amliorations et correctifs qui correspondent aux changements qui devront tre apports au produit lors des livraisons futures. Les lments du carnet de produit possdent au minimum les SUGGESTION proprits suivantes : une description, un niveau de Les quipes Scrum passent en gnral priorit ainsi quune estimation. Le niveau de plus de 10% de chaque sprint priorit dcoule du risque, de la valeur ajoute et de sassurer que le carnet de produit respecte bien la dfinition prsente cila ncessit de chaque lment. Il existe de dessus. A ce niveau de dtails, les nombreuses techniques pour tablir chacune de ces lments du carnet de produit en haut proprits. Les lments du carnet du produit sont tris par ordre de priorit. Les lments de plus haute priorit sont dvelopps en premier. Plus la priorit est leve, plus llment est urgent, plus on y a rflchit et plus il y a consensus sur la valeur ajoute de llment. Les lments de haute priorit sont dcrits de faon plus dtaille que ceux de moindre priorit. Ils peuvent donc tre estims plus prcisment. loppos, moins la priorit est leve, moins il est dcrit de faon prcise. mesure quun produit est utilis, que sa valeur augmente et que lon commence recevoir une rtroaction sur son utilisation, le carnet du produit grossit et devient plus exhaustif. Les besoins voluent continuellement et narrteront jamais de changer, ce qui fait du carnet du produit un document vivant. Les changements au niveau des
de liste (plus grande priorit, plus grande valeur daffaire) sont dcomposs afin dtre ralisables lintrieur dun sprint. Il y a une analyse et une rflexion importante qui est faite cette tape. Quand la runion de sprint a lieu, les lments du carnet de produit au haut de la liste sont donc dj bien compris et peuvent tre slectionns facilement pour implmentation dans le sprint.

SUGGESTION Les lments du carnet du produit sont gnralement exprims sous forme de scnarios utilisateurs (User Stories). Les cas dutilisation sont aussi appropris, mais ils sont mieux adapts au dveloppement de systmes critiques.

Page 14

besoins daffaires, des conditions du march, de la technologie et du personnel ont un impact sur le carnet du produit. Pour rduire la quantit de travail reprendre, seuls les lments de haute priorit doivent tre dcrits en dtail. Les lments du carnet du produit qui occuperont lquipe pendant les sprints venir ont t dcomposs de faon granulaire de sorte que chacun peut tre complt lintrieur des limites dun seul sprint. Il arrive souvent que de multiples quipes Scrum travaillent ensemble sur le mme produit. Un seul carnet du produit est utilis pour dcrire le travail venir pour un produit. On peut alors ajouter une proprit aux lments du carnet pour les regrouper. Le groupement peut se faire par ensemble de fonctionnalits, de technologies ou darchitectures. On utilise un groupement comme faon dorganiser le travail entre les diffrentes quipes.
SUGGESTION Les tests dacceptation sont une autre proprit qui est souvent associe aux lments du carnet du produit. Ils peuvent souvent remplacer des descriptions textuelles dtailles par une dfinition testable de ce que le produit doit faire pour que llment soit considr comme complt .

Le graphique de progression de livraison prsente les efforts ncessaires pour raliser les lments qui restent faire dans le carnet du produit. Les estimations sont exprimes dans une unit choisie par lquipe Scrum et la direction. Laxe horizontal du graphique reprsente gnralement chacun des sprints. Une ligne dextrapolation fonde sur les donnes antrieures du travail restant peut tre trace pour montrer la date de livraison projete si la tendance se maintient. Les estimations des lments du carnet du produit sont faites initialement lors de la planification de la livraison ou lors de leur cration si elles ont t faites aprs celle-ci. Toutefois, elles peuvent tre mises jour nimporte quel moment en cours de sprint. Lquipe est responsable deffectuer toutes les estimations. Le propritaire de produit peut influencer lquipe en laidant mieux comprendre la demande et en proposant des compromis, mais lestimation finale doit tre effectue par lquipe. Le propritaire du produit doit avoir en tout temps une version jour du carnet du produit et du graphique de progression de la livraison, et ceux-ci doivent tre affichs.
SUGGESTION Dans certaines organisations, plus de travail est ajout en cours de route au carnet de produit que ce qui est complt. Ceci se traduit par une ligne dextrapolation plat ou mme qui monte lgrement. Pour compenser ceci, on peut crer un nouveau plancher qui indique quand du travail a t ajout ou enlev. Le plancher ne devrait tre ajust que pour des changements significatifs qui sont bien documents.

CARNET DE SPRINT ET GRAPHIQUE DE PROGRESSION DE SPRINT

Le carnet de sprint contient la liste des tches ncessaires pour transformer les lments du carnet du produit en un sous-ensemble de fonctionnalits livrable. Il faut savoir que plusieurs tches seront probablement fixes au cours de la runion de planification du sprint. Runies, elles reprsentent tout le travail qui doit tre fait pour atteindre lobjectif du sprint. Les lments du carnet de sprint doivent tre dcoups en tches assez petites
Page 15

pour que lavancement soit le plus visible possible lors de la mle quotidienne. La ralisation dune tche ne devrait pas ncessiter plus dune journe. Lquipe modifie le carnet de sprint tout au long du sprint. mesure que les diffrentes tches sont ralises, il est possible que lquipe dcouvre que certaines tches ne sont plus ncessaires, que dautres doivent tre ajoutes et que certaines tches prendront plus ou moins de temps que ce qui tait prvu initialement. Lorsquon se rend compte que de nouvelles tches sont ncessaires, il faut les ajouter au carnet de sprint. Les tches qui ne sont plus ncessaires sont quant elles enleves du carnet de sprint. mesure que lquipe ralise ou termine une tche, elle met jour lestimation du travail restant pour la tche. Seule lquipe peut modifier le carnet de sprint durant le sprint. Elle seule peut en changer le contenu ou les estimations en dcoulant. Le carnet de sprint est une reprsentation fidle et en temps rel de ltat davancement de lquipe relativement au sprint en cours. Ce carnet appartient uniquement lquipe.

Le graphique de progression du sprint est un SUGGESTION graphique qui montre la quantit dlments du La ligne de tendance du graphique de carnet de sprint quil reste raliser au cours du progression peut ne pas tre sprint. Pour le crer, il suffit simplement reprsentative au cours des deux ou dadditionner chaque jour les estimations des trois premiers sprints moins que les lments quil reste raliser. Conservez les membres de lquipe aient dj travaill ensemble, quils connaissent sommes pour chaque jour du sprint et utilisez-les bien le produit et quils matrisent les pour crer le graphique montrant le travail technologies sous-jacentes. restant dans le temps. En traant une ligne travers les points du graphique, lquipe peut tablir une tendance et ainsi grer sa progression en cours de sprint. La dure des tches na pas dimportance selon Scrum. Seul le travail restant pour complter une tche et les dates sont importants. Une des rgles de Scrum souligne lobjectif des sprints, qui est de livrer successivement des sousensembles de fonctionnalits potentiellement livrables correspondant la dfinition du terme complt .
SUGGESTION Quand cest possible, tracez la main le graphique de progression du sprint sur une grande feuille de papier et affichez-le dans laire de travail de lquipe. Il est plus probable que les gens remarquent un grand graphique bien visible quils nouvrent un fichier Excel (ou autre) pour voir ledit graphique.

Page 16

DFINITION DE COMPLT
Scrum demande lquipe de livrer un sousensemble de produit la fin de chaque Sprint. Chaque sous-ensemble doit tre potentiellement livrable car le propritaire de produit pourrait le dployer immdiatement. Chaque sous-ensemble doit tre complt . Il doit sajouter au travail existant et tre test pour sassurer que tous les sous-ensembles fonctionnent bien ensemble.
SUGGESTION Le travail dit non complt est souvent accumul dans le carnet de produit sous une rubrique intitule Travail non complt ou Travail en cours . Le fait de prsenter ce travail sous non complt , plutt que de lenlever du sprint permet de montrer la progression relle du carnet de produit au cours du sprint.

En dveloppement logiciel, certains sattendent que pour quune fonctionnalit soit considre complte , le code doit tre propre, correctement remani (refactored), compil et test (tests unitaires et fonctionnels). Quelquun dautre pourrait sattendre ce quil soit simplement compil. Si tous ne sentendent pas sur la dfinition du terme complt , le contrle empirique du processus prn par Scrum ne peut fonctionner. Lorsquun travail est complt , il est absolument ncessaire que tout le monde ait la mme comprhension de ce que cela implique. Lorsque lquipe sengage complter un lment du carnet du produit, elle sengage respecter la dfinition du terme complt . Certains produits ne contiennent pas de documentation utilisateur. La dfinition de complt pour ces produits ne contient donc pas la partie documentation. Un sous-ensemble de produit complt comprend lanalyse, la conception, le remaniement, le codage, la documentation ainsi que tous les tests ncessaires associs aux lments du carnet du produit impliqus dans ce sousensemble de produit. Les essais incluent les tests unitaires, les tests de systme, les tests utilisateurs ainsi que les tests de rgression. On inclut galement les tests non fonctionnels comme les tests de performance, de stabilit, de scurit ainsi que dintgration. La dfinition de complt inclut galement tout ce qui touche linternationalisation si cest pertinent. Il arrive parfois que des quipes ne sont pas en mesure dinclure ds le dpart tout ce qui est ncessaire dans leur dfinition de complt . Si cest le cas, le propritaire du produit doit en tre inform car ce travail non ralis devra tre complt pour que le produit soit officiellement livrable et utilisable.

Page 17

LE MOT DE LA FIN
Certaines organisations sont incapables de construire un sous-ensemble complet de fonctionnalits dans les limites de temps dun sprint. Elles nont peut-tre pas encore linfrastructure requise dautomatisation des essais pour raliser tous les tests. Dans ce cas, on peut crer deux catgories relativement au travail excut au cours du sprint, le travail complt et le travail non complt . Le travail non complt devra tre complt plus tard. Le propritaire du produit est tout fait au courant de ce quil inspecte la fin du sprint car il comprend bien la dfinition du terme complt . Le travail non complt est ajout au carnet du produit pour que ltat davancement rel se reflte bien au niveau du carnet du produit ainsi que sur le graphique de progression de livraison. Lefficacit du processus dinspection et dadaptation lors la revue de sprint est directement lie la transparence de ltat davancement tel quil se reflte dans le carnet du produit. Par exemple, si lquipe nest pas en mesure de faire les tests de performance, de rgression, de stabilit ni dintgration pour chaque lment du carnet du produit, il faudra ajouter des lments au carnet du produit pour en tenir compte. Si on calcule que les tests manquants pour un lment du carnet du produit reprsentent 30 % du travail et que cet lment a ncessit 10 units de travail, il faudra donc rajouter un lment de travail de 3 units dans la catgorie travail non complt du carnet du produit. Sprint aprs sprint, le travail non complt doit tre accumul. Il devra obligatoirement tre pris en charge avant que le produit final puisse tre livr. Bien que ce travail saccumule de faon linaire, il est probable que leffort requis pour complter ce travail suive plutt une courbe exponentielle au fil du temps, en fonction des particularits de lorganisation. Des sprints sont ajouts la suite de chaque livraison afin de complter le travail non complt . Le nombre de sprints requis est difficilement prvisible d la nature non linaire de leffort ncessaire pour raliser le travail. Il est donc prfrable de limiter la quantit de travail non complt .

Page 18