Artefacts Scrum : Product Backlog, Sprint Backlog et Increment

Les artefacts Scrum sont les 3 éléments de travail que le cadre Scrum rend visibles à toute l’équipe : le Product Backlog, le Sprint Backlog et l’Increment. Depuis la version 2020 du Scrum Guide, chacun est relié à un engagement : l’Objectif de Produit, l’Objectif de Sprint et la Definition of Done. Cet article les détaille un par un, d’après le texte officiel, avec des exemples et les erreurs à éviter.

Pour une vue d’ensemble du cadre (rôles, événements, valeurs, mise en place), lisez d’abord notre guide de la méthode Scrum. Ici, on se concentre sur les artefacts.

Source de référence : le Scrum Guide de Ken Schwaber et Jeff Sutherland, dans sa version de novembre 2020, que scrumguides.org présente toujours comme « Official Current Version » (version officielle actuelle, vérifié le 08/10/2026). Les citations en français viennent de sa traduction française officielle.

Qu’est-ce qu’un artefact Scrum ?

Le Scrum Guide donne une définition courte : « Les artefacts de Scrum représentent un travail ou une valeur. Ils sont conçus pour maximiser la transparence des informations clés. Ainsi, tous ceux qui les inspectent ont la même base d’adaptation. »

Concrètement, un artefact Scrum est un support partagé (une liste, un plan, un résultat utilisable) qui permet à l’équipe et à ses parties prenantes de voir où en est le travail, puis de décider quoi ajuster.

Pourquoi les artefacts sont au cœur de la transparence

Scrum repose sur trois piliers empiriques : transparence, inspection et adaptation. Le guide relie directement le premier aux artefacts : « Avec Scrum, les décisions importantes sont fondées sur l’état perçu de ses trois artefacts formels. Des artefacts peu transparents peuvent mener à des décisions qui diminuent la valeur et augmentent le risque. »

Il ajoute que « les artefacts Scrum et les progrès vers les objectifs convenus doivent être inspectés fréquemment et avec diligence ». Autrement dit, un backlog à jour mais que personne ne regarde, ou un tableau que seule une partie de l’équipe comprend, ne remplit pas son rôle.

Artefact, artéfact ou artifact : d’où vient le mot ?

Le mot vient de l’anglais artefact, lui-même formé sur le latin artis facta, « effets de l’art », selon le dictionnaire Larousse. Par extension, le Trésor de la langue française (CNRTL) le définit comme un « produit de l’art, de l’industrie », un objet artificiel, par opposition à un objet naturel.

Côté orthographe, le Larousse indique que ce mot « ne prend pas d’accent sur le e » (artefact), tandis que le CNRTL l’enregistre sous la forme « artéfact ». Les deux graphies se rencontrent. En anglais, on écrit artifact (Scrum artifacts, agile artifacts) : c’est le terme utilisé dans la version originale du Scrum Guide.

Les 3 artefacts Scrum et leurs 3 engagements

Le Scrum Guide 2020 énumère les engagements ainsi : « Pour le Product Backlog, il s’agit de l’Objectif de Produit. Pour le Sprint Backlog, c’est l’Objectif de Sprint. Pour l’Increment, c’est la Definition of Done (définition de Fini). » Chaque engagement « apporte l’information nécessaire à la transparence et au focus rendant possible la mesure de la progression ».

Ces engagements sont une nouveauté de 2020. La section du guide consacrée aux changements entre les versions 2017 et 2020 explique que les versions précédentes décrivaient l’Objectif de Sprint et la Definition of Done « sans vraiment leur attribuer d’identité » et qu’ils « n’étaient pas tout à fait attachés à des artefacts ». L’Objectif de Produit, lui, est introduit en 2020. Si vous lisez un article ou un support de formation qui ne parle que de trois artefacts sans engagement, il s’appuie probablement sur le guide 2017.

Le Product Backlog et l’Objectif de Produit

Définition et contenu

Selon le guide, « le Product Backlog est une liste ordonnée et émergente de ce qui est nécessaire pour améliorer le produit. C’est l’unique source du travail entrepris par la Scrum Team. » Trois mots comptent :

