Traduction de la dernière version du guide officiel de Scrum (Version Juillet 2011)

Traduction de la dernière version du guide officiel de Scrum

(Version Juillet 2011)

Le guide définitif de Scrum :
Les règles du jeu
Par les pères fondateurs de Scrum

Ken Schwaber et Jeff Sutherland

Traduit de l’anglais et commenté par

Mahfoud Amiour
mamiour@softenia-solutions.com

www.softenia-solutions.com

(Traduction non officielle1, V1.0 -Avril 2012)

1
Titre original : « The Scrum Guide. The definitive Guide to Scrum : The Rules of the Game”. Le guide officiel en
anglais est disponible à l’adresse : www.scrum.org. Des traductions officielles dans d’autres langues y compris
en français sont également disponibles à la même adresse.

Guide officiel de Scrum version Juillet 2011 par K. Schwaber & J. Sutherland (Fondateurs de Scrum)

Traduit et commenté par Mahfoud AMIOUR ; email : mamiour@softenia-solutions.com

Tables des matiè res
Objectif du guide Scrum .......................................................................................................................... 3
Vue d’ensemble de Scrum ....................................................................................................................... 3
Le Framework Scrum .............................................................................................................................. 3
La théorie Scrum ..................................................................................................................................... 4
La transparence ................................................................................................................................... 4
L’adaptation......................................................................................................................................... 4
Scrum ....................................................................................................................................................... 5
L’équipe Scrum .................................................................................................................................... 5
Le Product Owner ............................................................................................................................ 5
L’équipe de développement............................................................................................................ 6
Le Scrum Master .............................................................................................................................. 7
Les événements Scrum........................................................................................................................ 8
Le Sprint ........................................................................................................................................... 8
Réunion de planification de Sprint .................................................................................................. 9
Mêlée Quotidienne ....................................................................................................................... 11
Revue de Sprint ............................................................................................................................. 12
Rétrospective de Sprint ................................................................................................................ 13
Les artefacts Scrum ........................................................................................................................... 13
Backlog de produit......................................................................................................................... 14
Backlog de Sprint ........................................................................................................................... 15
L’incrément.................................................................................................................................... 16
Définition de Fini ........................................................................................................................... 16
Conclusion ............................................................................................................................................. 17
Remerciements ..................................................................................................................................... 18
Les personnes .................................................................................................................................... 18
Historique .......................................................................................................................................... 18

Traduction non officielle -Version 1.0 Avril 2012 Page 2



Objectif du guide Scrum
Scrum est un framework dédié au développement et à la maintenance de produits complexes. Ce
guide présente la définition de Scrum. La définition inclut les rôles, les événements, les artefacts et
les règles qui les lient. Le guide est écrit et fourni par Ken Schwaber et Jeff Sutherland, les créateurs
et développeurs de Scrum.

Vue d’ensemble de Scrum
Scrum(n) : Un framework au sein duquel on peut adresser des problèmes complexes et changeants,
tout en livrant de manière productive et créative des produits ayant la plus haute valeur ajoutée
possible. Scrum est :

• Léger
• Simple à comprendre
• Extrêmement difficile à maitriser

Scrum est un framework utilisé dans la gestion de projets de développements complexes depuis le
début des années 1990. Ce n’est pas un processus ni un technique de construction de produits ; Il
s’agit plutôt d’un cadre dans lequel vous pouvez utiliser différents processus et techniques2.
Scrum vous aide à rendre visible l’efficacité relative de vos pratiques de gestion et de
développement, afin que vous puissiez les améliorer.

Le Framework Scrum
Le framework se compose d’équipes Scrum et leurs rôles, d’événements, d’artefacts et de règles.
Chacun de ces éléments répond à un objectif bien précis. Il est par conséquent indispensable à
l’utilisation et au succès de Scrum.

Les stratégies spécifiques pour l’utilisation du framework Scrum varient et sont décrites ailleurs.

Les règles de Scrum définissent et régissent les liens et les interactions entre les événements, les
rôles et les artefacts. Elles seront décrites tout au long de ce guide.

2
Scrum ne prescrit pas de pratiques d’ingénierie logicielle par exemple. En général, on utilise des pratiques
provenant de l’eXtreme Programming comme l’intégration continue, le développement dirigé par les tests
(TDD, etc.).




La théorie Scrum
Scrum est basé sur la théorie de contrôle des processus empiriques : L’empirisme. La théorie de
l’empirisme considère que la connaissance vient de l’expérience. De ce fait, elle favorise la prise de
décision en se basant sur ce qui est connu.

Scrum emploie également une approche itérative et incrémentale pour améliorer la prédictibilité et
le contrôle des risques.

Le contrôle des processus empiriques est fondé sur trois piliers : La transparence, l’inspection et
l’adaptation.

La transparence
Les aspects significatifs du processus doivent être visibles aux acteurs responsables du résultat. La
transparence nécessite que ces aspects soient définis via un standard commun à fin de permettre
aux observateurs d’avoir une compréhension commune de ce qu’ils sont en train d’observer.

Par exemple :

• Tous les participants doivent partager un langage commun représentant le processus
• Ceux qui effectuent le travail et ceux qui le valident doivent partager une définition
commune de « Fini3»

Afin de détecter les écarts indésirables, les utilisateurs de Scrum doivent régulièrement inspecter
les artefacts du framework et l’état d’avancement vers un objectif fixé. Cependant, la fréquence
de l’inspection ne doit pas être trop élevée pour ne pas gêner l’équipe dans son travail. D’autre
part, les inspections les plus bénéfiques sont celles menées par des inspecteurs qualifiés sur le lieu
de travail de l’équipe.

