2.56 Le Scrum : une méthode pour optimiser l'action collective

Définition du Scrum

Le Scrum est un cadre de processus utilisé depuis le début des années 90 pour le développement, la livraison et la maintenance en produits complexes. Scrum n'est pas un processus, une technique ou une méthode définitive. C'est plutôt un cadre dans lequel vous pouvez utiliser divers processus et techniques. Scrum indique clairement l’efficacité relative de votre gestion de produit et de vos techniques de travail afin que vous puissiez améliorer en permanence le produit, l’équipe et l’environnement de travail.

Le cadre Scrum est constitué des équipes Scrum et leurs rôles, événements, artefacts et règles associés. Chaque composant du cadre sert un objectif spécifique et est essentiel au succès et à l'utilisation de Scrum.

Les règles de Scrum sont les modalités qui lient les rôles, les événements et les artefacts, régissant les relations et les interactions entre eux. Ces règles sont décrites tout au long de ce document. Les tactiques d'utilisation du Scrum sont variés. Elles feront partie d'un prochain article.

Usage du Scrum
Scrum a été initialement développé pour gérer et développer des produits. Depuis le début des années 90, Scrum a été largement utilisé dans le monde entier pour:

Rechercher et identifier des marchés, des technologies et des capacités de produits viables;
Développer des produits et des améliorations;
Publier des produits et des améliorations jusqu'à plusieurs fois par jour;
Développer et maintenir des environnements "Cloud" (en ligne, sécurisé, à la demande) et d’autres environnements opérationnels pour l’utilisation des produits; et,
Maintenir et renouveler des produits.

Scrum a été utilisé pour développer des logiciels, du matériel, des logiciels intégrés, des réseaux de fonctions interactives, des véhicules autonomes, des écoles, des administrations, du marketing, de la gestion du fonctionnement d’organisations et presque tout ce que nous utilisons dans notre vie quotidienne.

Plus il y a une augmentation des complexités sur le plan technologique, commerciales, et environnementales, ainsi que leurs interactions, plus l'utilité de Scrum pour faire face à cette à cette complexité est quotidiennement confirmée.

Scrum s'est avéré particulièrement efficace pour le transfert de connaissances itératif et incrémental de savoir. Scrum est maintenant largement utilisé pour les produits, les services et la gestion de l’organisation.

L’essence de Scrum est une petite équipe de personnes. L'équipe individuelle est plus flexible et adaptative. Ces atouts continuent de fonctionner au sein d’une, ou plusieurs réseaux d’équipes qui développent, diffusent, exploitent et maintiennent le travail et les produits professionnels de milliers de personnes. Ils collaborent et interagissent via des architectures de développement sophistiquées et des environnements de publication cibles.

Lorsque les termes "développer" et "développement" sont utilisés dans le guide Scrum, ils désignent des travaux complexes, tels que les types identifiés ci-dessus.

Utilisation du Scrum

Scrum a été initialement développé pour gérer et développer des produits. Depuis le début des années 90, Scrum a été largement utilisé dans le monde entier pour:

Rechercher et identifier des marchés, des technologies et des capacités de produits viables;
Développer des produits et des améliorations;
Publier des produits et des améliorations autant de fois par jour;
Développer et pérenniser le cloud (en ligne, sécurisé, à la demande) et d’autres environnements opérationnels pour l’utilisation des produits; et,
Soutenir et renouveler les produits.

Scrum a été utilisé pour développer des logiciels, du matériel, des logiciels intégrés, des réseaux de fonctions interactives, des véhicules autonomes, des écoles, des administrations, le marketing, la gestion du fonctionnement d’organisations et presque tout ce que nous utilisons dans notre vie quotidienne, en tant qu’individus et sociétés.

Alors que les complexités technologiques, commerciales et environnementales, ainsi que leurs interactions, ont rapidement augmenté, l'utilité de Scrum pour gérer la complexité est prouvée quotidiennement.

Scrum s'est avéré particulièrement efficace pour le transfert de connaissances itératif et progressif. Scrum est maintenant largement utilisé pour les produits, les services et la gestion de l’organisation mère.

L’essence de Scrum est une petite équipe de personnes. L'équipe individuelle est très flexible et adaptative. Ces atouts continuent de fonctionner au sein d’une, plusieurs, plusieurs et plusieurs réseaux d’équipes qui développent, diffusent, exploitent et maintiennent le travail et les produits professionnels de milliers de personnes. Ils collaborent et interagissent via des architectures de développement sophistiquées et des environnements de publication cibles.

Lorsque les termes "développer" et "développement" sont utilisés dans le guide Scrum, ils désignent des travaux complexes, tels que les types identifiés ci-dessus.

Théorie du Scrum

Scrum est fondé sur la théorie empirique du contrôle de processus, ou l’empirisme. L'empirisme affirme que la connaissance provient de l'expérience et la prise de décision se fait en fonction de ce que l'on sait. Scrum utilise une approche itérative et incrémentale pour optimiser la prédictibilité et le contrôle les risques.

Trois piliers soutiennent chaque mise en œuvre du contrôle de processus empirique: transparence, inspection et adaptation.

Transparence

Les aspects importants du processus doivent être visibles pour les responsables du résultat. La transparence exige que ces aspects soient définis par une norme commune afin que les observateurs partagent une même compréhension de ce qui est vu.

A titre d' exemple:

Un langage commun faisant référence au processus doit être partagé par tous les participants;
Ceux qui effectuent le travail et ceux qui inspectent l’augmentation qui en résulte doivent partager une définition commune de "Terminé".

