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

Au début du développement d’un produit Agile, toutes les spécifications et éléments nécessaires pour décrire le produit sont regroupés dans ce que l’on appelle le PRODUCT BACKLOG. Ce répertoire sert de base pour l’équipe de réalisation, leur permettant d’initier le développement.

Le Product Owner (PO) organise ce backlog en regroupant les sujets en Épics (thèmes), qui sont ensuite subdivisés en Features (grandes fonctionnalités). Ces features sont à leur tour décomposées en plusieurs items, typiquement sous forme de User Stories (US) pour la plupart des équipes.

Ce système structuré offre à l’équipe une vision claire du produit et de ses objectifs, facilitant ainsi le processus de développement en alignant tous les efforts vers les mêmes fins.

Le Product Backlog peut contenir divers types d’items, chacun contribuant différemment au développement du produit.

Les User Stories constituent la majorité des items et détaillent les fonctionnalités du point de vue de l’utilisateur. En outre, il est essentiel d’inclure des items de type BUG pour adresser les anamalies qui nécessitent des corrections. On trouve également des Spikes, qui sont des études approfondies pour résoudre des problèmes techniques ou explorer de nouvelles solutions, et des User Stories techniques, généralement rédigées par les développeurs, pour aborder des nécessités internes de l’infrastructure ou du code.

Durant le Sprint Planning, première cérémonie marquant le début d’un sprint, les User Stories sont souvent subdivisées en sous-tâches. Ces tâches doivent être priorisées avec soin, en accord avec l’urgence et l’importance de leur réalisation.

La responsabilité complète du Product Backlog incombe au Product Owner (PO), qui doit veiller à sa gestion continue, à sa mise à jour et à sa priorisation pour refléter fidèlement les besoins du projet et des parties prenantes.

Sprint backlog

Scrum structure le développement d’un projet en cycles répétitifs appelés SPRINTS, chacun ayant des dates de début et de fin clairement définies. La durée d’un sprint est constante à travers le projet, et le guide Scrum recommande typiquement une durée de 2 à 3 semaines.

À la conclusion de chaque sprint, il est impératif que le travail réalisé apporte une valeur ajoutée significative au produit. Pour y parvenir, une série de tâches prédéfinies, souvent sous forme de User Stories et de tâches associées, sont planifiées pour exécution durant le sprint.

Ces tâches sont organisées dans ce que l’on nomme le Sprint Backlog, qui agit comme le réservoir des activités sélectionnées pour le sprint en cours, alignées avec les objectifs immédiats du projet.

L’équipe de réalisation, composée des personnes chargées de l’exécution, notamment les développeurs et les testeurs, est responsable du Sprint Backlog. Ces membres non seulement gèrent et exécutent les tâches prévues pour chaque sprint, mais ils sont également responsables de l’estimation de ces tâches.

En outre, cette équipe détermine un objectif spécifique pour chaque sprint, qui définit la valeur ajoutée attendue du produit une fois toutes les tâches du Sprint Backlog terminées. Cette démarche garantit que chaque cycle de travail apporte une contribution substantielle et mesurable au développement global du produit, alignant les actions quotidiennes sur les ambitions stratégiques plus larges.

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