Les artefacts et leurs engagements — The Scrum Guide

Si les événements sont le rythme de Scrum, les artefacts en sont la matière. Le guide les définit d'une phrase d'une densité remarquable : les artefacts de Scrum représentent du travail ou de la valeur. Ils ne sont ni des livrables bureaucratiques, ni des rapports d'avancement destinés à la hiérarchie : ils sont conçus pour maximiser la transparence de l'information clé. La conséquence est immédiate, et c'est elle qui fait tout l'intérêt du dispositif : tous ceux qui inspectent un artefact disposent de la même base pour s'adapter. Équipe et parties prenantes regardent la même liste, le même plan, le même produit — pas des versions divergentes de la réalité entretenues dans des outils séparés. On retrouve ici, incarnée dans des objets concrets, la théorie empirique du framework : sans transparence, l'inspection est trompeuse et l'adaptation détruit de la valeur au lieu d'en créer.

Trois artefacts, trois engagements

La version 2020 du guide apporte une clarification structurante : chaque artefact contient un engagement (commitment). Cet engagement garantit que l'artefact fournit une information qui renforce la transparence et le focus, et à l'aune de laquelle le progrès peut être mesuré. Un artefact sans engagement ne serait qu'un inventaire ; l'engagement lui donne une direction et un critère de réussite.

Artefact	Engagement	Question à laquelle il répond
Product Backlog	Product Goal	Vers quel état futur du produit allons-nous ?
Sprint Backlog	Sprint Goal	Pourquoi ce Sprint vaut-il la peine d'être mené ?
Increment	Definition of Done	Qu'est-ce que « terminé » veut dire, concrètement ?

Le guide précise la raison d'être de ces trois engagements : ils existent pour renforcer l'empirisme et les valeurs Scrum, pour la Scrum Team comme pour ses parties prenantes. Chaque paire artefact-engagement relie ainsi un horizon temporel à une promesse : le long terme du produit (Product Goal), le court terme du Sprint (Sprint Goal), et l'instant présent de la qualité (Definition of Done).

Le Product Backlog : la source unique du travail

Le Product Backlog est une liste émergente et ordonnée de ce qui est nécessaire pour améliorer le produit. Chaque adjectif compte. Émergente : la liste n'est jamais figée ni complète, elle évolue à mesure que l'équipe apprend. Ordonnée : les items ne forment pas un sac en vrac mais une séquence, qui exprime des décisions visibles de tous. Et surtout, c'est la source unique du travail entrepris par la Scrum Team. Il n'existe pas de circuit parallèle : pas de demandes glissées de la main à la main, pas de « petit service » qui contournerait la liste. Tout ce que fait l'équipe en provient.

Tous les items ne se valent pas en maturité. Le guide pose un critère précis : les items que la Scrum Team peut terminer en un Sprint sont réputés prêts pour la sélection lors d'un Sprint Planning. Et ils acquièrent généralement ce degré de transparence après des activités d'affinage (refinement).

Le Product Backlog refinement est l'acte de décomposer et de préciser les items du Product Backlog en items plus petits et plus précis. C'est une activité continue — pas un événement formel avec un timebox, contrairement aux cinq événements du framework — qui consiste à ajouter des détails : une description, un ordre, une taille. Le guide reste volontairement sobre sur la forme : les attributs varient souvent selon le domaine de travail. Une équipe de développement logiciel, une équipe marketing et une équipe de recherche ne décriront pas leurs items de la même manière, et c'est très bien ainsi.

Note

Le Scrum Guide 2020 ne mentionne ni user stories, ni story points, ni vélocité. Ces techniques populaires sont des pratiques complémentaires que beaucoup d'équipes trouvent utiles, mais elles ne font pas partie de Scrum : le guide dit seulement que les items ont des attributs comme une description, un ordre et une taille, et laisse chaque équipe choisir ses tactiques. Confondre Scrum avec ces pratiques est une source classique de malentendus.

Sur un point, en revanche, le guide est catégorique : les Developers qui feront le travail sont responsables du dimensionnement (sizing). Personne ne peut leur imposer une estimation — ni un manager, ni le Product Owner. Ce dernier a toutefois un rôle à jouer : il peut influencer les Developers en les aidant à comprendre et à choisir des compromis (trade-offs). Le dialogue est asymétrique mais réel : le Product Owner éclaire la valeur et les arbitrages possibles, les Developers restent maîtres du chiffrage de l'effort.

L'engagement du Product Backlog : le Product Goal

Le Product Goal décrit un état futur du produit, qui sert de cible de planification pour la Scrum Team. Point remarquable de la mécanique : le Product Goal n'est pas un document à part, il est dans le Product Backlog. Le reste du backlog émerge pour définir « quoi » réalisera ce Product Goal — l'objectif tire la liste, la liste concrétise l'objectif.

