Activités et artefacts de Scrum

Ci-dessous, nous expliquons non seulement les activités et artefacts les plus importants de Scrum, mais aussi comment ils sont interconnectés.

Le Product Owner a une vision produit spécifique. Comme le produit peut être très complexe, il est décomposé en fonctionnalités (éléments) plus petites grâce au Backlog Refinement, qui sont ensuite listées par ordre de priorité dans le Product Backlog.

Un Sprint commence par le Sprint Planning, inclut le travail de développement (Sprint Execution) pendant le Sprint et se termine par la Review et la Rétrospective. Le nombre d'éléments dans le Product Backlog est généralement plus élevé que ce qu'une équipe de développement pourrait accomplir durant une courte phase de Sprint. C'est pourquoi l'équipe de développement doit d'abord identifier certains éléments du Product Backlog qu'elle pense pouvoir terminer (Sprint Planning). L'objectif est d'avoir un incrément de produit potentiellement livrable à la fin du Sprint.

Une remarque sur les activités dans Scrum

En 2011, une modification dans "The Scrum Guide" (Schwaber et Sutherland 2011) a déclenché un débat sur le terme approprié pour décrire le résultat du Sprint Planning : "forecast" (prévision/estimation) ou "commitment" (engagement). Les partisans du terme Forecast préfèrent cette terminologie car même la meilleure estimation peut changer au cours d'un Sprint suite à de nouvelles informations. Certains estiment également qu'un Commitment de la part de l'équipe pourrait nuire à la qualité du travail, soit parce qu'on cherche à atteindre cet objectif fixé à tout prix, soit parce que l'équipe peut avoir tendance à se fixer des objectifs trop bas pour être sûre de les atteindre.

Il est indéniable que chaque équipe de développement devrait fournir une estimation de ce qu'elle pense pouvoir accomplir durant un Sprint. Cependant, de nombreuses équipes de développement pourraient bénéficier de la transformation d'un Forecast en Commitment. Les Commitments renforcent en effet la confiance entre le Product Owner et l'équipe de développement, tout comme entre les différents membres de l'équipe. De plus, les Commitments facilitent la planification à court terme et une prise de décision pertinente au sein d'une entreprise. Lorsque plusieurs équipes participent au développement d'un produit, les Commitments leur permettent de mieux coordonner leur planification – une équipe peut s'appuyer sur le Commitment d'une autre équipe pour prendre ses décisions. Un Commitment devrait cependant se concentrer principalement sur l'objectif du Sprint plutôt que sur les tâches en cours. Avec l'accumulation des connaissances, les équipes parviennent souvent à atteindre l'objectif du Sprint différemment de ce qui était initialement prévu. (Dans la suite, le terme Commitment sera principalement utilisé. Selon le contexte, le terme Forecast sera toutefois employé de temps en temps.)

Pour s'assurer que l'équipe de développement a défini un Commitment pertinent, les membres de l'équipe créent un second Backlog au cours du Sprint Planning, appelé Sprint Backlog. Ce Sprint Backlog décrit, à travers des tâches détaillées, comment l'équipe prévoit de concevoir, développer, intégrer et tester les différentes fonctionnalités du Product Backlog durant ce Sprint.

L'étape suivante s'appelle Sprint Execution, c'est-à-dire l'exécution du Sprint. L'équipe de développement y réalise les tâches nécessaires pour implémenter les fonctionnalités sélectionnées. Durant cette phase, des Daily Scrums ont lieu quotidiennement, permettant des activités de synchronisation et de vérification ainsi que des activités de planification adaptative. Cela permet aux membres de l'équipe de mieux gérer leurs flux de travail. À la fin de la Sprint Execution, l'équipe a produit un incrément de produit potentiellement livrable, qui représente déjà une partie de ce que le Product Owner avait imaginé.

L'équipe Scrum termine le Sprint par l'inspection et l'adaptation (inspect-and-adapt) du produit et du processus Scrum. Le produit est examiné lors du Sprint Review par l'équipe Scrum et les parties prenantes. L'inspection du processus Scrum utilisé pour créer le produit est effectuée par les membres de l'équipe lors d'un événement appelé Rétrospective. Des ajustements peuvent ensuite être apportés au Product Backlog ou au processus de développement.