L’adaptation
Si l’inspection d’un processus détecte des déviations qui dépassent les limites tolérables, rendant le
produit inacceptable, le processus ou le matériel en cours d’inspection doit être ajusté. Cet
ajustement doit être effectué le plus tôt possible pour éviter l’aggravation de la situation.

Scrum prescrit quatre opportunités formelles pour l’inspection et l’adaptation. Ces opportunités,
décrites dans la section « Les événements Scrum » de ce document, sont :

• La Réunion de planification de Sprint ;
• La Mêlée quotidienne ;
• La Réunion de revue de Sprint ;
• La Rétrospective de Sprint.

3
La définition de « Fini » fait partie des artefacts de Scrum. Elle sera présentée dans la section « Définition de
Fini ».




Scrum
Scrum est un framework structuré destiné à supporter le développement de produits complexes. Le
framework se compose des éléments suivants : Une équipe Scrum et ses rôles, des événements, des
artefacts et des règles. Chaque élément répond à un besoin spécifique le rendant indispensable à
l’utilisation et au succès de Scrum.

L’équipe Scrum
L’équipe Scrum comprend les rôles suivants : le Product Owner, l’équipe de développement et le
Scrum Master.

Les équipes Scrum sont auto organisées et multidisciplinaires4. L’auto-organisation signifie que la
façon de travailler de l’équipe n’est pas dictée de l’extérieur. C’est à l’équipe de choisir la meilleure
façon pour accomplir son travail et atteindre ses objectifs. La multidisciplinarité veut dire que
l’équipe possède toutes les compétences nécessaires à l’exécution de son travail, sans dépendre de
l’extérieur5. Ce modèle d’équipe a été conçu dans le but d’optimiser la flexibilité, la créativité et la
productivité.

L’équipe Scrum effectue des livraisons de produits de façon itérative et incrémentale, maximisant
ainsi les opportunités de feedback. Ces livraisons incrémentales de produits « Finis » permettent
d’avoir en permanence une version du produit potentiellement utilisable6.

Le Product Owner
Le Product Owner a la responsabilité de maximiser la valeur ajoutée du produit et du travail de
l’équipe de développement. La façon pour y parvenir dépend des organisations, des équipes Scrum
et des individus.

Le Product Owner est également l’unique responsable de la gestion du Backlog du produit. Cette
gestion consiste à :

• Décrire de manière claire les éléments du Backlog ;
• Ordonner les éléments de façon à mieux accomplir les objectifs et les missions7 ;
• Garantir la valeur du travail effectué par l’équipe de développement ;
• S’assurer de la visibilité du Backlog, de sa transparence et de sa clarté pour tous ;
• Garantir que le Backlog montre bien sur quoi l’équipe Scrum travaille prochainement ;
• S’assurer de la bonne compréhension des éléments du Backlog par l’équipe de
développement et avec le niveau de détail adéquat.

Le Product Owner peut effectuer lui-même les tâches ci-dessus. Il peut également les déléguer à
l’équipe de développement. Cependant, il demeure toujours le seul responsable du Backlog du
produit.

4
Note du traducteur : C’est une équipe transverse.
5
Note du traducteur : L’équipe possède des compétences en développement, tests, analyse fonctionnelle,
bases de donnes, etc.
6
Note du traducteur : Cela veut dire que l’on peut déployer l’incrément en production.
7
Note du Traducteur : Il s’agit de prioriser les éléments afin de commencer par la réalisation de ceux qui ont le
plus de valeur pour le client.




Le Product Owner est une personne physique et non un comité. Il peut néanmoins représenter les
désirs d’un comité via le Backlog du produit. Dans tous les cas, ceux qui désirent changer le Backlog
du produit (Modifier les priorités par exemple) doivent toujours passer par le Product Owner.

Afin que le Product Owner puisse réussir dans son rôle, l’organisation doit respecter ses décisions.
Ces dernières sont toujours visibles à travers le contenu et l’ordre du Backlog du produit. En dehors
du Product Owner, personne n’est autorisé à imposer à l’équipe de développement de travailler sur
des éléments qui ne font pas partie du Backlog. De son côté, l’équipe de développement n’est pas
autorisée à accepter les demandes ne provenant pas du Product Owner.

L’équipe de développement
L’équipe de développement se compose de professionnels qui travaillent pour livrer un incrément
« Fini » et potentiellement livrable en production à la l’issue de chaque Sprint. Seuls les membres de
l’équipe de développement réalisent l’incrément.

L’équipe de développement est habilitée par l’entreprise à organiser et à gérer elle-même son
travail. La synergie qui résulte de cette auto organisation permet à l’équipe d’optimiser son efficacité
et son efficience globale8.

Les caractéristiques de l’équipe de développement sont les suivantes :

• L’auto-organisation. Personne (Pas même le Scrum Master) ne peut dicter à l’équipe la façon
de procéder pour transformer le Backlog du produit en un incrément ;
• La multidisciplinarité. L’équipe possède toutes les compétences nécessaires à la création
des incréments9 ;
• Pas de titre individuel autre que celui de développeur. Scrum ne reconnait pas de titres au
sein de l’équipe de développement. Seul le titre de développeur est reconnu aux membres
de l’équipe indépendamment du travail qu’ils effectuent10. Il n’y a pas d’exception à cette
règle ;
• Les membres de l’équipe peuvent être spécialisés dans certains domaines et avoir des
compétences spécifiques11. Cependant, la responsabilité appartient collectivement à
l’équipe de développement.
• L’équipe de développement ne contient pas de sous équipes dédiées à des domaines
spécifiques comme les tests ou l’analyse métier.

Taille de l’équipe de développement
La taille optimale de l’équipe de développement est à la fois assez petite pour que l’équipe reste
agile, et suffisamment grande pour qu’elle soit capable de produire des résultats significatifs. Une