C'est aussi à cet endroit précis que le guide glisse sa seule définition d'un produit :

Un produit est un véhicule pour livrer de la valeur. Il a une frontière claire, des parties prenantes connues, des utilisateurs ou des clients bien définis. Un produit peut être un service, un produit physique, ou quelque chose de plus abstrait.

Cette définition élargit délibérément le champ d'application de Scrum bien au-delà du logiciel : un service d'assistance, une gamme de matériel, un programme de formation peuvent être « le produit » pourvu qu'ils aient une frontière, des parties prenantes et des utilisateurs identifiables.

Le Product Goal est l'objectif à long terme de la Scrum Team. Et le guide impose une discipline de focus qui tranche avec la dispersion habituelle des roadmaps : l'équipe doit atteindre — ou abandonner — un objectif avant de s'attaquer au suivant. Pas question de mener trois Product Goals de front : un seul horizon à la fois, quitte à reconnaître lucidement qu'un objectif ne vaut plus la peine et à le remplacer. On retrouve la valeur de focus élevée au rang de règle structurelle.

Le Sprint Backlog : le plan par et pour les Developers

Le Sprint Backlog est un artefact composite, et le guide en donne la formule exacte : il est composé du Sprint Goal (le pourquoi), de l'ensemble des items du Product Backlog sélectionnés pour le Sprint (le quoi), ainsi que d'un plan actionnable pour livrer l'Increment (le comment).

Composante	Question	Origine
Sprint Goal	Pourquoi ce Sprint vaut-il la peine ?	Défini par toute la Scrum Team en Sprint Planning
Items sélectionnés	Quoi peut être terminé ce Sprint ?	Choisis par les Developers, en discussion avec le Product Owner
Plan actionnable	Comment le travail choisi sera-t-il accompli ?	À la seule discrétion des Developers

Sa nature est sans ambiguïté : c'est un plan élaboré par et pour les Developers. Ni le Product Owner ni le management n'en dictent le contenu détaillé. C'est une image en temps réel, hautement visible, du travail que les Developers prévoient d'accomplir pendant le Sprint pour atteindre le Sprint Goal. Deux propriétés en découlent. D'abord, le Sprint Backlog est mis à jour tout au long du Sprint, à mesure que l'équipe apprend : un plan figé le lundi matin qui ne bougerait plus serait un aveu que personne n'apprend rien. Ensuite, il doit être suffisamment détaillé pour que les Developers puissent inspecter leur progression lors du Daily Scrum — assez fin pour révéler les écarts jour après jour, sans tomber dans le micro-planning qui prétendrait tout prévoir.

L'engagement du Sprint Backlog : le Sprint Goal

Le Sprint Goal est l'objectif unique du Sprint. Unique, pas « principal parmi d'autres » : un seul énoncé qui dit pourquoi ce Sprint vaut la peine. Le guide en fait un équilibre subtil : c'est un engagement des Developers, mais il offre de la flexibilité quant au travail exact nécessaire pour l'atteindre. On s'engage sur la destination, pas sur chaque pas du chemin. Le Sprint Goal crée de la cohérence et du focus, encourageant la Scrum Team à travailler ensemble plutôt que sur des initiatives séparées — sans lui, un Sprint dégénère facilement en dix chantiers individuels juxtaposés qui ne racontent aucune histoire commune.

Il est créé pendant le Sprint Planning, puis ajouté au Sprint Backlog. Et le guide prévoit explicitement le cas — inévitable en environnement complexe — où la réalité déjoue le plan : si le travail s'avère différent de ce que les Developers attendaient, ils collaborent avec le Product Owner pour négocier le périmètre du Sprint Backlog, au sein du Sprint, sans affecter le Sprint Goal.

Astuce

C'est la variable d'ajustement du Sprint : le périmètre se négocie, le Sprint Goal ne bouge pas. Une équipe qui découvre en cours de route qu'un item est plus lourd que prévu renégocie le contenu avec le Product Owner en préservant l'objectif ; rogner silencieusement la qualité n'est jamais une option.

L'Increment : la valeur rendue tangible

L'Increment (incrément) est une marche concrète vers le Product Goal (a concrete stepping stone). Trois exigences le définissent. Chaque Increment est additif à tous les Increments précédents : on n'écrase pas ce qui existe, on construit dessus. Il est vérifié en profondeur, ce qui garantit que tous les Increments fonctionnent ensemble : le nouveau travail ne casse pas l'ancien. Enfin, pour apporter de la valeur, l'Increment doit être utilisable : un travail « presque fini », non intégré ou non testé, n'est pas un Increment — c'est un stock de risque.

Le guide balaie au passage une idée reçue tenace : plusieurs Increments peuvent être créés au cours d'un même Sprint. Le Sprint n'est pas un tunnel dont on ne sort qu'une fois : chaque fois qu'un item atteint l'état « Done », une nouvelle marche est posée. La somme des Increments est présentée à la Sprint Review, ce qui soutient l'empirisme : les parties prenantes inspectent du réel, pas des promesses.