• ordonnée : les éléments sont classés, du plus important au moins important à traiter ;
• émergente : la liste n’est jamais figée, elle évolue avec ce que l’équipe et les parties prenantes apprennent ;
• unique source : il n’y a pas de second backlog parallèle, ni de demandes qui contournent la liste.

Le guide ne fixe pas le format des éléments : « Les attributs varient souvent en fonction du domaine d’activité. » Il cite seulement des détails « tels qu’une description, un ordre et une taille ». Les user stories, très répandues, sont une pratique complémentaire et non une obligation du cadre (voir plus bas).

Qui gère le Product Backlog ? Le rôle du Product Owner

Le Product Owner « est également redevable de la gestion efficace du Product Backlog », ce qui inclut, d’après le guide :

• formuler et communiquer explicitement l’Objectif de Produit ;
• créer et communiquer clairement les éléments du Product Backlog ;
• ordonner les éléments dans le Product Backlog ;
• s’assurer que le Product Backlog est transparent, visible et compris.

Il peut déléguer ce travail, mais il « en demeure redevable ». Le Product Owner est « une personne et non un comité », et ceux qui veulent modifier le backlog doivent le faire « en essayant de convaincre le Product Owner ». En revanche, ce n’est pas lui qui estime l’effort : « Les Developers qui effectueront le travail sont responsables du dimensionnement. » Pour approfondir ce rôle, voir notre article sur ce qu’il faut pour être un bon Product Owner.

Ordonner le backlog : la méthode MoSCoW en complément

Le guide parle d’ordonner, sans imposer de technique. Une technique possible est la méthode MoSCoW, utilisée notamment dans les projets DSDM et documentée par l’Agile Business Consortium : chaque besoin est classé en Must Have, Should Have, Could Have ou Won’t Have this time. Le consortium précise que classer un besoin en Should Have ou Could Have « ne signifie pas qu’il ne sera pas livré ; simplement que la livraison n’est pas garantie ».

Exemple (hypothétique) : pour un site e-commerce, le Product Owner pourrait placer en Must Have le tunnel d’achat, le paiement en ligne et le catalogue ; en Should Have le compte client et le filtre par catégorie ; en Could Have la liste d’envies ; en Won’t Have this time le forum et l’application mobile. Le Product Backlog reste ensuite une liste ordonnée unique : MoSCoW aide à décider de l’ordre, il ne remplace pas la liste.

L’affinement du backlog et la notion d’élément « prêt »

Le guide décrit l’affinement (refinement) comme une activité continue qui consiste « à décomposer et à définir davantage les éléments du Backlog en éléments plus fins et plus précis ». Les éléments « susceptibles d’être réalisés dans un seul Sprint » sont « considérés comme prêts à être traités en Sprint Planning ». Le guide ne prévoit pas d’événement dédié à l’affinement : il se fait au fil du Sprint, « si nécessaire ». Nous détaillons cette pratique dans notre article sur le backlog refinement.

L’engagement du Product Backlog : l’Objectif de Produit

« L’Objectif de Produit décrit un état futur du produit qui peut servir de cible à la Scrum Team pour planifier. » Il se trouve dans le Product Backlog, et « le reste du Product Backlog émerge pour définir “ce qui” permettra d’atteindre l’Objectif de Produit ». C’est « l’objectif à long terme de la Scrum Team » : l’équipe doit l’atteindre ou l’abandonner « avant de s’attaquer au suivant ».

Le guide précise aussi ce qu’il entend par produit : « un vecteur de valeur » avec « une limite 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.

Exemple (hypothétique) : pour une boutique en ligne, un Objectif de Produit pourrait être « permettre à un client de commander et payer sur mobile sans créer de compte ». Les éléments du backlog (paiement express, commande en invité, suivi de livraison par e-mail…) sont alors ordonnés selon leur contribution à cet objectif.

Le Sprint Backlog et l’Objectif de Sprint

Le pourquoi, le quoi et le comment du Sprint

Le Sprint Backlog « est composé de l’Objectif de Sprint (le “pourquoi”), de l’ensemble des éléments du Product Backlog choisis pour le Sprint (le “quoi”), ainsi que d’un plan d’action pour la réalisation de l’Increment (le “comment”) ».