8
Note du traducteur : L'efficience est la qualité d'un rendement permettant de réaliser un objectif avec
l'optimisation des moyens engagés (Source Wikipedia).
9
Note du traducteur : L’équipe inclut des compétences en développement, test, analyse fonctionnelle, base de
données, etc. selon les besoins du projet.
10
Note du Traducteur : Chaque membre de l’équipe est appelé développeur.
11
Note du Traducteur : C’est ce que l’on appelle les « profils en T ». Un membre de l’équipe peut par exemple
être expert en développement Java (Compétence centrale) et avoir des connaissances plus ou moins
importances en tests, bases de données, etc. Ces compétences « secondaires » lui permettent de prendre des
tâches autres que du développement Java ; Comme participer aux tests par exemple.




taille de moins de trois membres réduirait les interactions et mènerait à des gains en productivité
moins importants. Une équipe de petite taille risque également de manquer de certaines
compétences nécessaires au projet, ce qui peut l’empêcher d’atteindre l’objectif du Sprint.

Inversement, avoir plus de neuf personnes dans une équipe exige beaucoup d’effort de
coordination. En effet, les équipes de développement de grande taille génèrent trop de complexité
pour être gérées par un processus empirique comme Scrum. Le Product Owner et le Scrum Master
ne sont pas inclus dans le comptage de la taille de l’équipe, sauf s’ils contribuent à la réalisation des
éléments du Backlog du produit12.

Le Scrum Master
Le Scrum Master garantit la bonne compréhension et l’application de Scrum en s’assurant que
l’équipe Scrum adhère à la théorie, aux pratiques et aux règles du framework. Le Scrum Master est
un leader13 au service de l’équipe Scrum.

Le Scrum Master apporte son assistance également aux personnes de l’organisation ne faisant pas
partie de l’équipe Scrum. Il les aide à comprendre les interactions utiles avec l’équipe Scrum et
celles qui ne le sont pas14. Le Scrum Master apporte son aide pour changer ces interactions de façon
à maximiser la valeur créée par l’équipe Scrum.

Services rendus au Product Owner
Les services rendus par le Scrum Master au Product Owner incluent :

• Trouver les techniques efficaces pour gérer le Backlog du produit ;
• Communiquer la vision, les objectifs et les éléments de Backlog du produit à l’équipe de
développement ;
• Apprendre à l’équipe Scrum (Product Owner et équipe de développement) comment
élaborer des éléments de Backlog clairs et concis ;
• Comprendre la planification à long terme dans un environnement empirique ;
• Comprendre et appliquer l’agilité ;
• Faciliter la tenue des évènements Scrum.

Services rends à l’équipe de développement
Les services rendus par le Scrum Master à l’équipe de développement incluent :

• Coacher l’équipe dans l’auto-organisation et la multidisciplinarité ;
• Conduire l’équipe et lui apprendre comment créer des produits à forte valeur ajoutée ;
• Eliminer les obstacles qui empêchent l’équipe d’avancer ;
• Faciliter la tenue des événements Scrum ;

12
Il existe des équipes où le Scrum Master effectue également des tâches de développement par exemple.
Dans ce cas, il compte aussi comme un membre de l’équipe de développement.
13
Note du traducteur : Servant-leader en anglais. Cela signifie que le Scrum Master n’a pas de pouvoir
hiérarchique sur l’équipe ; Ce n’est pas lui qui assignent les tâches par exemple.
14
Certaines réunions ne concernent que les membres de l’équipe Scrum comme par exemple les mêlées
quotidiennes (présentées plus loin dans ce guide). Il est inutile que des personnes externes à l’équipe Scrum y
participent. En revanche, il est utile (voire indispensable) que ces personnes puissent participer à la réunion de
revue des résultats à la fin de chaque Sprint.




• Coacher l’équipe dans les organisations qui n’ont pas encore adopté Scrum.

Services rendus à l’organisation
Les services rendus par le Scrum Master à l’organisation incluent :

• Conduire et coacher l’organisation dans son adoption de Scrum ;
• Planifier les implantations de Scrum ;
• Aider les employés et les parties prenantes à comprendre et appliquer Scrum et le
développement empirique (Transparence, Inspection et adaptation) ;
• Provoquer le changement permettant d’accroitre la productivité de l’équipe Scrum ;
• Collaborer avec les autres Scrum Master de l’organisation pour rendre l’application de Scrum
plus efficace.

Les événements Scrum
Scrum prescrit des événements dans l’objectif de créer de la régularité dans le projet et de
minimiser le recours à d’autres réunions non définis dans le Framework. Chaque événement a une
durée maximale appelée « Time-box ». Imposer une durée maximale aux événements permet de
consacrer une quantité de temps appropriée au processus de planification sans autoriser de
gaspillage.

En dehors du Sprint lui-même, qui est le conteneur de tous les événements de Scrum, chaque
événement constitue une opportunité formelle pour inspecter et adapter quelque chose. Ces
événements sont conçus spécifiquement pour offrir la transparence critique et l’inspection. Omettre
l’un d’eux conduira à une diminution de la transparence et à des occasions d’inspection et
d’adaptation manquées.

Le Sprint
Le Sprint est au cœur du framework Scrum. C’est un time-box d’un mois ou moins durant lequel on
crée un incrément « Fini » utilisable et potentiellement livrable à la production. Les Sprints ont des
durées constantes tout au long de l’effort de développement. Un nouveau Sprint commence
immédiatement après la fin du précédent.

Les sprints sont constitués d’une réunion de planification de Sprint, de mêlées quotidiennes, du
travail de réalisation15, d’une revue de Sprint et d’une rétrospective de Sprint.