À ce stade, le cycle de Sprint recommence. L'équipe de développement détermine maintenant les prochains Product Backlog Items qu'elle peut terminer. Après un nombre approprié de Sprints, la vision du Product Owner sera réalisée et le résultat pourra alors être présenté.

Dans ce qui suit, chacune de ces activités et chacun de ces artefacts seront traités en détail.

Carnet de produit

Dans le travail avec Scrum, on s'occupe toujours en premier des tâches les plus précieuses. Le Product Owner est – en concertation avec l'équipe de développement et les parties prenantes – responsable en fin de compte de l'ordre de ces étapes de travail et doit les communiquer dans une liste de priorités, le Product Backlog. Lors du développement de nouveaux produits, les Product Backlog Items ne sont d'abord que des fonctionnalités nécessaires pour concrétiser la vision du Product Owner. Lors de l'évolution de produits existants, le Product Backlog peut aussi contenir de nouvelles fonctionnalités, ainsi que des modifications de fonctionnalités existantes, des corrections de défauts nécessaires ou des améliorations techniques, etc.

Le Product Owner collabore avec les parties prenantes internes et externes pour rassembler et définir les Product Backlog Items. Il doit ensuite s'assurer que tous les items sont placés dans le bon ordre (en fonction de la valeur, des coûts, des connaissances et des risques), de sorte que les items les plus précieux apparaissent en haut et les moins précieux plus bas dans le Product Backlog. Le Product Backlog est un artefact en constante évolution. Lorsque les circonstances d'une entreprise changent ou que la compréhension du produit par l'équipe Scrum s'approfondit (grâce aux retours pendant les Sprints), des items peuvent être ajoutés, supprimés et retravaillés par le Product Owner.

De manière générale, la conception, l'élaboration, l'évaluation et la priorisation des Product Backlog Items s'appelle le Backlog Grooming ou Backlog Refinement.

Avant de pouvoir finaliser la priorisation ou l'ordonnancement des items dans le Product Backlog, il faut d'abord connaître l'envergure de chaque item. L'envergure détermine les coûts, et le Product Owner doit les connaître pour pouvoir définir la priorité d'un item. Scrum ne prescrit pas d'unité de mesure spécifique. En pratique, de nombreuses équipes utilisent des unités relatives comme les Story Points ou les Ideal Days. Une unité relative n'exprime pas l'envergure absolue d'un item, mais seulement son envergure par rapport aux autres items.

Sprints

En Scrum, il existe des itérations ou cycles pouvant aller jusqu'à un mois, appelés Sprints. Un Sprint terminé devrait toujours produire quelque chose de valeur tangible pour le client ou l'utilisateur.

Pour tous les Sprints, un cadre temporel (Timebox) avec une date de début et de fin définie est établi, qui devrait en principe avoir la même durée pour tous les Sprints. Un nouveau Sprint suit directement l'achèvement du Sprint précédent. Même si des modifications du périmètre ou du personnel pouvant impacter l'objectif ne devraient normalement pas être effectuées pendant un Sprint, cela est parfois inévitable en raison de certains besoins métier.

Planification de Sprint

Le travail dans un Product Backlog peut s'étendre sur plusieurs semaines ou mois, ce qui dépasse largement ce qui peut être accompli lors d'un seul Sprint court. Lors du Sprint Planning, le Product Owner, l'équipe de développement et le Scrum Master déterminent quels sont les Product Backlog Items les plus importants pour le prochain Sprint. Au cours de cette planification, le Product Owner et l'équipe de développement s'accordent sur un Sprint Goal, c'est-à-dire une définition de ce qui doit être accompli durant le Sprint à venir.

Sur la base de ces directives, l'équipe de développement examine le Product Backlog et identifie les items les plus précieux qu'elle peut réellement accomplir lors du prochain Sprint. Le rythme de travail, également appelé Sustainable Pace, doit être choisi de manière à pouvoir être maintenu sans difficulté sur une longue période.