Il naît pendant le Sprint Planning, qui aborde ces trois thèmes : pourquoi ce Sprint est important, ce qui peut être fait, et comment le travail choisi sera réalisé. Pour le « comment », le guide indique que cela se fait « souvent en décomposant les éléments du Product Backlog en éléments de travail d’une journée ou moins », et que « la façon de procéder est laissée à la seule discrétion des Developers ». Le déroulé de cette réunion est détaillé dans notre article sur le Sprint Planning.

Exemple (hypothétique) : pour l’élément « En tant que visiteur, je veux m’inscrire à la newsletter pour être informé des nouveautés », les Developers pourraient prévoir les tâches suivantes dans le Sprint Backlog :

1. créer le champ d’inscription dans le pied de page ;
2. développer le formulaire avec validation de l’adresse e-mail ;
3. brancher l’envoi des données vers l’outil d’e-mailing ;
4. créer les e-mails de confirmation et de bienvenue ;
5. tester le parcours d’inscription de bout en bout.

Un plan élaboré par et pour les Developers

Le guide est clair sur la propriété de cet artefact : « Le Sprint Backlog est un plan élaboré par et pour les Developers. » C’est « une image très visible et en temps réel du travail » prévu pour atteindre l’Objectif de Sprint. Il est donc « mis à jour tout au long du Sprint selon ce qu’on en apprend » et doit être « suffisamment détaillé pour que les Developers puissent inspecter leur progression durant le Daily Scrum ».

Un manager ou un Product Owner qui remplirait lui-même le Sprint Backlog et répartirait les tâches irait à l’encontre de ce principe : les Developers sont redevables de « créer un plan de Sprint, un Sprint Backlog » et d’« adapter leur plan chaque jour par rapport à l’Objectif de Sprint ».

L’engagement du Sprint Backlog : l’Objectif de Sprint

« L’Objectif de Sprint est l’unique but du Sprint. » Il est créé pendant le Sprint Planning, puis ajouté au Sprint Backlog. Le guide précise qu’il « offre une certaine flexibilité en termes de travail nécessaire pour atteindre cet objectif » : si le travail s’avère différent de ce qui était prévu, les Developers « collaborent avec le Product Owner pour négocier le périmètre du Sprint Backlog dans le cadre de ce Sprint, sans que cela n’affecte l’Objectif de Sprint ».

Pendant le Sprint, « aucun changement n’est permis, qui pourrait remettre en cause l’Objectif de Sprint ». Si l’objectif devient obsolète, le Sprint peut être annulé, et « seul le Product Owner a le pouvoir d’annuler le Sprint ».

Exemple (hypothétique) : « Permettre aux visiteurs de s’inscrire à la newsletter et de recevoir un e-mail de bienvenue. » Si l’e-mail de bienvenue personnalisé prend plus de temps que prévu, l’équipe peut renégocier avec le Product Owner une version simple de cet e-mail : le périmètre change, l’objectif reste.

L’Increment et la Definition of Done

Qu’est-ce qu’un Increment ?

« Un Increment est une première étape concrète vers l’Objectif de Produit. Chaque Increment s’ajoute à tous les Increments précédents et fait l’objet d’une vérification approfondie, ce qui garantit que tous les Increments fonctionnent ensemble. Afin de fournir une valeur, l’Increment doit être utilisable. »

Deux précisions du guide sont souvent ignorées :

• « Plusieurs Increments peuvent être créés durant un Sprint » ;
• « un Increment peut être livré aux parties prenantes avant la fin du Sprint. La Sprint Review ne doit jamais être considérée comme le seul moment pour délivrer de la valeur. »

La somme des Increments est présentée lors de la Sprint Review. Et la règle de base est stricte : « Un travail qui ne remplirait pas les conditions de la Definition of Done ne peut pas être considéré comme un Increment. »

L’engagement de l’Increment : la Definition of Done

« La Definition of Done (Définition de Fini) est une description formelle de l’état de l’Increment lorsqu’il satisfait les mesures de qualité requises pour le produit. » Dès qu’un élément du Product Backlog la satisfait, « il se transforme en Increment ». Dans le cas contraire, il « ne peut pas être publié ni même présenté lors de la Sprint Review » et il est « renvoyé au Product Backlog pour être pris en compte ultérieurement ».