Pendant le Sprint :

• Les changements pouvant compromettre l’objectif du Sprint ne sont pas permis
• La composition de l’équipe de développement ne doit pas changer
• Les objectifs de qualité ne doivent pas diminuer
• Le périmètre peut être renégocié entre le Product Owner et l’équipe de développement
suite à des connaissances nouvelles acquises durant le Sprint.

15
Note du traducteur : Il s’agit des tâches nécessaires à la réalisation des fonctionnalités : Conception, codage,
tests, documentation, etc.




Chaque Sprint peut être considéré comme un projet de moins d’un mois d’horizon. Comme tout
projet, les Sprints sont utilisés pour accomplir un travail. A ce titre, chaque Sprint possède une
définition de ce qu’il faut construire, une conception et un plan flexible permettant de réaliser cette
conception, le travail à faire, et le produit résultant.

Les Sprints sont limités à un mois calendaire. Si l’horizon d’un Sprint est très lointain (plus d’un mois),
la définition du produit en cours de construction peut changer, la complexité peut accroitre et le
risque peut augmenter. Un horizon de moins d’un mois est plus approprié : Il améliore la
prédictibilité en permettant d’inspecter et d’adapter le planning au minimum une fois tous les
mois ; Le coût des risques est également limité à un mois calendaire.

Abandonner un Sprint
Un Sprint peut être abandonné avant son terme. Seul le Product Owner est habilité à prendre une
telle décision, même s’il peut le faire à la demande des parties prenantes, de l’équipe de
développement ou du Scrum Master.

Le Sprint peut être abandonné si son objectif devient obsolète. Cela peut arriver lorsque l’entreprise
change d’orientation ou si les conditions du marché et de la technologie évoluent. En général, un
Sprint doit être abandonné s’il perd son sens compte tenu des nouvelles circonstances. Mais, vue la
courte durée des Sprints, l’abandon d’un Sprint représente rarement de l’intérêt16.

Lorsqu’un Sprint est abandonné, chaque élément « Fini » est examiné. Si une partie du travail est
potentiellement livrable en production, le Product Owner peut décider de l’accepter et l’intégrer au
produit. Les éléments incomplets sont ré-estimé et remis dans le Backlog du produit. La ré-
estimation des éléments et une activité régulière dans Scrum car le travail effectué sur les éléments
se déprécie rapidement.

L’abandon d’un Sprint est consommateur de ressources. Tout le monde doit se regrouper dans une
nouvelle réunion de planification et redémarrer un nouveau Sprint. Les abandons sont souvent
traumatisants pour l’équipe Scrum et ils sont rares.

Réunion de planification de Sprint
Le travail à réaliser durant le Sprint est planifié pendant la réunion de planification du Sprint. Le plan
qui résulte de la réunion est établi collectivement par l’ensemble de l’équipe Scrum.

La réunion a une durée maximale de huit heures pour un Sprint d’un mois. Ce time-box est
proportionnel à la durée du Sprint. Par exemple, pour un Sprint de deux semaines la durée maximale
de la réunion de planification est de quatre heures.

La réunion de planification du Sprint se compose en deux parties. Chaque partie possède un time-
box égal à la moitié du time-box global. Les deux parties doivent répondre respectivement aux deux
questions suivantes :

• Le Quoi : Que doit-on livrer dans le Sprint?
• Le Comment : Comment doit-on procéder pour accomplir le travail nécessaire?

16
Note du traducteur : On peut aller jusqu’au bout du Sprint et finir les choses proprement, notamment si peu
de jours nous séparent de la fin du Sprint.




Première partie(Le Quoi) : Qu’est ce qui va être fait pendant ce Sprint?
Dans la première partie de la réunion, l’équipe de développement cherche à établir une prévision
de la fonctionnalité qui sera livrée à l’issue du Sprint. Le Product Owner commence par lui présenter
les éléments ordonnés du Backlog du produit17. Ensemble, ils discutent les éléments afin de
comprendre le travail à effectuer pendant le Sprint18.

Les prérequis de la première partie de la réunion sont le Backlog du produit, le dernier incrément, la
capacité de l’équipe de développement durant le Sprint et sa performance passée19.

Il appartient exclusivement à l’équipe de développement de décider du nombre d’éléments à
réaliser dans le Sprint. En effet, seule l’équipe (connaissant ses capacités) est en mesure d’évaluer
ce qu’elle peut accomplir durant le Sprint qui vient.

Après avoir établi une prévision de la fonctionnalité à livrer, l’équipe Scrum définit un But pour le
Sprint. Ce but représente l’objectif que l’on cherche à atteindre à travers la réalisation des
éléments sélectionnés du Backlog du produit. Il permet d’orienter l’équipe et lui montrer l’intérêt de
l’incrément qu’elle est en train de construire20.

Deuxième partie (Le Comment) : Comment le travail sélectionné va être effectué ?
Dans cette partie de la réunion l’équipe de développement détermine comment procéder pour
réaliser la fonctionnalité sélectionnée pour le Sprint. L’ensemble formé par les éléments choisis du
Backlog et le plan de réalisation de ces éléments est appelé Backlog de Sprint21.

L’équipe de développement commence souvent par concevoir le système22 et identifier le travail
nécessaire pour transformer les éléments sélectionnés en un incrément. Les unités de travail
identifiées peuvent avoir des tailles ou des durées variées. Cependant, Il faut identifier
suffisamment de travail durant cette réunion, de façon à permettre à l’équipe de développement
d’estimer ce qu’elle est en mesure de livrer à la fin du Sprint. Avant la fin de la réunion, le travail
prévu pour les premiers jours du Sprint est décomposé en unités (tâches) d’une journée ou moins.
L’équipe de développement s’auto-organise pour prendre en charge le travail qu’elle consigne dans