À retenir

Un Increment peut être livré aux parties prenantes avant la fin du Sprint. Le guide est formel : la Sprint Review ne doit jamais être considérée comme une barrière à la livraison de valeur. Attendre la fin du Sprint pour mettre en production ce qui est prêt depuis dix jours n'est pas une règle de Scrum — c'est une habitude, souvent coûteuse. La Review est un moment d'inspection, pas un guichet de douane.

La frontière de l'Increment est tracée d'un trait net : un travail ne peut être considéré comme faisant partie d'un Increment que s'il respecte la Definition of Done. Ce qui nous amène au troisième engagement.

La Definition of Done : là où naît l'Increment

La Definition of Done (définition de « terminé ») est une description formelle de l'état de l'Increment lorsqu'il respecte les mesures de qualité requises pour le produit. Formelle : écrite, explicite, connue de tous — pas un sentiment diffus de « ça devrait aller ». Et le guide lui donne une formulation presque poétique : dès l'instant où un item du Product Backlog respecte la Definition of Done, un Increment naît.

Sa fonction première est, encore une fois, la transparence : la Definition of Done donne à chacun une compréhension partagée du travail qui a été accompli dans le cadre de l'Increment. Quand un Developer annonce « c'est terminé », chacun sait exactement ce que cela recouvre. Sans elle, « fini » veut dire dix choses différentes pour dix personnes, et la Sprint Review inspecte du brouillard.

Attention

Le guide ne laisse aucune échappatoire : si un item ne respecte pas la Definition of Done, il ne peut être ni livré, ni même présenté à la Sprint Review. Il retourne au Product Backlog pour être reconsidéré plus tard. Pas de démonstration d'un travail « à 90 % », pas d'astérisque « reste juste les tests » : montrer de l'inachevé comme s'il était fini détruirait précisément la transparence que l'artefact existe pour créer.

D'où vient cette définition ? Le guide prévoit deux cas. Si la Definition of Done fait partie des standards de l'organisation, toutes les Scrum Teams doivent la suivre — au minimum : une équipe peut être plus exigeante que le standard, jamais moins. Si ce n'est pas un standard organisationnel, la Scrum Team doit créer une Definition of Done appropriée au produit. Dans tous les cas, les Developers sont tenus de s'y conformer — c'est d'ailleurs, on l'a vu au chapitre sur l'équipe, l'une de leurs responsabilités permanentes : instiller la qualité en adhérant à une Definition of Done. Et lorsque plusieurs Scrum Teams travaillent ensemble sur un même produit, elles doivent mutuellement définir et respecter la même Definition of Done : un produit, une définition de la qualité — sinon les Increments des unes et des autres ne pourraient jamais « fonctionner ensemble ».

À retenir

Les artefacts de Scrum représentent du travail ou de la valeur et sont conçus pour maximiser la transparence : tous ceux qui les inspectent disposent de la même base d'adaptation.
Chaque artefact contient un engagement qui permet de mesurer le progrès et renforce l'empirisme et les valeurs Scrum : Product Backlog → Product Goal, Sprint Backlog → Sprint Goal, Increment → Definition of Done.
Le Product Backlog est une liste émergente et ordonnée, source unique du travail de la Scrum Team ; le refinement est une activité continue de décomposition et de précision des items, et les Developers qui feront le travail sont responsables du dimensionnement — le Product Owner peut les aider à comprendre et à choisir des compromis.
Le Product Goal est l'objectif à long terme de l'équipe, contenu dans le Product Backlog dont le reste émerge pour définir le « quoi » ; il faut atteindre ou abandonner un objectif avant d'en prendre un autre.
Le Sprint Backlog réunit le pourquoi (Sprint Goal), le quoi (items sélectionnés) et le comment (plan actionnable) ; c'est un plan par et pour les Developers, image en temps réel du travail, mis à jour tout au long du Sprint et assez détaillé pour être inspecté au Daily Scrum.
Le Sprint Goal est l'objectif unique du Sprint : un engagement des Developers, flexible sur le travail exact, qui crée cohérence et focus ; si le travail diffère des attentes, on négocie le périmètre avec le Product Owner sans affecter le Sprint Goal.
L'Increment est une marche concrète vers le Product Goal : additif, vérifié en profondeur et utilisable ; plusieurs Increments peuvent naître par Sprint, et l'un d'eux peut être livré avant la fin du Sprint — la Sprint Review n'est jamais une barrière à la livraison de valeur.
La Definition of Done est la description formelle de la qualité requise : dès qu'un item la respecte, un Increment naît ; un item non conforme ne peut être ni livré ni présenté en Review et retourne au Product Backlog ; plusieurs équipes sur un même produit partagent la même Definition of Done.