Bonjour !
Dans notre leçon précédente, nous avons exploré le rythme de Scrum en détaillant ses cinq événements-clés : le Sprint, le Sprint Planning, le Daily Scrum, la Sprint Review et la Sprint Retrospective. Nous avons vu que ces événements structurent le temps et les interactions de l'équipe, et sont des opportunités formelles d'inspection et d'adaptation.
Aujourd'hui, nous allons nous concentrer sur le "quoi" : les outils concrets qui rendent le travail visible et tangible. L'objectif de cette leçon est d'expliquer le rôle des artefacts Scrum : le Product Backlog, le Sprint Backlog et l'Incrément.
Pour vous, qui aspirez à un rôle de Tech Lead ou de chef de projet technique, la maîtrise de ces artefacts est fondamentale. Ils ne sont pas de simples listes de tâches ; ce sont les instruments centraux de la planification, de la communication et du suivi. Ils matérialisent la vision du produit et le plan pour la réaliser. Savoir les lire, les construire et les utiliser est une compétence essentielle pour guider une équipe et dialoguer avec les parties prenantes.
1. Qu'est-ce qu'un Artefact Scrum ?
Avant de détailler chaque artefact, il est important de comprendre leur rôle commun. Dans Scrum, un artefact est un outil qui représente le travail ou la valeur. Leur but principal est de maximiser la transparence.
Pour comprendre cette idée de transparence, je vous propose de lire une courte introduction.
Méthode Scrum : l'agilité au quotidien pour vos projets ...
L'article "Méthode Scrum : l'agilité au quotidien pour vos projets..." sur le site YesWeDev explique très bien pourquoi la transparence est le premier pilier de Scrum et comment les artefacts la rendent possible.
Lisez les paragraphes sous le titre "Les 'Artefacts'". Concentrez-vous sur l'idée que pour inspecter le travail et s'adapter, il faut d'abord pouvoir le "voir" de manière transparente.
Comme vous l'avez lu, sans artefacts clairs et partagés, il est impossible pour l'équipe et les parties prenantes d'avoir une conversation constructive sur l'avancement et la direction du produit.
Scrum prescrit trois artefacts officiels. Chacun est associé à un "engagement" qui lui donne un objectif et une direction.
Explorons-les un par un.
2. Le Product Backlog
Le Product Backlog est le point de départ de tout travail dans Scrum. C'est la source de vérité unique pour tout ce qui pourrait être fait sur le produit.
Pour bien comprendre toutes ses facettes, je vous propose une vidéo très complète et didactique.
Product Backlog : Scrum Life présente
La chaîne Scrum Life a produit une excellente vidéo dédiée au Product Backlog. Elle va bien au-delà de la simple définition en abordant son caractère émergent, son appropriation et les erreurs courantes.
Regardez la vidéo du début jusqu'à 03:38. Portez une attention particulière aux points suivants : Qu'est-ce que le Product Backlog et que peut-il contenir ? Que signifie le fait qu'il est "ordonné" et "émergent" ? Qui en est responsable ? L'exemple concret de ce qu'il ne faut pas faire (le PO qui arrive avec une liste de 112 éléments) versus la bonne approche collaborative.
Pour synthétiser et formaliser ce que vous venez de voir, voici les points essentiels concernant le Product Backlog :
- Description : C'est une liste ordonnée et émergente de tout ce qui est connu comme étant nécessaire pour améliorer le produit. Cela peut inclure des fonctionnalités, des corrections de bugs, des améliorations techniques (comme la refactorisation), ou même des travaux de recherche.
- Propriétaire : Le Product Owner est responsable du Product Backlog, y compris de son contenu, de sa disponibilité et de son ordonnancement. Cependant, sa création et son affinage sont des activités collaboratives impliquant toute la Scrum Team.
- Caractère dynamique : Le Product Backlog n'est jamais complet. Il évolue constamment à mesure que l'équipe et les parties prenantes en apprennent davantage sur le produit, le marché et les clients. C'est ce qu'on appelle son caractère émergent.
- Engagement - Le Product Goal : Le Product Backlog a un objectif à long terme, le Product Goal. Il décrit un état futur du produit que l'équipe cherche à atteindre. Chaque élément du backlog doit, d'une manière ou d'une autre, contribuer à ce but. C'est ce qui donne une direction et un sens au travail.
Testez votre compréhension !
Un nouveau client demande l'ajout d'une fonctionnalité "critique" qui n'était pas prévue. Que doit faire le Product Owner ?
- Refuser, car ce n'est pas dans le plan initial.
- Demander à l'équipe de tout arrêter pour travailler dessus immédiatement.
- Ajouter cette demande au Product Backlog et en discuter avec la Scrum Team et les parties prenantes pour évaluer sa valeur et sa priorité par rapport aux autres éléments et au Product Goal.
Show answer
La bonne réponse est la 3. Le Product Backlog est un artefact vivant. Une nouvelle idée, même si elle semble critique, doit être ajoutée au backlog pour être ensuite évaluée et priorisée. Cela garantit que l'équipe reste concentrée sur l'objectif du Sprint en cours, tout en permettant au backlog d'évoluer de manière ordonnée.
3. Le Sprint Backlog
Si le Product Backlog est la liste de tout ce qui pourrait être fait, le Sprint Backlog est le plan pour ce qui sera fait pendant le Sprint en cours.
Nous avons vu dans la leçon précédente que cet artefact est créé lors du Sprint Planning. Approfondissons maintenant sa nature et son rôle.
Les Artefacts Scrum : Guide Complet
L'article "Les Artefacts Scrum : Guide Complet" du site scrum-master.org fournit une description très claire et structurée du Sprint Backlog.
Lisez la section intitulée "Sprint Backlog". Notez bien : Comment il est créé et par qui. De quoi il est composé (les éléments du Product Backlog + le plan pour les réaliser). Son lien avec le Sprint Goal.
Résumons les points clés :
- Description : Le Sprint Backlog est composé de l'Objectif de Sprint (le "pourquoi"), des éléments du Product Backlog sélectionnés pour le Sprint (le "quoi"), et d'un plan d'action pour livrer l'Incrément (le "comment").
- Propriétaire : Le Sprint Backlog est un plan créé par les Developers, pour les Developers. Ils sont les seuls à pouvoir le modifier pendant le Sprint. C'est leur plan de travail en temps réel.
- Caractère dynamique : Tout comme le Product Backlog, il est évolutif. Si les Developers découvrent de nouvelles tâches nécessaires pour atteindre le Sprint Goal, ils les ajoutent au Sprint Backlog. Si certaines tâches s'avèrent inutiles, ils peuvent les retirer. Il est mis à jour quotidiennement, typiquement pendant le Daily Scrum.
- Engagement - Le Sprint Goal : C'est l'objectif unique du Sprint. Il est élaboré pendant le Sprint Planning et ajouté au Sprint Backlog. Le Sprint Goal fournit la flexibilité : si le plan détaillé (le "comment") s'avère mauvais, les Developers peuvent le modifier tant qu'ils travaillent à l'atteinte du Sprint Goal. L'engagement est sur l'objectif, pas sur la liste des tâches.
4. L'Incrément
L'Incrément est le résultat tangible de chaque Sprint. C'est la raison d'être de tout le framework.
- Description : Un Incrément est la somme de tous les éléments du Product Backlog terminés pendant un Sprint, ajoutée à la valeur de tous les Incréments précédents. C'est une version concrète et fonctionnelle du produit.
- Propriétaire : L'Incrément est le résultat du travail de toute la Scrum Team.
- Caractère clé : Chaque Incrément doit être utilisable. Le Product Owner peut décider de le livrer aux utilisateurs finaux ou non, mais il doit être dans un état potentiellement livrable.
- Engagement - La Definition of Done (DoD) : C'est l'un des concepts les plus importants de Scrum, et il vous parlera particulièrement en tant que développeur. La DoD est un accord formel au sein de la Scrum Team, une liste de critères qui doivent être respectés pour qu'un élément du backlog soit considéré comme "terminé".
Pour illustrer ce qu'est un Incrément et sa relation avec la DoD, regardons un court extrait vidéo.
Les bases de Scrum : Tout ce que vous devez savoir
Nous retournons à la vidéo d'Agitips, qui explique de manière concise ce qu'est un Incrément et introduit la Definition of Done.
Regardez les deux extraits : de 07:28 à 07:51, puis de 10:00 à 10:35. Le premier définit l'Incrément, le second introduit la Definition of Done.
La Definition of Done assure la transparence et la qualité. Elle répond à la question : "Qu'est-ce que ça veut dire, 'c'est fini' ?". Pour une équipe de développement, une DoD pourrait inclure des critères comme :
- Le code est écrit et respecte les standards de l'équipe.
- Les tests unitaires et d'intégration sont écrits et réussissent.
- Le code a été revu par un autre développeur (pull request validée).
- La documentation technique a été mise à jour.
- La fonctionnalité est déployée sur l'environnement de pré-production.
Sans une DoD claire et partagée, un développeur peut penser qu'une tâche est terminée lorsqu'elle "marche sur sa machine", tandis que le Product Owner s'attend à ce qu'elle soit déjà testée et documentée. La DoD élimine cette ambiguïté.
Conclusion
Nous avons vu aujourd'hui les trois artefacts Scrum qui rendent le travail et la valeur transparents. Ils sont les piliers sur lesquels reposent les événements d'inspection et d'adaptation.
Voici les points clés à retenir :
- Les artefacts (Product Backlog, Sprint Backlog, Incrément) sont des outils pour maximiser la transparence.
- Le Product Backlog est la liste unique, ordonnée et émergente de tout le travail à faire pour le produit. Son engagement est le Product Goal.
- Le Sprint Backlog est le plan des Developers pour un Sprint, incluant les éléments sélectionnés et un plan pour les réaliser. Son engagement est le Sprint Goal.
- L'Incrément est la partie du produit, utilisable et potentiellement livrable, créée à chaque Sprint. Son engagement est la Definition of Done, qui garantit un niveau de qualité partagé.
Ces trois artefacts ne sont pas indépendants. Ils forment une chaîne logique : on puise dans le Product Backlog pour créer le Sprint Backlog, dont l'exécution produit un Incrément.
Dans notre prochaine leçon, nous deviendrons encore plus concrets. Nous apprendrons à rédiger une User Story claire et concise, incluant des critères d'acceptation. C'est la technique la plus populaire pour décrire les éléments du Product Backlog d'une manière qui soit centrée sur l'utilisateur et facilement compréhensible par toute l'équipe. À bientôt