Le Scrum Guide 2020 définit trois artefacts Scrum, chacun associé à un engagement : le Product Backlog s'engage envers le Product Goal, le Sprint Backlog envers le Sprint Goal, et l'Increment envers la Definition of Done. Les artefacts rendent le travail et la valeur transparents, et les engagements donnent à chaque artefact un objectif clair par rapport auquel mesurer les progrès. Si vous maîtrisez ces trois paires, vous pouvez répondre à une grande partie des questions sur les artefacts aux examens PSM I, PSPO I et CSM.
Quels sont les trois artefacts Scrum ?
Les artefacts Scrum représentent du travail ou de la valeur. Ils existent pour maximiser la transparence des informations clés, afin que tous ceux qui les inspectent disposent de la même base pour s'adapter. Cela se rattache directement aux trois piliers de Scrum : transparence, inspection et adaptation. Un artefact qui n'est pas transparent mène à de mauvaises décisions, car on ne peut pas inspecter ce que l'on ne voit pas.
L'édition 2020 du Scrum Guide a ajouté un engagement à chaque artefact. Le guide explique que ces engagements existent pour renforcer l'empirisme et les valeurs de Scrum pour la Scrum Team et ses stakeholders.
Les artefacts et engagements Scrum en un coup d'œil
| Artefact | Engagement | Qui est responsable |
|---|---|---|
| Product Backlog | Product Goal | Product Owner (gestion du Product Backlog, y compris l'élaboration et la communication du Product Goal) |
| Sprint Backlog | Sprint Goal | Developers (le Sprint Backlog est leur plan, fait par et pour eux) |
| Increment | Definition of Done | Les Developers s'y conforment ; la Scrum Team la crée si l'organisation n'en fournit pas |
Gardez ce tableau en tête pour l'examen. De nombreuses questions pièges se contentent d'échanger le responsable d'un artefact ou d'associer un artefact au mauvais engagement.
Le Product Backlog et le Product Goal
Le Product Backlog est une liste ordonnée et évolutive de ce qui est nécessaire pour améliorer le produit. C'est l'unique source du travail entrepris par la Scrum Team. Les éléments situés en haut sont généralement plus clairs et plus raffinés, car ils ont de bonnes chances d'être choisis lors du prochain Sprint Planning.
Le raffinement du Product Backlog consiste à décomposer les éléments et à ajouter des détails comme la description, l'ordre et la taille. C'est une activité continue, pas un événement Scrum. Le guide 2020 ne donne aucun pourcentage fixe ; l'ancienne règle « pas plus de 10 % de la capacité des Developers » a été supprimée.
Le Product Owner est responsable de la gestion du Product Backlog. Le Product Owner est une seule personne, pas un comité. Il peut déléguer à d'autres la rédaction ou l'ordonnancement des éléments, mais il reste responsable.
Qu'est-ce que le Product Goal et pourquoi a-t-il été ajouté en 2020 ?
Le Product Goal décrit un état futur du produit et sert de cible à partir de laquelle la Scrum Team planifie. C'est l'objectif à long terme de la Scrum Team, et le Product Backlog évolue pour définir « ce qui » permettra de l'atteindre.
Avant 2020, Scrum n'avait aucun objectif explicite au niveau des artefacts au-dessus du Sprint Goal. Les équipes pouvaient travailler Sprint après Sprint sans vision commune de la direction que prenait le produit. Le Product Goal comble ce vide : il relie chaque Sprint Goal à un but plus large et donne aux stakeholders quelque chose de concret pour inspecter les progrès.
Deux détails comptent à l'examen. Premièrement, la Scrum Team travaille sur un seul Product Goal à la fois. Deuxièmement, elle doit atteindre (réaliser) ou abandonner un Product Goal avant d'en entreprendre un autre.
Le Sprint Backlog et le Sprint Goal
Le Sprint Backlog se compose de trois parties : le Sprint Goal (pourquoi), l'ensemble des éléments du Product Backlog sélectionnés pour le Sprint (quoi) et un plan réalisable pour livrer l'Increment (comment). Elles correspondent aux trois sujets du Sprint Planning : pourquoi ce Sprint est-il utile, que peut-on terminer (Done) pendant ce Sprint, et comment le travail choisi sera-t-il réalisé.
Le Sprint Backlog est un plan fait par et pour les Developers. C'est une image très visible, en temps réel, du travail que les Developers prévoient d'accomplir pendant le Sprint. Les Developers en sont propriétaires et le mettent à jour tout au long du Sprint à mesure qu'ils apprennent.
Comment le Sprint Goal apporte de la flexibilité
Le Sprint Goal est l'objectif unique du Sprint. Il est créé pendant le Sprint Planning et ajouté au Sprint Backlog. Bien que ce soit un engagement des Developers, il offre de la flexibilité quant au travail exact nécessaire pour l'atteindre.
En pratique, cela signifie que les éléments sélectionnés et le plan peuvent changer pendant le Sprint alors que l'objectif reste stable. Si le travail s'avère différent de ce qui était attendu, les Developers collaborent avec le Product Owner pour négocier le périmètre du Sprint Backlog au sein du Sprint, sans modifier le Sprint Goal. Le Daily Scrum est le moment où les Developers inspectent les progrès vers le Sprint Goal et adaptent le Sprint Backlog si nécessaire.
Si le Sprint Goal lui-même devient obsolète, seul le Product Owner peut annuler le Sprint.
L'Increment et la Definition of Done
Un Increment est une étape concrète vers le Product Goal. Chaque Increment s'ajoute à tous les Increments précédents et est vérifié de façon approfondie, afin que tous les Increments fonctionnent ensemble. Pour apporter de la valeur, l'Increment doit être utilisable.
Ce que signifie « Done »
La Definition of Done (DoD) est une description formelle de l'état de l'Increment lorsqu'il atteint les critères de qualité requis pour le produit. Dès qu'un élément du Product Backlog respecte la Definition of Done, un Increment naît.
La DoD crée de la transparence en donnant à tous une compréhension commune du travail réalisé dans l'Increment. C'est le seuil de qualité, et les Developers sont responsables d'instaurer la qualité en la respectant.
D'où vient la Definition of Done :
- Si l'organisation dispose d'une Definition of Done dans ses standards, toutes les Scrum Teams doivent la suivre au minimum.
- Sinon, la Scrum Team doit créer une Definition of Done adaptée au produit.
- Une équipe peut rendre sa DoD plus stricte que le standard de l'organisation, mais pas plus faible.
Que devient le travail non terminé ?
Si un élément du Product Backlog ne respecte pas la Definition of Done, il ne peut pas être livré ni même présenté à la Sprint Review. Il retourne dans le Product Backlog pour être reconsidéré plus tard. Il n'existe pas de « presque terminé » ou de « terminé à 90 % » dans Scrum : le travail est soit Done, soit il ne fait pas partie de l'Increment.
Plusieurs Increments par Sprint
Une idée reçue courante veut qu'un Sprint produise exactement un Increment à la fin. Le guide 2020 indique que plusieurs Increments peuvent être créés au cours d'un Sprint. La Sprint Review ne doit jamais être considérée comme une porte à franchir pour livrer de la valeur : un Increment peut être livré aux stakeholders avant la fin du Sprint. La somme des Increments est présentée à la Sprint Review.
Pièges d'examen fréquents sur les artefacts Scrum
Voici les points qui piègent le plus souvent les candidats aux tests d'entraînement et aux vrais examens :
- À qui appartient le Sprint Backlog ? Aux Developers. Ni au Product Owner ni au Scrum Master. Le Product Owner est propriétaire du Product Backlog.
- Le Sprint Backlog peut-il changer pendant le Sprint ? Oui. Les Developers le mettent à jour à mesure qu'ils apprennent, et le périmètre peut être clarifié et renégocié avec le Product Owner. Ce qu'il ne faut pas compromettre, c'est le Sprint Goal ou la qualité.
- L'équipe peut-elle abaisser la DoD de l'organisation ? Non. Une Definition of Done organisationnelle est un minimum. L'équipe peut y ajouter des critères.
- Un burndown chart est-il un artefact ? Non. Les burndown charts, la vélocité, les story points et les user stories ne figurent pas dans le Scrum Guide. Ce sont des pratiques complémentaires.
- Y a-t-il un Increment par Sprint ? Pas forcément. Plusieurs Increments peuvent être créés, et livrés, au sein d'un même Sprint.
- Le travail non terminé peut-il être montré à la Sprint Review ? Non. Il retourne dans le Product Backlog.
- Combien de Product Goals à la fois ? Un seul. Il doit être atteint ou abandonné avant le suivant.
La meilleure façon de vérifier que vous maîtrisez vraiment ces règles est de répondre à des questions de type examen sous pression de temps. Essayez l'examen blanc PSM gratuit (20 questions, 20 minutes) ou, si vous préparez l'examen Product Owner, la formation à la certification Product Owner, où les questions sur le Product Goal et la gestion du Product Backlog reviennent souvent.
FAQ
Quels sont les 3 artefacts de Scrum ?
Le Product Backlog, le Sprint Backlog et l'Increment. Dans le Scrum Guide 2020, chacun a un engagement : respectivement le Product Goal, le Sprint Goal et la Definition of Done.
Qui crée la Definition of Done ?
Si l'organisation a une Definition of Done, les Scrum Teams la suivent au minimum. Sinon, la Scrum Team en crée une adaptée au produit.
Le Sprint Backlog peut-il changer pendant le Sprint ?
Oui. Les Developers sont propriétaires du Sprint Backlog et le mettent à jour tout au long du Sprint à mesure qu'ils apprennent. Le Sprint Goal reste fixe, et le périmètre peut être renégocié avec le Product Owner.
Le Product Goal est-il un artefact ?
Non. Le Product Goal est l'engagement de l'artefact Product Backlog. C'est l'objectif à long terme de la Scrum Team, et l'équipe n'en poursuit qu'un à la fois.