17
Note du traducteur : Il les présente dans l’ordre de priorité.
18
Note du traducteur : Afin de se focaliser sur la planification et minimiser le nombre de fonctionnalités à
expliquer, je préconise d’expliquer les fonctionnalités en dehors de la réunion de planification : Soit lors de la
phase de préparation du projet (en début du projet), soit lors des réunions de préparation du Backlog du
produit.
19
Note du traducteur : Il s’agit de la vélocité estimé de l’équipe. Cette information permet à l’équipe de
développement de déterminer combien d’éléments elle peut sélectionner pour le Sprint.
20
Note du traducteur : Exemple de Buts : Implémenter la recherche avancée, Internationaliser l’application,
etc. Avoir un but peut aussi être une source de motivation supplémentaire pour l’équipe.
21
Note du traducteur : C’est un artefact officiel de Scrum. Il sera détaillé plus loin dans ce document.
22
Note du traducteur : Il ne s’agit pas ici d’une conception technique détaillée mais d’une discussion et d’une
ébauche de la solution technique dans laquelle toute l’équipe de développement participe. On parle de
conception participative.




le Backlog du Sprint23. La prise en charge du travail par les membres de l’équipe peut se faire
pendant la réunion de planification et tout au long du Sprint selon les besoins.

Le Product Owner peut participer à la deuxième partie de la réunion afin de préciser les éléments
sélectionnés du Backlog du produit et d’aider l’équipe de développement à trouver des compromis
si nécessaire. Si au cours de la réunion l’équipe se rend compte qu’elle a sélectionné trop d’éléments
ou à l’inverse très peu de choses à faire, elle négocie avec le Product Owner un nouveau périmètre
du Sprint24.

Si l’équipe de développement le juge utile, elle peut également inviter d’autres personnes à la
réunion. C’est le cas par exemple si elle veut se faire conseiller sur certains aspects techniques ou
fonctionnels.

Avant la fin de la réunion de planification du Sprint, l’équipe de développement doit être en mesure
d’expliquer au Product Owner et au Scrum Master comment elle compte procéder pour atteindre le
but du Sprint en tant qu’équipe auto-organisée.

But de Sprint
Le But du Sprint offre à l’équipe de développement une certaine flexibilité par rapport à la
fonctionnalité à réaliser durant le Sprint.

L’équipe de développement garde ce but à l’esprit durant toute la durée du Sprint. Pour l’atteindre,
elle implémente de la fonctionnalité et de la technique. Si le travail s’avère différent de de ce qui a
été prévu, l’équipe de développement peut consulter le Product Owner afin de négocier un
nouveau périmètre pour le Sprint.

Le but du Sprint peut être considéré comme un jalon intermédiaire dans la roadmap du produit.

Mêlée Quotidienne
La mêlée quotidienne est un événement d’une durée maximale de 15 minutes. Il permet à l’équipe
de développement de synchroniser ses activités et de définir un plan pour les prochaines 24 heures.
La mêlée consiste à examiner les tâches accomplies depuis la réunion précédente et de prévoir les
tâches à faire avant la suivante.

La mêlée quotidienne a lieu chaque jour, à la même heure et au même endroit. Pendant la réunion,
chaque membre de l’équipe de développement explique trois points :

• Qu’est-ce qu’il a fait depuis la dernière mêlée ?
• Qu’est-ce qu’il va faire avant la prochaine mêlée ?
• Quels sont les obstacles qui l’empêchent d’avancer dans son travail?

23
Note du traducteur : Dans une équipe de développement auto-organisée, les tâches ne sont pas assignées
de l’extérieur. Les membres de l’équipe prennent les tâches en fonction de leur compétence et leur
disponibilité.
24
Le revoir à la hausse ou à la baisse selon le cas.




L’équipe de développement se sert de la mêlée quotidienne pour : Evaluer l’avancement vers le but
du Sprint ; Estimer les tendances de l’avancement vers l’achèvement du Backlog du Sprint. La mêlée
quotidienne permet ainsi, d’optimiser la probabilité d’atteindre l’objectif du Sprint.

Le plus souvent, l’équipe de développement se rencontre immédiatement après la mêlée
quotidienne pour mettre à jour le planning du Sprint (Backlog du Sprint). A travers cette mise à jour
quotidienne, l’équipe doit être à tout moment en mesure d’expliquer, au Product Owner et au
Scrum Master, comment elle compte procéder pour atteindre le but du Sprint dans le temps qui lui
reste.

Le Scrum Master s’assure de la bonne organisation de la mêlée quotidienne par l’équipe de
développement. Cependant, c’est à l’équipe qu’incombe la responsabilité de gérer la réunion.

Le Scrum Master apprend à l’équipe de développement comment tenir la mêlée dans un délai de 15
minutes. Il s’assure également que seuls les membres de l’équipe de développement participent à la
réunion. En effet, la mêlée ne doit pas être considéré comme un point d‘avancement du projet. Elle
est conçue uniquement pour les personnes qui réalisent les éléments du Backlog du produit.

Les mêlées quotidiennes sont donc des réunions clés pour l’inspection et l’adaptation. Elles
permettent : d’améliorer la communication ; de minimiser le recours à d’autres réunions ; d’éliminer
les obstacles ; de promouvoir la prise de décision rapide et d’améliorer la connaissance de l’équipe
de développement sur le projet.

Revue de Sprint
La revue du Sprint a lieu à la fin de ce dernier. Elle permet d’inspecter l’incrément et adapter le
Backlog du produit si nécessaire. Pendant la revue, l’équipe Scrum et les parties prenantes discutent
ce qui a été réalisé dans le Sprint. Basés sur ces échanges et sur les éventuelles modifications
introduites sur le Backlog du produit durant le Sprint, les participants travaillent ensemble sur la
définition de ce qu’il faut faire pour la suite.