Inspection

Les utilisateurs Scrum doivent fréquemment inspecter les artefacts Scrum et la progression vers un objectif de sprint afin de détecter les écarts indésirables. La fréquence des 'inspections ne devrait pas gêner le travail en cours. Les inspections sont plus utiles lorsqu'elles sont effectuées avec diligence par des inspecteurs qualifiés sur le lieu de travail.

Adaptation

Si un inspecteur détermine qu'un ou plusieurs aspects d'un processus s'écartent des limites acceptables et que le produit résultant sera inacceptable, le processus ou le matériel doit être ajusté. Un ajustement doit être effectué dès que possible pour minimiser le risque d'autres dérives.

Scrum prescrit quatre événements formels d'inspection et d'adaptation, tels que décrits dans la section Événements Scrum de ce document:

Planification du sprint (Sprint planning)
Mêlée quotidienne (Daily Scrum)
Revue de Sprint (Sprint Review)
Rétrospective Sprint (Sprint Retrospective)

Valeurs du Scrum

Lorsque les valeurs d’engagement, de courage, de concentration, d’ouverture et de respect sont incarnées et vécues par l’équipe Scrum, les piliers Scrum de transparence, d’inspection et d’adaptation prennent vie et renforcent la confiance de tous. Les membres de l'équipe Scrum apprennent et explorent ces valeurs au fur et à mesure qu'ils travaillent avec les événements, les rôles et les artefacts de Scrum.

Pour que Scrum soit utilisé avec succès, il faut que les gens maîtrisent mieux ces cinq valeurs. Les gens s’engagent personnellement à atteindre les objectifs de l’équipe Scrum. Les membres de l’équipe Scrum ont le courage de faire ce qui est juste et de travailler sur des problèmes difficiles. Tout le monde se concentre sur le travail du sprint et les objectifs de l'équipe Scrum. L’équipe Scrum et ses parties prenantes acceptent d’être ouvertes sur tout le travail et les défis liés à l’exécution de ce travail. Les membres de l'équipe Scrum se respectent en tant que personnes compétentes et indépendantes.

L'équipe Scrum

L’équipe Scrum se compose d’un responsable de produit (Product Owner), d'une l’équipe de développement et d’un Scrum Master. Les équipes Scrum sont auto-organisées et pluridisciplinaires. Les équipes auto-organisées choisissent la meilleure façon d'accomplir leur travail, plutôt que d'être dirigées par des personnes extérieures à l'équipe. Les équipes pluridisciplinaires ont toutes les compétences nécessaires pour accomplir le travail sans dépendre d'autres personnes ne faisant pas partie de l'équipe. Le modèle d'équipe dans Scrum est conçu pour optimiser la flexibilité, la créativité et la productivité. L’équipe Scrum s’est révélée de plus en plus efficace pour toutes les utilisations mentionnées précédemment et pour tout autre travail complexe.

Les équipes Scrum fournissent des produits de manière itérative et incrémentalle, maximisant ainsi les opportunités de retour d'informations. Les livraisons incrémentielles du produit "Terminé" garantissent qu'une version potentiellement utile du produit fonctionnel.

Le propriétaire du produit ( Product Owner)

Le Product Owner est responsable de la maximisation de la valeur du produit résultant du travail de l'équipe de développement. La façon dont cela est fait peut varier considérablement selon les organisations, les équipes Scrum et les individus. Le Product Owner est le seul responsable de la gestion du backlog de produits. La gestion du backlog de produit comprend:

L'expression claire les éléments du backlog de produit;
L'ordonnancement des éléments dans le backlog de produits pour mieux réaliser les objectifs et les missions;
L'optimisation de la valeur du travail effectué par l'équipe de développement;
L'assurance que le backlog de produit est visible, transparent et clair pour tous, et montre ce sur quoi l'équipe de développement travaillera ensuite;
L'assurance que l'équipe de développement comprend les éléments du backlog de produit au niveau requis.

Le responsable de produit peut effectuer le travail ci-dessus ou le confier à l'équipe de développement. Cependant, le propriétaire du produit reste responsable.

Le Product Owner est une personne, pas un comité. Le Product Owner peut représenter les souhaits d'un comité dans le backlog de produit, mais ceux qui souhaitent modifier la priorité d'un élément de backlog de produit doivent s'adresser à ce dernier.

Pour que le Product Owner réussisse, toute l'organisation doit respecter ses décisions. Les décisions du responsable du produit sont visibles dans le contenu et l'ordonnancement du backlog produit. Personne ne peut forcer l’équipe de développement à travailler à partir d'un autre ensemble d’exigences.

L'équipe de développement

L’équipe de développement est composée de professionnels qui s’emploient à créer un produit incrémental du produit "Terminé" qui peut être publié à la fin de chaque sprint. Un incrément "Terminé" est requis lors de la revue du sprint. Seuls les membres de l'équipe de développement créent l'incrément.

Les équipes de développement sont structurées et habilitées par l'organisation à organiser et gérer leur propre travail. La synergie qui en résulte optimise l'efficacité globale de l'équipe de développement.

Les équipes de développement présentent les caractéristiques suivantes:

Elles s'auto-organisent. Personne (pas même le Scrum Master) ne dit à l'équipe de développement comment transformer le backlog de produit en incréments de fonctionnalités potentiellement publiables.
Les équipes de développement sont pluridisciplinaires et possèdent toutes les compétences nécessaires pour créer un increment produit
Scrum ne reconnaît aucun titre aux membres de l’équipe de développement, quel que soit le travail effectué par la personne;
Scrum ne reconnaît aucune sous-équipe de l'équipe de développement, quels que soient les domaines à traiter, tels que les tests, l'architecture, les opérations ou l'analyse fonctionnelle, etc...
Les membres individuels de l'équipe de développement peuvent avoir des compétences spécialisées et des domaines d'intervention, mais la responsabilité appartient à l'équipe de développement dans son ensemble.