Pour avoir une idée de ce qui est réalisable, de nombreuses équipes décomposent chaque Product Backlog Item en différentes tâches. Celles-ci forment, avec les items correspondants, un second backlog : le Sprint Backlog.

Ensuite, les équipes de développement donnent une estimation de l'effort nécessaire pour chaque item (généralement en heures). Décomposer les Product Backlog Items en tâches est une forme de conception et de planification Just-in-Time pour la réalisation des fonctionnalités. Pour une durée de Sprint d'une à quatre semaines, le Sprint Planning doit être réalisé en deux à huit heures – il ne faut pas prévoir plus de temps. Il existe différentes approches, dont l'une des plus populaires suit un cycle simple : on sélectionne un Product Backlog Item (si possible, l'item suivant dans le classement du Product Owner), on le décompose en tâches et on décide s'il s'intègre bien dans le Sprint (en tenant compte des autres items prévus pour ce Sprint). S'il convient au Sprint et qu'il reste suffisamment de temps, on répète le processus jusqu'à ce que les capacités de l'équipe pour d'autres tâches soient épuisées.

Une autre approche consiste à ce que le Product Owner et l'équipe déterminent tous les Product Backlog Items souhaités en une seule fois. Seule l'équipe de développement effectue la décomposition en tâches individuelles, confirmant ainsi qu'elle peut terminer tous les items souhaités.

Exécution du Sprint

Dès que l'équipe Scrum a terminé le Sprint Planning et s'est mise d'accord sur le contenu du prochain Sprint, l'équipe de développement se met au travail (au niveau des tâches) nécessaire à la réalisation des fonctionnalités. Réalisation signifie ici que tous les travaux nécessaires à la production de fonctionnalités de haute qualité ont été accomplis.

Personne ne dicte à l'équipe de développement comment ni dans quel ordre elle doit effectuer le travail du Sprint Backlog au niveau des tâches. Les membres de l'équipe peuvent ainsi définir eux-mêmes leur travail au niveau des tâches et s'organiser de la manière qu'ils jugent optimale pour atteindre l'objectif du Sprint.

Daily Scrum / Daily Standup

Chaque jour pendant le Sprint, de préférence à la même heure et au même endroit, les membres de l'équipe tiennent une réunion appelée Daily Scrum. Cette réunion devrait durer 15 minutes maximum. Ce processus d'inspection et d'adaptation est parfois aussi appelé Daily Stand-Up, car en pratique, tous les participants restent souvent debout pour que la réunion reste courte.

Une approche courante du Daily Scrum consiste à ce que chaque membre de l'équipe réponde à trois questions, ce qui est extrêmement utile pour le reste de l'équipe.

• Qu'est-ce que j'ai accompli depuis le dernier Daily Scrum ?
• Sur quoi vais-je probablement travailler d'ici le prochain Daily Scrum ?
• Qu'est-ce qui m'empêche exactement de progresser ?

En répondant à ces questions, chacun obtient une vue d'ensemble de ce qui se passe, des progrès réalisés par rapport à l'objectif du Sprint, des changements de planification prévus pour le lendemain et des problèmes à traiter. Pour que l'équipe puisse garantir des flux de travail rapides et flexibles pendant un Sprint, le Daily Scrum est indispensable.

Les problèmes ne sont pas résolus pendant le Daily Scrum. À la place, les équipes peuvent se réunir après le Daily Scrum en petits groupes avec toutes les personnes intéressées pour discuter des problèmes. Le Daily Scrum n'est pas non plus une réunion de statut traditionnelle, comme celles convoquées par un chef de projet pour être informé de l'état d'avancement du projet. Un Daily Scrum est plutôt conçu pour communiquer le statut des éléments du Sprint Backlog au sein de l'équipe de développement. Principalement, un Daily Scrum est une activité où l'on effectue des inspections, des synchronisations et une planification adaptative, ce qui permet à une équipe auto-organisée de fournir un travail encore meilleur.

Définition de Terminé