De plus, la revue du Sprint est une réunion informelle. La présentation de l’incrément est destinée à
obtenir du feedback de la part des participants et à encourager la collaboration.

Pour un Sprint d’un mois, la durée maximale de la revue est de quatre heures. Ce time-box est
proportionnel à la durée du Sprint. Par exemple, pour un Sprint de deux semaines, la revue ne doit
pas dépasser deux heures.

La revue du Sprint inclut les éléments suivants :

• Le Product Owner identifie les éléments « Finis » et ceux qui ne le sont pas ;25
• L’équipe de développement discute de ce qui a bien fonctionné durant le Sprint, des
problèmes rencontrés et comment elle les a traités ;
• L’équipe de développement effectue une démonstration des éléments « Finis » et répond
aux questions concernant l’incrément ;

25
Note du traducteur : Parmi les éléments du Backlog du produit sélectionnés pour le Sprint




• Le Product Owner discute le Backlog du produit dans son état actuel. Il ou elle estime les
dates probables d’achèvement en se basant sur l’avancement à ce jour ;
• L’ensemble des participants collabore à définir le travail à faire pour la suite. De ce fait, la
revue fournit des inputs précieux aux réunions de planification suivantes.

Le résultat de la revue du Sprint est un Backlog de produit mis à jour qui définit les éléments
probables pour le Sprint suivant. La conclusion de la revue peut également être un changement total
du Backlog pour répondre à de nouvelles opportunités par exemple.

Rétrospective de Sprint
La rétrospective du Sprint est une opportunité mise à la disposition de l’équipe Scrum pour faire
son auto inspection et établir un plan d’amélioration pour le prochain Sprint.

La rétrospective se fait après la revue du Sprint et avant la réunion de planification du Sprint suivant.
Son time-box est de 3 heures pour un Sprint d’un mois. Cette limite est proportionnelle à la durée
du Sprint.

L’objet de la rétrospective peut se résumer dans les points suivants :

• Inspecter comment le dernier Sprint s’est déroulé par rapport aux personnes, aux relations,
aux processus et aux outils ;
• Identifier et ordonner les principaux éléments ayant bien fonctionné ainsi que les
améliorations potentielles ;
• Définir un plan d’action pour mettre en place les actions permettant à l’équipe Scrum
d’améliorer sa façon de travailler.

Le Scrum Master encourage l’équipe Scrum à améliorer son processus de développement et ses
pratiques au sein du framework Scrum. L’objectif est de rendre ces processus plus efficaces et plus
agréables lors du Sprint suivant.

Lors de la rétrospective, l’équipe Scrum peut adapter sa définition de « Fini » dans le but d’accroitre
la qualité des produits qu’elle livre.

Avant la fin de la réunion, l’équipe Scrum doit identifier les améliorations à mettre en place pour le
Sprint suivant. En implémentant ces améliorations, l’équipe Scrum applique sur elle-même les
pratiques d’inspection et d’adaptation. Même si les améliorations peuvent être implémentées à
n’importe quel moment du projet, la rétrospective constitue une opportunité formelle pour se
focaliser sur l’inspection et l’adaptation.

Les artefacts Scrum
Les artefacts Scrum sont une représentation, sous des formes diverses, du travail ou de la valeur
produits par l’équipe. Ils offrent de la transparence et constituent des ingrédients alimentant
l’inspection et l’adaptation. Les artefacts sont pour maximiser la visibilité des informations requises
pour assurer la réussite des équipes Scrum dans la livraison d’incréments «Finis»26.

26
Note du traducteur : Les artefacts sont : le Backlog de Produit, Le Backlog de Sprint, l’incrément et la
définition de « Fini ». Ils seront présentés plus loin dans ce document.




Backlog de produit
Le Backlog du produit est une liste ordonnée contenant tout ce qui est requis dans le produit. C’est
aussi l’unique source des besoins pour toute modification du produit. Cet artefact est sous la
responsabilité exclusive du Product Owner. La responsabilité inclut le contenu du Backlog, sa
disponibilité et l’ordre de ses éléments.

Un Backlog de produit n’est jamais complet. En début du projet, il expose uniquement les besoins
connus et les mieux compris à ce stade du projet. Il évolue ensuite au rythme de l’évolution du
produit et de son environnement. C’est aussi un artefact dynamique : Il change constamment pour
identifier de quoi le produit a besoin afin qu’il reste pertinent, compétitif et utile ; Tant que le
produit existe son Backlog doit exister.

Le Backlog du produit liste toutes les caractéristiques27, les fonctionnalités, les besoins, les
améliorations et les correctifs. Ces éléments constituent les changements à introduire sur le produit
dans ses versions futures. Chaque élément possède une description, un ordre et une estimation28.

Les éléments du Backlog du produit sont souvent ordonnés par leur valeur, leur risque, leur priorité
et leur nécessité dans le produit. Les éléments avec un ordre élevé doivent être réalisés en premier.

L’ordre d’un élément est le reflet du degré de sa prise en considération et de l’importance du
consensus dont il bénéficie : Plus son ordre est élevé, plus l’élément est considéré et plus le
consensus à son égard et à l’égard de sa valeur sont importants.

Les éléments avec un ordre élevé sont plus concis et plus détaillés que les éléments d’ordre inférieur.
Par exemple, ils possèdent des estimations plus précises, établies grâce à une clarté plu grande et à
un niveau de détail plus fin.