Taille de l'équipe de développement

Une équipe de développement optimale doit être suffisamment petite pour rester souple et suffisamment grande pour effectuer un travail important dans un sprint. Moins de trois membres de l'équipe de développement réduisent les interactions et entraînent des gains de productivité moins importants. Les équipes de développement plus petites peuvent rencontrer des contraintes de compétences pendant le sprint, ce qui empêche l'équipe de développement de fournir un incrément potentiellement publiable. A l'opposé, avoir plus de neuf membres nécessite trop de coordination. Les grandes équipes de développement génèrent trop de complexité pour qu'un processus empirique soit utile. Les rôles du Product Owner et du Scrum Master ne sont pas inclus dans ce décompte, sauf s'ils exécutent également le travail du Backlog Sprint.

Le Scrum Master

Le Scrum Master est responsable de la promotion et du soutien de Scrum tel que défini dans le Guide Scrum. Pour ce faire, Scrum Masters aide tout le monde à comprendre la théorie, les pratiques, les règles et les valeurs de Scrum.

Le Scrum Master est un leader serviteur de l’équipe Scrum. Le Scrum Master assiste les personnes extérieures à l'équipe Scrum à comprendre lesquelles de leurs interactions avec l'équipe Scrum sont utiles et celles qui ne le sont pas. le Scrum Master aide tout le monde à adapter leurs interactions avec l'équipe Scrum pour maximiser la valeur créée par cette équipe.

Le Scrum Master au service du Product Owner

Le Scrum Master sert le responsable de produit de plusieurs manières, notamment:

S'assurer que les objectifs, la portée et le domaine du produit sont compris par tous les membres de l'équipe Scrum aussi bien que possible;
Trouver des techniques pour une gestion efficace du backlog de produits;
Aider l'équipe Scrum à comprendre le besoin d'éléments de backlog de produits clairs et concis;
Comprendre la planification des produits dans un environnement empirique;
S'assurer que le responsable de produit sait comment organiser le backlog de produit afin de maximiser la valeur;
Comprendre et pratiquer l'agilité; et,
Faciliter les événements Scrum à la demande ou au besoin.
Service Scrum Master à l'équipe de développement

Le Scrum Master au service de l’équipe de développement

Le Scrum Master est au service de l'équipe de développement de plusieurs manières, notamment en:

Coachant l'équipe de développement en matière d'auto-organisation et de pluridisciplinarité;
Aidant l'équipe de développement à créer des produits de grande valeur;
Éliminant les obstacles à la progression de l'équipe de développement;
Facilitant les événements Scrum à la demande ou au besoin, etc...
Coachant l'équipe de développement dans des environnements organisationnels dans lesquels Scrum n'est pas encore complètement adopté et compris.
Service Scrum Master à l'organisation

Le Scrum Master au service de l'organisation:

Le Scrum Master sert l’organisation de plusieurs manières, notamment en:

Accompagnant l'organisation dans son adoption de Scrum;
Planifiant les implémentations du Scrum au sein de l'organisation;
Aidant les employés et les parties prenantes à comprendre et à mettre en œuvre Scrum et le développement de produits empiriques;
Provoquant des changements qui augmentent la productivité de l'équipe Scrum;
Collaborant avec d'autres Scrum Master pour accroître l'efficacité de l'application du Scrum dans l'organisation.

Les Evénements du Scrum

Les événements prescrits sont utilisés par Scrum pour créer la régularité et minimiser le besoin de réunions non définies par Scrum. Tous les événements sont limités dans le temps ; en boîte de temps (time-boxés), de telle sorte que chaque événement ait une durée maximale. Une fois qu'un Sprint commence, sa durée est fixe et ne peut être écourtée ou prolongée. Les autres événements peuvent se terminer dès que leurs objectifs sont atteints, tout en assurant qu’il y a eu suffisamment de temps accordé pour ces événements sans pour autant permettre le gaspillage dans le processus.

Outre le Sprint lui-même, qui est un conteneur pour tous les autres événements, chaque événement Scrum est une occasion formelle d'inspecter et d'adapter quelque chose. Ces événements sont spécifiquement conçus pour permettre la transparence et l’inspection. Ne pas inclure l’un de ces événements entraîne une transparence réduite et constitue une occasion perdue d'inspection et d'adaptation.

Le Sprint:

Le cœur de Scrum est le Sprint, qui a une boîte de temps (time-box), une durée, d'un mois ou moins au cours de laquelle un Incrément Produit « Fini » fonctionnel et potentiellement publiable est créé. Les sprints ont une durée cohérente durant la phase de développement. Un nouveau Sprint commence immédiatement après la conclusion du Sprint précédent.

Les Sprints contiennent et consistent en une planification du Sprint (Sprint Planning), des mêlées quotidiennes (Daily Scrums), des activités de développement, une revue de sprint (Sprint Review) et une rétrospective de Sprint (Sprint Retrospective).

Pendant le Sprint:

L’objectif du sprint est fixe ; les changements qui le remettent en cause ne sont donc pas permis ;
Les objectifs de qualité sont maintenus ; ils ne sont jamais revus à la baisse ; et,
Le périmètre peut être clarifié et renégocié entre le Product Owner et l’équipe de développement selon ce que l’équipe Scrum apprend.

