Le terme « artefact » désigne un produit qui a été transformé ou créé par l’intervention humaine. Dans le contexte de Scrum, les artefacts sont des outils qui représentent les objectifs, la priorisation des tâches, et le suivi de la progression de l’équipe.

Scrum identifie trois artefacts principaux :

Product Backlog : une liste ordonnée de tout ce qui est nécessaire pour le développement du produit.

Sprint Backlog : l’ensemble des items sélectionnés pour le Sprint, plus un plan pour livrer le produit Increment et réaliser l’objectif du Sprint.

Increment : la somme de tous les items du Product Backlog complétés pendant un Sprint et tous les Sprints précédents.

En plus de ces trois artefacts classiques, il y a un artefact supplémentaire qui joue un rôle crucial en termes de transparence :

Definition of Done (DoD) : une liste clairement définie de critères qui doit être remplie pour qu’une User Story soit considérée comme complète.

Ces quatre éléments sont essentiels à la gestion efficace d’un projet Scrum et subissent des transformations continues tout au long de la vie du produit pour s’adapter aux changements et aux besoins émergents. Ces transformations permettent de maintenir l’alignement de l’équipe avec les objectifs du projet et d’assurer la transparence dans le processus de développement.

Product backlog


Le Product Backlog est un élément central de la méthodologie Scrum. Il s’agit d’une liste priorisée, évolutive et transparente de toutes les fonctionnalités, améliorations, corrections ou besoins techniques à développer pour faire évoluer un produit.

Construit et maintenu par le Product Owner, le Product Backlog représente la vision du produit et oriente le travail de l’équipe de développement. Il est constamment enrichi au fil du temps en fonction des retours des utilisateurs, des priorités business ou des contraintes techniques.

Chaque élément du backlog – souvent appelé User Story – décrit une fonctionnalité ou un besoin métier. Ces éléments sont généralement accompagnés d’un niveau de priorité, d’une estimation de complexité, ainsi que de critères d’acceptation permettant de valider leur bon fonctionnement.

Le Product Backlog n’est jamais figé : il évolue en continu grâce à un travail d’affinage collaboratif (backlog refinement) entre le Product Owner et l’équipe. L’objectif est de s’assurer que les éléments les plus importants soient prêts à être développés lors du prochain Sprint.

Un backlog bien structuré et partagé permet de maximiser la valeur délivrée à chaque itération et d’aligner l’ensemble de l’équipe sur les objectifs à atteindre.

Sprint backlog

Le Sprint Backlog est l’artefact Scrum qui représente le plan de l’équipe pour atteindre l’objectif du Sprint. Il est composé d’un ensemble d’éléments du Product Backlog sélectionnés pour être réalisés pendant le Sprint, ainsi que des tâches techniques nécessaires à leur mise en œuvre.

Ce backlog est créé et géré par l’équipe de développement au début du Sprint, généralement lors du Sprint Planning. L’équipe y définit comment elle va transformer les besoins exprimés en valeur livrable à la fin du Sprint.

L’objectif n’est pas seulement de livrer des éléments techniques, mais de répondre à un objectif clair et partagé : l’Objectif de Sprint (Sprint Goal). Cet objectif donne une direction commune et aide à guider les décisions tout au long du Sprint.

L’équipe est libre de décider comment atteindre cet objectif, en adaptant et réorganisant les tâches du Sprint Backlog si nécessaire. Elle peut, par exemple :

découper davantage les tâches,
ajuster certaines priorités,
intégrer des apprentissages ou imprévus rencontrés en cours de route.

Le Sprint Backlog est donc vivant et évolutif : il sert à visualiser le travail en cours, à faciliter la collaboration quotidienne, et à assurer que tous les efforts convergent vers l’objectif fixé.

Un bon Sprint Backlog est clair, partagé, mis à jour en continu, et piloté par la recherche de valeur et de cohérence avec l’objectif du Sprint.

Product incrément

Durant chaque Sprint, l’équipe de développement travaille à créer un segment du produit qui est cohérent et prêt à être déployé sur le marché; ceci est connu comme l’incrément produit. Ce processus assure que chaque partie livrée ajoute de la valeur tangible au produit final.

Pour garantir la qualité et la complétude, chaque tâche ou User Story achevée doit satisfaire à la Definition Of Done (DoD) établie par l’équipe. Cette DoD est une liste de critères précis qui déterminent quand une User Story est considérée comme terminée, assurant ainsi uniformité et qualité tout au long du développement.

L’incrément produit final de chaque sprint doit intégrer toutes les tâches (User Stories) qui ont été estimées et incluses dans le Sprint Backlog lors de sa constitution. Cette intégralité est cruciale pour maintenir l’intégrité et la fonctionnalité du produit à chaque étape du développement.

Il arrive parfois que certaines tâches ne soient pas achevées à la fin du sprint, souvent en raison d’imprévus qui peuvent ralentir leur développement et leur livraison.

Dans de tels cas, les User Stories incomplètes sont généralement reportées au sprint suivant. Cependant, elles peuvent aussi être dépriorisées par le Product Owner (PO) en fonction de l’évolution des priorités et des besoins du projet. Cette flexibilité est cruciale pour s’adapter aux dynamiques changeantes du marché et pour assurer que l’équipe reste concentrée sur les éléments qui apportent la plus grande valeur au produit.

 

DoD

Cet artefact Scrum, connu sous le nom de Definition of Done (DoD), est crucial pour clarifier ce que l’équipe entend par « terminé ». La DoD est une norme collective que l’équipe établit pour déterminer les conditions sous lesquelles une User Story peut être considérée comme achevée et, par conséquent, potentiellement prête à être livrée.

Il s’agit d’une liste de critères spécifiques que l’équipe doit définir avant de lancer son premier Sprint. Ces critères sont essentiels pour assurer la cohérence et la qualité du travail fourni. Tout au long du développement du produit, cette liste peut être revue et affinée, permettant à l’équipe de s’adapter et d’améliorer continuellement ses processus de vérification et de validation.

La Definition of Done (DoD) doit être clairement visible pour tous les membres de l’équipe et peut être affichée sur un mur ou sur un tableau virtuel si l’équipe travaille à distance. Pour une gestion plus dynamique, elle peut également être intégrée sur chaque tâche (User Story) du Sprint Backlog sous la forme d’une liste avec des cases à cocher, permettant à chaque membre de l’équipe de marquer sa partie comme terminée en cochant la case correspondante.

Il est important de noter que les critères inclus dans la Definition of Done ne sont pas figés et peuvent être révisés par l’équipe tout au long du projet. Certains critères peuvent être ajoutés, modifiés, ou même retirés en cours de route pour mieux s’adapter aux réalités du développement et aux exigences du produit. Cette flexibilité permet à l’équipe de maintenir des standards de qualité pertinents et adaptés à l’évolution des conditions du projet.

A propos

Coach Agile, j’accompagne les organisations et les équipes à comprendre et à mettre en place les principes de l’Agilité (mindset, framework, méthodes, outils)
En savoir plus