Les éléments qui occuperont l’équipe de développement durant le prochain Sprint ont une
granularité fine. Cette granularité est obtenue en décomposant les éléments en sous éléments
pouvant être « Finis » en l’espace d’un Sprint. Ces éléments sont «prêts » ou «actionnables » pour
être sélectionnés lors de la réunion de planification du Sprint.

A mesure que le produit est utilisé et que le marché fournit du feedback, le Backlog du produit
s’élargit et devient plus exhaustif. De plus, les besoins n’arrêtent pas de changer faisant du Backlog
du produit un artefact vivant ; Des évolutions dans le métier, dans les conditions du marché ou dans
la technologie peuvent provoquer des modifications dans le Backlog du produit.

Un produit doit avoir un seul Backlog même si généralement plusieurs équipes Scrum travaillent sur
le même produit. Dans ce cas, on peut ajouter un attribut au Backlog pour regrouper les éléments29.

Un Backlog de produit se prépare de façon continue. La préparation du Backlog est l’action d’ajouter
les détails, les estimations et l’ordre à ses éléments. C’est un processus continu dans lequel le

27
Note du traducteur : Features en anglais.
28
Note du traducteur : Il s’agit d’une estimation de la taille de l’élément. A l’instar des autres méthodes Agile,
Scrum emploie en général les points (Story points) pour estimer la taille.
29
Note du traducteur : Regroupement es éléments par équipe.




Product Owner et l’équipe de développement travaillent ensemble30. Pendant la préparation, les
éléments du Backlog sont passés en revue et mis à jours. Mais les éléments peuvent être mis à jours
à n’importe quel moment31 par le Product Owner ou avec son accord.

La préparation du Backlog est une activité à temps partiel qui a lieu pendant le Sprint. Elle implique
le Product Owner et l’équipe de développement. Cette dernière possède souvent la connaissance du
domaine lui permettant de réparer le Backlog de façon autonome32. Quand et comment faire la
préparation est du ressort de l’équipe de développement. Mais le temps consacré à la préparation
ne doit pas dépasser 10% de sa capacité pendant le Sprint33.

L’équipe de développement est responsable de l’établissement de toutes les estimations. Le
Product Owner peut influer l’équipe en l’aidant à comprendre les fonctionnalités à réaliser et choisir
des solutions alternatives par exemple. Cependant, les estimations finales reviennent à l’équipe de
développement.

Suivre l’avancement vers un but
A tout moment, le Product Owner doit être en mesure de connaitre le travail total restant à faire
pour atteindre un objectif34. Il traque ce reste à faire au minimum à chaque revue de Sprint.

Pour ce faire, le Product Owner compare le reste à faire à la fin du Sprint courant avec les restes à
faire à la fin des Sprints précédents35. Cela lui permet d’évaluer l’avancement de l’achèvement du
travail planifié pour la date souhaité de l’objectif. Cette information d’avancement est visible à
toutes les parties prenantes.

Plusieurs techniques d’estimation de l’avancement ont été utilisées : Burndown, Burnup et autres
pratiques de projection. Elles ont toutes prouvé leur utilité. Cependant, elles ne remplacent pas
l’importance de l’empirisme. Dans des environnements complexes, ce qui va arriver reste du
domaine de l’inconnu. Seul ce qui s’est réellement passé peut être utilisé pour la prise de décision et
la préparation du futur.

Backlog de Sprint
Le Backlog de Sprint est constitué : de l’ensemble des éléments du Backlog du produit sélectionnés
pour ce Sprint ; du plan de réalisation de ces éléments36. Il s’agit d’une prévision (Faite par l’équipe
de développement) de la fonctionnalité à livrer dans le prochain incrément, et des tâches
nécessaires à cette livraison.

30
Note du traducteur : Le Scrum Master peut également participer en tant que facilitateur
31
Note du traducteur : En dehors du processus de préparation
32
Note du traducteur : A mon avis cette affirmation n’est valable que pour des équipes de développement très
mature dans l’utilisation de Scrum. Pour des équipes qui débutent, l’implication du Product Owner et du Scrum
Master est indispensable.
33
Note du traducteur : Contrairement aux événements, Scrum n’impose donc pas de fréquence et de date pour
préparer le Backlog du produit. C’est à l’équipe Scrum d’organiser des réunions de préparation selon les
besoins, mais sans dépasser les 10% de sa capacité.
34
Note du traducteur : Il s’agit ici du but du produit final
35
Note du traducteur : Les restes à faire à la fin des Sprint précédents sont des informations connues. Elles sont
consignées dans l’historique du projet (On utilise souvent ce que l’on appelle le Burndown du produit).
36
Note du traducteur : Il s’agit des tâches




Le Backlog du Sprint définit le travail que l’équipe de développement effectuera pour transformer
les éléments du Backlog du produit en un incrément « Fini ». Il permet ainsi de visualiser toutes les
tâches identifiées comme nécessaires à l’atteinte du But du Sprint.

Le Backlog du Sprint est suffisamment détaillé afin de permettre à l’équipe de développement de
comprendre son avancement lors de la mêlée quotidienne. L’équipe le met à jour continuellement
faisant du Backlog un artefact qui émerge tout au long du Sprint. Cette émergence apparait à
mesure que l’équipe exécute son planning et à mesure qu’elle acquiert de la connaissance sur le
travail à faire pour atteindre l’objectif du Sprint.

Lorsque du nouveau travail est identifié, l’équipe de développement doit l’ajouter au Backlog du
Sprint ; Quand elle effectue un travail elle doit mettre à jour l’estimation du reste à faire ; De même,
si un travail est jugé inutile, elle doit le supprimer du Backlog du Sprint.

Seule l’équipe de développement est habilité à effectuer les changements sur le Backlog du Sprint :
C’est sa propriété exclusive. C’est aussi l’image visible qui reflète en temps réel le travail que
l’équipe de développement compte accomplir durant le Sprint.