Chaque sprint peut être considéré comme un projet n'ayant qu'un horizon d'un mois. À l’instar d’un projet, un Sprint est utilisé pour accomplir quelque chose. Chaque Sprint a un objectif de ce qui doit être construit, une conception (design) et un plan flexible qui guidera la construction, le travail lui même et l’incrément produit résultant.

Les sprints sont limités à un mois calendaire. Lorsque l'échéance d'un Sprint est trop longue, la définition de ce qui est en cours de construction peut changer, la complexité peut augmenter et le risque peut s'accroître. Les sprints permettent la prédictibilité en assurant l'inspection et l'adaptation de la progression vers un objectif du Sprint (Sprint Goal) au moins tous les mois calendaires. Les sprints limitent également le risque à un coût maximal d’un mois calendaire.

Annulation d'un Sprint:

Un Sprint peut être annulé avant son échéance. Seul le Product Owner a le pouvoir d'annuler le Sprint, bien qu'il ou elle puisse le faire sous l'influence des parties prenantes, de l'équipe de développement ou du Scrum Master.

Un Sprint serait annulé si l'objectif du Sprint devient obsolète. Cela pourrait se produire si l'organisation change de direction ou si les conditions de marché ou celles technologiques changent. En général, un Sprint devrait être annulé s'il n'a plus de sens compte tenu des circonstances. Mais en raison de la courte durée de Sprints, l'annulation est rarement justifiable.

Lorsqu'un Sprint est annulé, tous les éléments achevés et « Finis » du Backlog produit (PBIs : Product Backlog Items) sont examinés. Généralement, si une partie du travail est potentiellement publiable, le Product Owner l'accepte. Tous les éléments du Backlog produit incomplets sont estimés à nouveau et remis au Backlog produit. Le travail effectué en vue de les compléter se déprécie rapidement et doit être fréquemment estimé à nouveau.

Les annulations Sprint consomment des ressources, car tout le monde se regroupe dans une autre réunion de planification du Sprint (Sprint Planning) pour commencer un autre Sprint. Les annulations Sprint sont souvent bouleversantes pour l'équipe Scrum et sont très peu fréquentes.

Planification du Sprint:

Le travail à effectuer durant un Sprint est défini durant la réunion de Planification du Sprint (Sprint Planning). Ce plan est créé de manière collaborative par tous les membres de l'équipe Scrum. La réunion de planification du Sprint dure au maximum huit heures pour un Sprint d'un mois. Pour les sprints plus courts, l'événement est généralement plus court. Le Scrum Master veille à ce que l’événement ait lieu et que les participants en comprennent le but. Le Scrum Master apprend à l'équipe Scrum à le garder dans la boîte de temps (time-box).

La Planification du Sprint répond aux questions suivantes :

Que peut-on livrer comme incrément résultant du Sprint à venir ?
Comment sera effectué le travail à livrer et nécessaire pour achever l'Incrément?

Thème 1: Que peut - on faire de ce Sprint:

L'équipe de développement travaille à prévoir les fonctionnalités qui seront développées pendant le Sprint. Le Product Owner discute de l’objectif que le Sprint devrait concrétiser et des éléments du Backlog produit qui, s’ils sont complétés durant le Sprint, pourraient permettre d’atteindre l'objectif du Sprint. Toute l'équipe Scrum collabore pour comprendre le travail requis durant le Sprint.

Les éléments nécessaires pour le démarrage de la réunion de Planification du Sprint sont le Backlog produit, le dernier incrément produit, la capacité projetée par l'équipe de développement pendant le Sprint et les performances passées de l'équipe de développement. Le nombre d’éléments sélectionnés du Backlog produit pour le Sprint revient uniquement à l'équipe de développement. Seule l'équipe de développement peut évaluer ce qu'elle peut accomplir durant le Sprint à venir.

Durant la planification du Sprint (Sprint Planning), l’équipe Scrum détermine aussi l’objectif du Sprint (Sprint Goal). Il s’agit d’un objectif qui sera atteint durant le sprint grâçe à l’implémentation des éléments du backlog produit choisis, et qui fournit à l’équipe de développement la raison pour laquelle elle développe l’incrément.

Thème Deux: Comment le travail choisi sera-t-il terminé ?

Une fois l’objectif du sprint fixé et les éléments du Backlog Produit choisis, l’équipe de développement planifie le travail pour transformer cette fonctionnalité en un incrément produit «Fini» durant le Sprint. Les éléments du Backlog produit sélectionnés pour ce sprint plus le plan de travail pour les livrer est appelé le Backlog Sprint (Sprint Backlog).

L'équipe de développement commence généralement par la conception du système et du travail nécessaire afin de transformer le Backlog produit en un incrément fonctionnel du produit. La taille ou l’effort estimé du travail peut varier. Cependant, lors de la réunion de planification, l’équipe de développement doit envisager suffisamment de travail pour qu’elle ait une bonne idée de ce qu'elle pense pouvoir accomplir durant le Sprint. Avant la fin de la réunion, l’équipe de développement décompose le travail prévu pour les premiers jours du Sprint, souvent jusqu'à une granularité d'une journée ou moins. L'équipe de développement s'auto-organise pour entreprendre le travail consigné au Backlog Sprint, à la fois lors de la réunion de Planification du Sprint et quand cela est nécessaire tout au long du Sprint.