Dans Scrum, les résultats des Sprints sont appelés incréments de produit potentiellement livrables. Cela signifie que tout ce que l'équipe Scrum voulait accomplir a effectivement été réalisé selon la Definition of Done convenue (définition de ce qui peut être considéré comme terminé). Cette définition spécifie le niveau de qualité du travail accompli et son caractère potentiellement livrable. Dans le développement logiciel, par exemple, la Definition of Done devrait au minimum exiger le développement complet d'une fonctionnalité produit, qui est conçue, développée, intégrée, testée et documentée.

Grâce à une Definition of Done ambitieuse, une entreprise peut décider à chaque Sprint si elle souhaite livrer ce qui a été développé à ses clients internes ou externes.

Pour bien comprendre : « potentiellement livrable » ne signifie pas que quelque chose doit obligatoirement être livré. Il s'agit d'une décision business, constamment influencée par des facteurs comme « Avons-nous suffisamment de fonctionnalités ou assez contribué à la satisfaction du client ? » ou « Nos clients peuvent-ils supporter un autre changement alors que nous leur avons déjà livré quelque chose il y a deux semaines ? ».

« Potentiellement livrable » devrait plutôt être vu comme le niveau de ce qui a réellement été accompli pendant le Sprint. Cela signifie qu'aucun travail important (comme des tests essentiels ou l'intégration, etc.) n'est en suspens et ne doit être terminé avant que le résultat du Sprint puisse être livré. La Definition of Done n'est pas gravée dans le marbre et devrait, comme tout le reste, faire l'objet d'une inspection et d'une adaptation régulières. En pratique, de nombreuses équipes font évoluer leur Definition of Done au fil du temps.

Revue de Sprint

À la fin de chaque Sprint, il y a deux autres activités d'Inspection et d'Adaptation. L'une d'entre elles est appelée Sprint Review.

L'objectif de cette activité est l'inspection et l'adaptation du produit souhaité. Un élément essentiel est la communication entre l'équipe Scrum, les parties prenantes, les sponsors, les clients et les membres intéressés d'autres équipes. L'accent est mis sur l'examen des fonctionnalités qui viennent d'être terminées par rapport à l'ensemble de l'effort de développement. Chaque personne présente obtient une vision claire de ce qui se passe actuellement et a la possibilité d'influencer le développement futur, permettant ainsi de trouver la meilleure solution pour l'entreprise.

Une Review réussie entraîne un flux d'informations dans les deux sens. Les personnes extérieures à l'équipe Scrum peuvent s'informer sur l'état du produit et influencer les prochaines étapes. En même temps, les membres de l'équipe Scrum ont la possibilité de développer une meilleure compréhension des aspects commerciaux et marketing en recevant constamment des retours pour savoir si le développement du produit est sur la bonne voie pour que les clients et utilisateurs soient enthousiasmés par le produit. Le Sprint Review représente donc une occasion planifiée d'inspecter et d'adapter un produit. Les personnes extérieures à l'équipe Scrum peuvent effectuer des revues de fonctionnalités pendant un Sprint et donner leur avis, ce qui aide l'équipe Scrum à atteindre son objectif de Sprint.

Rétrospective de Sprint

La deuxième activité Inspect-and-Adapt à la fin d'un Sprint est la Sprint Retrospective, qui se déroule régulièrement après le Sprint Review et avant le prochain Sprint Planning. Alors que le Sprint Review sert à inspecter et adapter le produit, la Sprint Retrospective est une occasion d'inspecter et d'adapter le processus. Lors d'une Sprint Retrospective, l'équipe de développement, le Scrum Master et le Product Owner se réunissent pour discuter de ce qui fonctionne et de ce qui ne fonctionne pas dans la pratique avec Scrum. L'accent est mis sur l'amélioration continue du processus, qui peut transformer une bonne équipe Scrum en une équipe Scrum exceptionnelle. À la fin d'une Sprint Retrospective, l'équipe Scrum devrait avoir identifié un nombre raisonnable d'actions d'amélioration qu'elle mettra en œuvre lors du prochain Sprint.

Une fois la Sprint Retrospective terminée, tout le cycle recommence – en commençant par un nouveau Sprint Planning, où l'on détermine les travaux les plus précieux sur lesquels l'équipe doit se concentrer.