Qui la définit ? 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 » ;
• sinon, « la Scrum Team doit créer sa propre Definition of Done qui soit appropriée pour le produit ».

Les Developers « sont tenus de se conformer à la Definition of Done ». Si plusieurs Scrum Teams travaillent sur le même produit, « elles doivent la définir ensemble et s’y conformer ».

Exemple de Definition of Done

Exemple (hypothétique) pour une petite équipe qui développe un site web :

• code relu et validé par un pair ;
• tests unitaires et d’intégration passants ;
• documentation utilisateur et technique à jour ;
• déployé et testé sur l’environnement de recette ;
• aucune régression connue sur les parcours existants.

L’Agile Alliance recommande, dans son glossaire, que la liste définisse « le travail minimum » nécessaire et qu’elle soit écrite et affichée plutôt que simplement implicite : une bonne partie de sa valeur tient au fait d’être « un contrat explicite connu de tous les membres de l’équipe ». La Sprint Retrospective est l’occasion de la réexaminer : l’équipe y inspecte notamment « les outils et leur Definition of Done ».

Definition of Done et critères d’acceptation : quelle différence ?

La Definition of Done s’applique à tout le travail livré. Les critères d’acceptation, eux, sont propres à un élément du backlog (par exemple : « le client peut choisir son mode de livraison » pour un tunnel d’achat). Le glossaire de l’Agile Alliance le formule ainsi : des fonctionnalités ou user stories peuvent avoir des critères de « fini » spécifiques « en plus de ceux qui s’appliquent au travail en général ». Un élément est donc terminé quand il respecte à la fois ses critères d’acceptation et la Definition of Done commune.

Artefacts et événements Scrum : quand les inspecter ?

Le guide relie explicitement les deux : « Chaque événement dans Scrum est une occasion formelle pour inspecter et adapter les artefacts Scrum. » Le tableau ci-dessous résume quel artefact est travaillé à chaque événement, d’après les sections du guide consacrées aux événements.

Le détail de chaque réunion se trouve dans notre article sur les cérémonies Scrum et dans celui consacré à la rétrospective de sprint.

Les autres artefacts agiles (user stories, burndown chart, Definition of Ready) : ce que le Scrum Guide ne définit pas

Le guide parle de « trois artefacts formels ». Les listes de « 7 artefacts Scrum » que l’on trouve en ligne y ajoutent des pratiques courantes, utiles, mais qui ne font pas partie du cadre officiel. Le guide le dit lui-même : « Divers processus, techniques et méthodes peuvent être employés dans ce cadre de travail. » Le Manifeste agile, de son côté, ne parle d’artefacts nulle part : ce sont les cadres comme Scrum qui en définissent.

Ces outils peuvent tout à fait coexister avec Scrum, qui « peut fonctionner comme un conteneur pour d’autres techniques, méthodologies et pratiques ». Le point de vigilance : ne pas les présenter comme des obligations du cadre, ni les laisser remplacer les trois artefacts officiels.

Gérer les artefacts Scrum dans un outil

Le Scrum Guide ne prescrit aucun outil. Des fiches ou des post-it, comme ceux que l’Agile Alliance décrit pour les user stories, peuvent suffire. Les besoins à couvrir découlent des règles vues plus haut :

• un Product Backlog unique, ordonné, visible et compris par toute l’équipe et les parties prenantes ;
• un Sprint Backlog que les Developers mettent à jour eux-mêmes, au moins chaque jour, avec l’Objectif de Sprint bien visible ;
• une Definition of Done écrite et accessible à tous ;
• la possibilité de voir ce qui a été livré à chaque Sprint pour préparer la Sprint Review.

Si votre équipe travaille à distance ou sur plusieurs projets en parallèle, un logiciel devient vite utile. Comparez les solutions dans notre sélection de logiciels de gestion de projet agile, ou dans celle des outils Kanban si vous cherchez surtout un tableau visuel. Pour un petit budget, voyez aussi les logiciels de gestion de projet gratuits.

Les erreurs fréquentes avec les artefacts Scrum