Le Product Owner peut aider à clarifier les éléments du Backlog Produit choisis et à faire des compromis. Si l’équipe de développement détermine qu’elle a trop ou pas assez de travail, elle peut renégocier les éléments du Backlog Produit choisis avec le Product Owner. L’équipe de développement peut également inviter d’autres personnes à la réunion pour recevoir des conseils techniques ou liés au domaine.

À la fin de la planification du Sprint, l’équipe de développement devrait être en mesure d’expliquer au Product Owner et au Scrum Master comment elle entend s’organiser pour réaliser l’objectif du Sprint et créer l’incrément prévu.

Objectif du Sprint:

L’objectif du Sprint (Sprint Goal) est un but fixé pour le Sprint et peut être réalisé par l’implémentation d’une partie du Backlog Produit. Il fournit à l’équipe de développement la raison pour laquelle elle construit l’incrément du produit. Il est défini lors de la réunion de planification du Sprint (Sprint Planning). L’objectif du Sprint fournit à l’équipe de développement une certaine flexibilité quant à la fonctionnalité implémentée durant le Sprint. Les éléments du

Backlog Produit sélectionnés offrent une fonction cohérente, ce qui peut faire office d’objectif du Sprint. Par ailleurs, l’objectif du Sprint peut être une autre source de cohérence poussant l’équipe de développement à travailler ensemble au lieu d’entreprendre des initiatives distinctes.

Tout en effectuant son travail, l’équipe de développement garde à l’esprit l’objectif du Sprint. Afin d’atteindre l’objectif du Sprint, l’équipe implémente les fonctionnalités et les technologies nécessaires. Si le travail se révèle différent de ce qui a été prévu, l’équipe de développement collabore avec le Product Owner et négocie le périmètre du Backlog Sprint durant le sprint.

Daily Scrum:

La mêlée quotidienne (Daily Scrum) est un événement de 15 minutes (time-boxé) destiné à l'équipe de développement. La mêlée quotidienne est tenue tous les jours du Sprint. L’équipe de développement planifie le travail pour les prochaines 24 heures. Cela optimise la collaboration et la performance de l'équipe tout en inspectant le travail depuis la dernière mêlée quotidienne et envisageant le travail restant durant le Sprint. La mêlée quotidienne est tenue à la même heure et au même lieu chaque jour pour réduire la complexité.

L'équipe de développement utilise la mêlée quotidienne pour inspecter son avancement vers l'objectif du Sprint et comment cet avancement tend à l'achèvement des travaux prévus dans le Backlog Sprint. La mêlée quotidienne optimise la probabilité que l'équipe de développement va atteindre l'objectif du Sprint. Chaque jour, l'équipe de développement doit comprendre comment elle entend travailler ensemble en tant qu'équipe auto-organisée pour atteindre l'objectif du Sprint et créer l'Incrément prévu à la fin du Sprint.

La structure de la réunion est définie par l'équipe de développement et peut être conduite de différentes manières si elle se concentre sur la progression vers l'objectif du Sprint. Certaines équipes de développement utiliseront les questions, d'autres seront plus basées sur la discussion. Voici un exemple de ce qui pourrait être utilisé :

Qu'est-ce que j'ai fait hier qui a aidé l'équipe de développement à atteindre l'objectif du Sprint ?
Que ferai-je aujourd'hui pour aider l'équipe de développement à atteindre l'objectif du Sprint ?
Est-ce que je vois des obstacles qui m'empêchent ou empêchent l'équipe de développement de respecter l'objectif du Sprint ?

L'équipe de développement ou les membres de l'équipe se rencontrent souvent immédiatement après la mêlée quotidienne pour des discussions détaillées ou pour adapter ou planifier à nouveau le reste du travail du Sprint.

Le Scrum Master s’assure que la mêlée quotidienne a lieu, mais c’est l’équipe de développement qui est responsable de son déroulement. Le Scrum Master apprend à l’équipe de développement à limiter la mêlée quotidienne à 15 minutes.

La mêlée quotidienne est une réunion interne pour l'équipe de développement. Si d'autres personnes sont présentes, le Scrum Master s'assure qu'elles ne perturbent pas la réunion.

Les mêlées quotidiennes améliorent la communication, éliminent les autres réunions, identifient les obstacles à éliminer qui perturbent le développement, mettent en avant et encouragent la prise de décision rapide tout en améliorant le niveau de savoir au sein l’équipe de développement. Il s’agit d’un point clé d’inspection et d’adaptation.

Revue du Sprint:

Une revue de Sprint (Sprint Review) est tenue à la fin du Sprint pour inspecter l’incrément réalisé et adapter le Backlog Produit si nécessaire. Pendant la revue de Sprint, l'équipe Scrum et les parties prenantes échangent sur ce qui a été fait durant le Sprint.

Sur la base de cela et de tout changement du Backlog Produit survenus pendant le sprint, les participants collaborent sur les prochains travaux qui pourraient être faits pour optimiser la valeur. Cette réunion se veut informelle, pas une réunion de pilotage, et la présentation de l'incrément est destinée à susciter les réactions et à favoriser la collaboration.

Il s'agit au maximum d'une réunion de quatre heures pour les sprints d'un mois. Pour les sprints plus courts, l'événement est généralement plus court. Le Scrum Master s’assure que l’événement ait lieu et que les participants en comprennent son but. Le Scrum Master apprend à tous ceux qui y sont impliqués à le garder dans la boîte de temps (time-boxé).

La Revue de sprint comprend les éléments suivants :