Suivre l’avancement du Sprint
A tout moment, l’équipe de développement doit être en mesure d’indiquer le reste à faire total du
Backlog du Sprint. Elle traque cette information au moins à chaque mêlée quotidienne. Cela lui
permet de déterminer la probabilité d’accomplir le But du Sprint et mieux gérer son avancement.

Scrum ne tient pas compte du temps passé sur les éléments du Backlog du Sprint. Il s’intéresse
exclusivement au reste à faire37.

L’incrément
L’incrément s’obtient en additionnant tous les éléments du Backlog du produit réalisés durant le
Sprint courant et ceux des Sprints précédents38. A la fin d’un Sprint, le nouvel incrément doit être
« Fini ». Ce qui signifie que l’incrément doit être utilisable et satisfaire la définition de « Fini » de
l’équipe Scrum. L’incrément doit répondre aux conditions d’utilisation indépendamment de la
décision du Product Owner de le déployer ou non en production.

Définition de Fini
Lorsqu’ un élément du Backlog du Produit ou un incrément est considéré comme « Fini », tout le
monde doit avoir la même signification de « Fini ». Cette définition peut varier d’une équipe Scrum à
l’autre.

Les membres d’une même équipe Scrum doivent tous avoir une compréhension commune de ce que
signifie un travail fini. Cette compréhension commune constitue la définition de « Fini » de l’équipe
Scrum. L’équipe s’en sert pour vérifier si le travail est réellement achevé.

37
Note du traducteur : Souvent dans les projets on a besoin pour des raisons d’imputation budgétaire de
garder trace du temps consommé sur les activités. Si c’est le cas dans votre projet, vous pouvez ajouter un
attribut au Backlog du Sprint pour stocker le temps consommé.
38
Note du traducteur : Il ne s’agit pas d’une addition mathématique. Chaque incrément s’obtient par l’ajout de
nouvelles fonctionnalités à son prédécesseur.




La définition de Fini permet également à l’équipe de développement (Lors de la réunion de
planification du Sprint) d’avoir en sa possession tous les éléments pouvant l’aider à décider du
nombre d’éléments du Backlog du Produit à inclure dans le Sprint39.

L’équipe de développement livre un incrément utilisable à l’issue de chaque Sprint. Le Product
Owner peut décider de le déployer en production immédiatement. L’incrément est alors additionné
aux incréments précédents40. L’ensemble est minutieusement testé, afin de garantir que les
incréments fonctionnent ensemble.

A mesure que la maturité de l’équipe Scrum augmente, elle peut étendre sa définition de « Fini »
pour inclure des critères plus stricts et avoir une qualité meilleure.

Conclusion
Scrum est gratuit et est offert dans ce guide. Les rôles de Scrum, les artefacts, les événements et les
règles sont immuables. Bien qu’il soit possible de mettre en place des parties de Scrum uniquement,
le résultat obtenu n’est pas un processus Scrum. Scrum existe uniquement dans sa globalité. Il
fonctionne bien comme conteneur pour d’autres techniques, méthodologies et pratiques41.

39
Note du traducteur : En ayant en tête la définition de Fini l’équipe va considérer toutes les tâches qui
permettent de satisfaire cette définition de Fini : Tâches de tests unitaires, déploiement sur les
environnements adéquats, guide utilisateurs, etc.
40
Note du traducteur : Il ne s’agit pas d’une addition mathématique. Chaque incrément s’accroit par l’ajout de
nouvelles fonctionnalités à son prédécesseur.
41
NDT : Il est fréquent dans des projets Agile d’utiliser Scrum avec des pratiques XP, KANBAN ou LEAN. Les
pratiques CMMI ou PMBOK ne sont pas incompatibles non plus.




Remerciements
Les personnes
Parmi les milliers de personnes qui ont contribué à Scrum, nous voudrions distinguer ceux qui ont
joué un rôle dans ses dix premières années. D’abord il y‘avait Jeff Sutherland collaborant avec Jeff
McKenna, et Ken Schwaber travaillant avec Mike Smith et Chris Martin. Beaucoup d’autres ont
contribué dans les années qui ont suivi. Sans leur aide, Scrum ne serait pas affiné tel qu’il l’est
aujourd’hui. David Starr a fourni des informations clés et des compétences rédactionnelles dans la
formulation de cette version du guide Scrum.

Historique
Ken Schwaber et Jeff Sutherland ont coprésenté Scrum pour la première fois lors de la conférence
OOPSLA en 1995. Cette présentation à principalement documenté l’apprentissage que Ken et Jeff ont
acquis de l’application de Scrum au cours des années précédentes.

Cette histoire de Scrum est déjà considérée comme longue. Pour honorer les premiers endroits où
Scrum a été essayé et affiné, nous reconnaissons « Individual », « Inc », « Fidelity Investments » et
« IDX » (Actuellement GE Medical).

Le guide Scrum documente le framework tel que développé et maintenu pendant plus de vingt ans
par Jeff Sutherland et Ken Schwaber. D’autres sources vous fournissent des patterns, des processus
et des idées montrant comment des pratiques, des facilitations, et des outils qui complètent le
framework Scrum. Ces pratiques permettent d’optimiser la productivité, la valeur, la créativité et la
fierté.


Traduction de la dernière version du guide officiel de Scrum (Version Juillet 2011)

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (20)

Semelhante a Traduction de la dernière version du guide officiel de Scrum (Version Juillet 2011)

Semelhante a Traduction de la dernière version du guide officiel de Scrum (Version Juillet 2011) (20)

Traduction de la dernière version du guide officiel de Scrum (Version Juillet 2011)