• Plusieurs backlogs pour un même produit. Le guide en fait « l’unique source du travail » ; si plusieurs Scrum Teams travaillent sur un produit, elles partagent « le même Objectif de Produit, le même Product Backlog et le même Product Owner ».
• Un backlog géré par un comité. Le Product Owner est une personne ; les autres passent par lui pour faire évoluer la liste.
• Un Sprint Backlog rempli par le manager. C’est un plan élaboré par et pour les Developers.
• Changer l’Objectif de Sprint en cours de route. On peut renégocier le périmètre avec le Product Owner, pas l’objectif ; s’il devient obsolète, seul le Product Owner peut annuler le Sprint.
• Présenter en Sprint Review un travail qui ne respecte pas la Definition of Done. Il n’est pas un Increment et retourne dans le Product Backlog.
• Baisser l’exigence de qualité pour tenir le Sprint. Le guide l’exclut : « Les objectifs de qualité ne sont jamais revus à la baisse. »
• Attendre la fin du Sprint pour livrer. Un Increment peut être livré avant la Sprint Review.
• Piloter uniquement au burndown. Ces courbes indiquent une tendance ; l’Agile Alliance rappelle qu’elles ne disent pas si l’équipe travaille sur les bons éléments.

Pour replacer ces artefacts dans l’ensemble du cadre et des autres méthodes, voir aussi l’essentiel de la gestion de projet agile, la méthode Kanban et, pour comparer avec une approche séquentielle, la méthode Waterfall.

FAQ sur les artefacts Scrum

Quels sont les 3 artefacts Scrum ?

Le Product Backlog (liste ordonnée de ce qui est nécessaire pour améliorer le produit), le Sprint Backlog (Objectif de Sprint, éléments choisis et plan des Developers) et l’Increment (résultat concret et utilisable qui respecte la Definition of Done). Ce sont les trois artefacts formels du Scrum Guide 2020.

Quels sont les engagements associés aux artefacts Scrum ?

L’Objectif de Produit pour le Product Backlog, l’Objectif de Sprint pour le Sprint Backlog et la Definition of Done pour l’Increment. Ils ont été rattachés aux artefacts dans la version 2020 du guide pour rendre visible la progression de chacun.

Existe-t-il 7 artefacts Scrum ?

Non, pas dans le cadre officiel. Le Scrum Guide définit 3 artefacts et 3 engagements. Les listes plus longues ajoutent des pratiques comme les user stories, le burndown chart ou la Definition of Ready, utiles mais absentes du guide.

La Definition of Done est-elle un artefact ?

Non. Depuis 2020, c’est l’engagement de l’Increment : la description formelle de l’état qu’un travail doit atteindre pour devenir un Increment. Avant 2020, le guide la décrivait sans lui donner ce statut.

Qui est responsable du Product Backlog et du Sprint Backlog ?

Le Product Owner est redevable de la gestion efficace du Product Backlog (Objectif de Produit, contenu, ordre, transparence), même s’il délègue une partie du travail. Le Sprint Backlog est élaboré par et pour les Developers, qui en assurent la mise à jour.

Que signifie le mot « artefact » en français ?

Le Larousse le fait venir de l’anglais, formé sur le latin artis facta, « effets de l’art ». Par extension, le CNRTL le définit comme un « produit de l’art, de l’industrie », un objet artificiel. Dans Scrum, un artefact est un élément qui représente un travail ou une valeur et rend l’information visible à tous.

Agile artifacts, artefacts agiles : est-ce la même chose que les artefacts Scrum ?

Pas tout à fait. Le Manifeste agile ne définit aucun artefact. L’expression « agile artifacts » est souvent employée plus largement, pour d’autres supports d’équipes agiles (user stories, tableaux, graphiques d’avancement…). Au sens strict, les artefacts Scrum sont uniquement les 3 artefacts définis par le Scrum Guide.

Quels sont les 3 piliers de Scrum ?

La transparence, l’inspection et l’adaptation. Les artefacts servent directement le premier pilier : selon le guide, les décisions importantes sont fondées sur leur état perçu. Ces piliers sont détaillés dans notre guide de la méthode Scrum.

Le Sprint Backlog peut-il changer pendant le Sprint ?

Oui. Le guide prévoit qu’il est « mis à jour tout au long du Sprint selon ce qu’on en apprend », et le Daily Scrum sert notamment à l’adapter. Ce qui ne doit pas être remis en cause, c’est l’Objectif de Sprint.