Les participants incluent l'équipe Scrum et les principales parties prenantes invitées par le Product Owner ;
Le Product Owner indique quels éléments du Backlog Produit ont été « Finis » et ceux qui n'ont pas été « Finis » ;
L’équipe de développement discute de ce qui s’est bien passé pendant le Sprint, quels problèmes ont été rencontrés, et comment ces problèmes ont été résolus ;
L'équipe de développement démontre le travail « Fini » et répond aux questions sur l'incrément ;
Le Product Owner discute de l’état actuel du Backlog Produit tel qu'il est. Il ou elle projette les dates prévisionnelles et celles de livraison en fonction des progressions réalisées à ce jour (si nécessaire) ;
L'ensemble du groupe convient de ce qu'il faut faire pour la suite, de sorte que la revue de sprint fournisse une contribution précieuse à la prochaine réunion de Planification du Sprint ;
La revue de la façon dont les conditions de marché ou un usage potentiel du produit pourrait avoir dicté ce qu’il conviendrait mieux de faire dorénavant ;
La revue des délais, budget, fonctionnalités potentielles et conditions de marché pour les prochaines versions prévues de la fonctionnalité du produit.

Le résultat de la revue de sprint est un Backlog Produit révisé qui définit les éléments probables pour le prochain Sprint. Le Backlog Produit peut également être globalement ajusté pour répondre aux nouvelles opportunités d’affaires.

Réstrospective du Sprint:

La rétrospective de Sprint (Sprint Retrospective) est une opportunité pour l'équipe Scrum de s’auto-inspecter et de créer un plan d'améliorations à adopter au cours du prochain Sprint.

La rétrospective de Sprint se produit après la revue de sprint et avant la prochaine réunion de planification du Sprint. Il s'agit au maximum d'une réunion de trois heures pour les Sprints d'un mois. Pour les sprints plus courts, l'événement est généralement plus court. Le Scrum Master s’assure que l’événement ait lieu et que les participants en comprennent son but.

Le Scrum Master s'assure que la réunion est positive et productive. Le Scrum Master apprend à tous ceux qui y sont impliqués à la garder dans la boîte de temps (time-box). Le Scrum Master participe en tant que membre de l’équipe Scrum et y amène le point de vue du responsable du processus Scrum.

Le but de la rétrospective de Sprint est de :

Inspecter la manière dont le dernier Sprint s’est déroulé en ce qui concerne les personnes, les relations, les processus et les outils ;
Identifier et ordonner les principaux éléments qui ont bien fonctionné et des améliorations potentielles ; et,
Créer un plan pour mettre en œuvre des améliorations sur la façon dont l'équipe Scrum fait son travail.

Le Scrum Master encourage l'équipe Scrum à améliorer, dans le cadre de travail Scrum, son processus de développement et ses pratiques afin de les rendre plus efficaces et agréables pour le prochain Sprint. Lors de chaque rétrospective de Sprint, l'équipe Scrum propose des moyens adéquats pour accroître la qualité du produit tout en améliorant les processus de travail ou adaptant la définition de « Fini », le cas échéant, ces moyens n’entrent pas en contradiction avec les normes du produit ou celles de l'organisation.

À la fin de la rétrospective de Sprint, l'équipe Scrum devrait avoir identifié les améliorations qu'elle mettra en œuvre dans le prochain Sprint. La mise en œuvre de ces améliorations dans le prochain Sprint est l'adaptation à l'inspection de l'équipe Scrum elle-même. Bien que des améliorations puissent être mises en œuvre à tout moment, la rétrospective de Sprint offre une opportunité formelle d'inspection et d'adaptation.

Les artefacts du Scrum

Les artefacts de Scrum représentent soit du travail, soit de la valeur fournissant ainsi de la transparence et des opportunités pour l'inspection et d'adaptation. Les artefacts définis par Scrum sont spécialement conçus pour maximiser la transparence d’informations essentielles afin que chacun ait la même compréhension de l'artefact.

Backlog Produit:

Le Backlog Produit est une liste ordonnée de tous les éléments identifiés comme nécessaires au produit. Il constitue l’unique source d'exigences pour tout changement à apporter au produit. Le Product Owner est responsable du Backlog produit, y compris son contenu, sa disponibilité et son ordonnancement.

Un Backlog Produit n'est jamais complet. Ses toutes premières moutures ne font qu’esquisser les besoins tels qu’initialement connus et compris. Le Backlog Produit évolue au fur et à mesure que le produit et le contexte dans lequel il sera utilisé évoluent. Le Backlog Produit est dynamique ; il change constamment pour identifier ce que le produit requiert pour être approprié, compétitif et utile. Si un produit existe, son Backlog Produit existe.

Le Backlog Produit liste toutes les fonctionnalités, les fonctions, les exigences, les améliorations et les corrections qui constituent des modifications à apporter au produit dans les versions futures. Les éléments du backlog produit se composent d'une description, d'un ordre, d'une estimation et d'une valeur. Les éléments du backlog produit incluent souvent des descriptions du test qui prouveront leur complétude lorsqu’ils sont « Finis ».

À mesure qu’un produit est utilisé, que sa valeur augmente et que l’on commence à recevoir des retours sur son utilisation, le Backlog produit devient une liste plus vaste et plus exhaustive. Les exigences ne cessent jamais de changer, de sorte qu'un Backlog produit est un artefact vivant. Les changements de besoins de l'organisation, des conditions de marché ou de la technologie peuvent entraîner des changements dans le Backlog produit.

Il arrive souvent que plusieurs équipes Scrum travaillent sur le même produit. Un seul Backlog Produit est utilisé pour décrire le travail à faire sur ce produit. On peut alors ajouter un attribut aux éléments du Backlog Produit pour les regrouper.

Le raffinement du backlog de produit (Product Backlog Refinement) consiste en l’ajout de détails, d’estimations et de l’ordonnancement des éléments du Backlog Produit. Il s’agit d’une activité régulière dans laquelle le Product Owner et l’équipe de développement collaborent pour détailler les éléments du Backlog Produit. Durant le raffinement du Backlog Produit, les éléments sont revisités et révisés. L’équipe Scrum décide comment et quand le raffinement est effectué. Le raffinement n’occupe généralement pas plus de 10% de la capacité de l’équipe de développement. Toutefois, les éléments du Backlog Produit peuvent être modifiés à n’importe quel moment par le Product Owner ou à sa discrétion.

Les premiers éléments du Backlog Produit sont généralement plus détaillés que les suivants. Leur estimation est plus précise grâçe à une plus grande clarté et un niveau de détail accru. Les éléments qui sont placés plus loin dans le Backlog Produit sont moins détaillés. Les éléments qui occuperont l’équipe de développement durant le prochain Sprint sont affinés au point que n’importe lequel peut être raisonnablement « Fini » dans un Sprint. Ces éléments sont réputés « Prêts » pour leur sélection durant la planification du Sprint. Les éléments du Backlog Produit acquièrent ce degré de transparence grâce aux activités de raffinements décrites plus haut.

L'équipe de développement est responsable de toutes les estimations. Le Product Owner peut influencer l'équipe de développement en l’aidant dans sa compréhension et le choix des compromis, mais les personnes qui effectueront le travail ont le mot final sur les estimations.

Suivi de la progression vers les objectifs:

À tout moment, la somme de travail restant pour atteindre un objectif de développement peut être calculée. Le Product Owner suit l’évolution de la somme de travail restant au moins à chaque revue de sprint. Il compare cette quantité à la somme de travail restant lors des revues des Sprints précédents afin d’évaluer la progression vers l’achèvement du travail prévu dans les délais voulus par l'objectif. Cette information est rendue transparente pour toutes les parties prenantes.

Diverses pratiques de projections des tendances telles que les « burn-downs », les « burn- ups » ou les « cummulative flow » ont été utilisées afin de prévoir la progression. Ces pratiques ont prouvé leur utilité. Toutefois, elles ne remplacent pas l’importance de l’empirisme. Dans les environnements complexes, ce qui se passera est inconnu. Seul ce qui s’est déjà passé peut être utilisé pour la prise de décision prévisionnelle.

Blacklog Sprint:

Le Backlog Sprint est l’ensemble des éléments sélectionnés pour le Sprint plus un plan pour livrer l’incrément du produit et réaliser l’objectif du Sprint. Le Backlog Sprint est une prévision que l’équipe de développement fait de la fonctionnalité qui sera présente dans le prochain incrément et le travail nécessaire pour livrer cette fonctionnalité dans un incrément « Fini ».

Le Backlog Sprint rend visible tout le travail que l'équipe de développement identifie comme nécessaire pour atteindre l'objectif du Sprint. Pour assurer une amélioration continue, il

comprend au moins une amélioration de processus, hautement prioritaire, identifiée lors de la précédente réunion de rétrospective de Sprint.

Le Backlog Sprint est un plan suffisamment détaillé pour que la progression soit compréhensible lors de la mêlée quotidienne. L’équipe de développement modifie le Backlog Sprint tout au long du Sprint, et le Backlog Sprint émerge durant le Sprint. Cette émergence a lieu alors même que l’équipe de développement exécute le plan et découvre le travail nécessaire pour atteindre l’objectif du Sprint.

À mesure que du nouveau travail est nécessaire, l’équipe de développement l’ajoute au Backlog Sprint. Lorsque le travail est effectué ou complété, les estimations du travail restant sont mises à jour. Lorsque des éléments du plan sont jugés inutiles, ils sont écartés. Seule l’équipe de développement peut changer son Backlog Sprint durant un Sprint. Le Backlog Sprint est une vue en temps-réel et très visible du travail que l’équipe de développement prévoit d’accomplir durant le Sprint et il appartient uniquement à l’équipe de développement.

Suivi de la progression du Sprint:

À n’importe quel moment d’un sprint, la somme totale du travail restant dans le Backlog Sprint peut être calculée. L’équipe de développement fait le suivi de cette somme de travail restant au moins à chaque mêlée quotidienne pour évaluer la probabilité d’atteindre l’objectif du Sprint. En effectuant le suivi du travail restant tout au long du sprint, l’équipe de développement peut gérer son avancement.

Incrément:

L'incrément est constitué des éléments du Backlog produit « Finis » pendant le sprint ainsi que de la valeur cumulative des incréments livrés dans les sprints précédents. À la fin d’un Sprint, le nouvel incrément doit être « Fini », ce qui implique qu’il doit être dans un état publiable et qu’il correspond à la définition de « Fini » (Definition of Done) de l’équipe de développement. Un incrément est la partie d’un travail fait, qui prend en charge l'empirisme, et vérifiable à la fin du Sprint. L'incrément est un pas vers une vision ou un but. L’incrément doit être dans un état publiable, sans égard à la décision du Product Owner de le publier ou non.

Artéfact de la transparence :

Scrum repose sur la transparence. Les décisions d’optimiser la valeur et contrôler le risque sont prises en se basant sur l’état perçu des artefacts. Dans la mesure où la transparence est complète, ces décisions ont une base solide. Dans la mesure où les artefacts ne sont pas totalement transparents, ces décisions peuvent être faussées, la valeur peut diminuer et le risque peut augmenter.

Le Scrum Master doit travailler avec le Product Owner, l’équipe de développement et les autres parties impliquées pour comprendre si les artefacts sont complètement transparents. Il existe

des pratiques pour faire face à une transparence incomplete ; le Scrum Master doit aider tout le monde à appliquer les pratiques les plus appropriées en l’absence d’une transparence complète. Un Scrum Master peut détecter une transparence incomplète en inspectant les artefacts, en identifiant certains usages récurrents, en écoutant attentivement ce qui est dit et en décelant les différences entre les résultats escomptés et réels.

La responsabilité du Scrum Master consiste à travailler avec l’équipe Scrum et l’organisation afin d’accroître la transparence des artefacts. Ce travail implique généralement l’apprentissage, la persuasion et le changement. La transparence ne se produit pas du jour au lendemain, mais est plutôt un chemin.

Définition du "fini":

Lorsqu'un élément du Backlog produit ou un Incrément est décrit comme « Fini », tout le monde doit comprendre ce que « Fini » signifie. Bien que cela puisse varier considérablement d’une équipe Scrum à une autre, les membres doivent avoir une compréhension commune de ce que signifie que le travail soit complet, afin d'assurer la transparence. Il s'agit de la définition de
« Fini » (Definition of Done) pour l'équipe Scrum. Celle-ci est utilisée pour évaluer si le travail est terminé dans un incrément produit.

La même définition guide l'équipe de développement en sachant combien d'éléments de Backlog produit elle peut choisir au cours de la Planification du Sprint. L’objectif de chaque Sprint est de fournir des Incréments de fonctionnalités potentiellement publiables qui adhèrent à la définition de « Fini » actuelle de l’équipe Scrum.

Les équipes de développement fournissent un incrément de la fonctionnalité du produit à chaque Sprint. Cet incrément est publiable, de telle sorte qu'un Product Owner peut choisir de le publier immédiatement. Si la définition de « Fini » d’un incrément fait partie des conventions, standards ou lignes directrices de l’organisation de développement, toutes les équipes doivent au minimum la respecter.
Si la définition de « Fini » n'est pas une convention de l'organisation de développement, l'équipe de développement de l'équipe Scrum doit établir une définition de « Fini » appropriée pour le produit. S'il existe plusieurs équipes Scrum travaillant sur la livraison d’un système ou un produit, les équipes de développement de toutes les équipes Scrum doivent mutuellement définir une définition de « Fini ».

Chaque Incrément est ajouté à tous les Incréments précédents et testé de manière approfondie, tout en veillant à ce que tous les Incréments fonctionnent ensemble.

Au fur et à mesure que les équipes de Scrum mûrissent, on s'attend à ce que leurs définitions de « Fini » se développent pour inclure des critères plus stricts pour une meilleure qualité. L’utilisation d’une nouvelle définition de « Fini » peut révéler le travail à faire dans les incréments précédemment « Finis ». Tout produit ou système devrait avoir une définition de « Fini » qui est une norme pour tout travail effectué.

Note de fin et remerciements

Les rôles, les événements, les artefacts et les règles de Scrum sont immuables et, bien que la mise en œuvre de certaines parties de Scrum soit possible, le résultat n'est pas Scrum. Scrum n'existe que dans sa totalité et fonctionne bien comme un conteneur pour d'autres techniques, méthodologies et pratiques.

Les rôles, les événements, les artefacts et les règles de Scrum sont immuables et, bien que la mise en œuvre de certaines parties de Scrum soit possible, le résultat n'est pas Scrum. Scrum n'existe que dans sa totalité et fonctionne bien comme un conteneur pour d'autres techniques, méthodologies et pratiques.

Personnes:

Parmi les milliers de personnes qui ont contribué à Scrum, nous devrions distinguer ceux qui ont joué un rôle déterminant dès le départ: Jeff Sutherland a travaillé avec Jeff McKenna et John Scumniotales, et Ken Schwaber a travaillé avec Mike Smith et Chris Martin, et qui ont tous travaillé ensemble. Beaucoup d'autres ont contribué dans les années suivantes et sans leur aide, Scrum ne serait pas aussi affiné qu'il l’est aujourd'hui.

Historique:

Ken Schwaber et Jeff Sutherland ont travaillé sur Scrum jusqu'en 1995 lorsqu'ils ont co-présenté Scrum à la conférence OOPSLA en 1995. Cette présentation a essentiellement documenté l'apprentissage que Ken et Jeff ont acquis au cours des dernières années et rendu public la première définition formelle de Scrum.

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

Le Guide Scrum documente Scrum tel que développé, évolué et soutenu pendant plus de 20 ans par Jeff Sutherland et Ken Schwaber. D'autres sources vous fournissent des modèles, des processus et des idées qui complètent le cadre Scrum. Ceux-ci optimisent la productivité, la valeur, la créativité et la satisfaction par rapport aux résultats.

Traduction:

Ce guide a été traduit de la version originale anglaise, fournie par Ken Schwaber et Jeff Sutherland. L’équipe de traduction en langue Française est gérée par Kamel Kaouech.

L’équipe de traduction tient à remercier les contributeurs à la traduction des anciennes versions du Guide Scrum. Les traducteurs du présent guide, la version 2017 du Guide Scrum, désirent aussi remercier spécialement Mariem Sassi, Tristan Libersat et Christian Lapointe pour la relecture. Information Importante : L'utilisation du genre masculin a été adoptée afin de faciliter la lecture et n'a aucune intention discriminatoire.