Définition des artefacts Scrum : les 6 notions indispensables

Les artefacts du cadre méthodologique Scrum

Les artefacts Scrum sont basés sur un ensemble de valeurs, principes et pratiques qui fournissent la base de la philosophie Agile.

Mais pour commencer, que veut dire artefact ?

Le mot artefact désigne, de manière générale, un produit ayant subi une transformation, même minime, par l’homme et qui se distingue ainsi d’un autre provoqué par un phénomène naturel.

Wikipédia

La définition peut paraître difficile à comprendre et à associer au scrum. Pourtant, les artefacts scrum répondent parfaitement à cette définition comme nous allons le voir.

Rappel : Lors d’un développement utilisant le cadre Scrum, le produit est découpé en fonctionnalités. Une équipe Scrum va développer ces tâches en respectant un calendrier et une cadence fixe.

Pour répondre à des évolutions rapides, l’équipe travaille au rythme des itérations qui ont pour objectif d’apporter des nouvelles fonctionnalités au produit à chaque fin de cycle.

Alors que signifient les artefacts Scrum ?

Les artefacts Scrum sont au nombre de 3 :

  • Le Sprint Backlog;
  • Le Product Backlog;
  • L’Incrément Produit.

3 autres notions complètent ces artefacts :

  • La User Sotry;
  • Les Story Points;
  • La Definition Of Done

Scrum utilise le terme Artefact car ces éléments subissent des transformations venant de l’homme regroupant tout le nécessaire pour créer quelque chose de nouveau.

Dans cet article je vais détailler chacun des artefacts scrum utilisés par une équipe Scrum.

Définition des artefacts Scrum 

On ne peut comprendre ou appliquer le cadre méthodologique Scrum sans connaître les termes de sprint, backlog, user story ou story point…

Ce jargon a l’air complexe au premier abord, cependant il ne faut se laisser effrayer.

Ces artefacts ont été spécialement conçus pour maximiser la transparence des informations afin que tout le monde ait la même compréhension de leur définitions et de leur utilités.

Les 6 artefacts Scrum 

Le sprint backlog

Comme défini dans l’introduction, le cadre méthodologique Scrum divise le calendrier d’une équipe en cycles qui se répètent.

Un certain nombre de tâches prédécoupées sont intégrées dans ces différents cycles.

À la fin de chaque cycle, le travail accompli doit créer de la valeur pour le produit en développement. Ces cycles sont appelés “sprints”. Ils ont une date de début et une date de fin fixe.

La durée d’un sprint est toujours la même. Le guide Scrum conseille de la fixer à 2 ou 3 semaines. 

Sprint

Le backlog produit (ou product backlog)

Au démarrage du développement d’un produit agile, le MVP va être découpé en petites fonctionnalités ou tâches à réaliser pour faciliter sa construction.

Cette planification va permettre à l’équipe d’avoir une vision du produit et de son objectif. 

Ces tâches prédécoupées seront rangées dans ce qu’on appelle le backlog produit. 

C’est une sorte de réservoir regroupant l’ensemble des fonctionnalités du produit. Les tâches doivent y être ordonnées avec discernement en fonction de la priorité dans laquelle elles doivent être réalisées. 

En parallèle, il y a également le backlog de sprint, qui lui représente le réservoir des tâches intégrées dans le sprint en cours.

Le backlog d’un sprint est un engagement de la part de l’équipe sur les fonctionnalités qui seront développées à la fin du cycle.

La user story

Une user story est une sorte de carte d’identité qui définit la fonctionnalité ou la tâche à développer. L’objectif de cet artefact est de réduire au maximum les possibilités d’interprétation des consignes écrites.

Une US se doit de comporter les éléments suivants :  

  • L’utilisateur cible ou groupe d’utilisateurs de la fonctionnalité;
  • Ce que souhaite l’utilisateur;
  • Pourquoi la fonctionnalité est-elle requise.

Cela permet de donner toutes les informations utiles à la compréhension de la tâche et à sa réalisation. 

La rédaction d’une US doit suivre un certain modèle : 

En tant que < utilisateur cible >, je souhaite < objectif de la fonctionnalité > afin de <raison du développement de la fonctionnalité (le pourquoi) >

Exemple : si la fonctionnalité est la connexion à une application, voici à quoi ressemblerait la user story:

En tant qu’ < utilisateur m’étant enregistré au moins une fois >, je souhaite < me connecter à l’application > afin de < pouvoir afficher le contenu uniquement disponible pour les utilisateurs enregistrés >.

Le suivi de la structure d’une user story paraît un peu stricte et futile, cependant elle est très importante. Elle permet de ne pas oublier d’information et de se poser les bonnes questions.

Au fur et à mesure de son utilisation le modèle paraîtra plus naturel. 

Les story points

Une estimation est fournie à chaque user story. Elle est réalisée en équipe durant l’une des cérémonies Scrum.

En savoir plus sur les 4 rituels Scrum.

Estimer une user story consiste à lui donner un nombre de point qui va qualifier sa complexité.

Dans un projet géré avec les méthodes traditionnelles du type « waterfall », les différentes tâches sont évaluées en nombre d’heures.

L’utilisation de Scrum remplace cette temporalité par des points de complexités provenant de la série de Fibonacci (1,2,3,4,8,13,21,34…). 

L’intérêt d’utiliser des chiffres abstraits pour évaluer une user story est de permettre aux individus ayant des compétences, et des vitesses d’exécutions différentes, de se mettre d’accord.

La définition de “terminé” (Ou Definition of Done)

Un des artefacts Scrum consiste à définir ce que signifie pour l’équipe le terme “terminé”.

En effet, si vous interrogez trois personnes en leur demandant de décrire ce qu’est, selon eux, une tache terminée, vous aurez trois descriptions différentes.

Ces interprétations n’ont pas leur place dans une équipe Scrum.

D’autant plus qu’un produit ne doit pas avoir de fonctionnalité à “moitié effectuées” ou de tâches ne pouvant être utilisées en fin de cycle. La définition de “Terminé” doit être unanime

La « définition de terminé » (ou DoD en anglais) est une liste de vérifications des tâches que l’équipe doit réaliser avec succès avant de déclarer que la fonctionnalité est potentiellement livrable.

Ces vérifications peuvent varier selon la nature du produit, les technologies utilisées ,…mais il est essentiel de s’assurer qu’elles soient entendues, comprises et appliquées par toute l’équipe

Selon Scrum Alliance, il existe 3 sortes de DoD

  • Définition de Terminé pour une fonctionnalité (user story ou élément de backlog de produit);
  • Définition de Terminé pour un sprint;
  • Définition de Terminé pour une version.

Voici quelques exemples de vérifications à apporter à la tâche réalisée avant de la déclarer comme “terminée”: 

  • Le design correspond à la demande/maquette;
  • Le code a été testé;
  • Le code a été inspecté;
  • Le tracking est mis en place;

L’incrément de produit (Ou Product Increment)

Incrément produit : artefacts scrum

Source : RomanPichier

C’est un des artefacts Scrum les plus importants de la culture Agile.

Durant chaque Sprint, l’équipe de développement réalise un incrément de produit.

Cet incrément de produit doit s’aligner sur la «Définition de Terminé» de l’équipe de développement.

Si l’équipe a bien estimé les différentes user stories intégrées dans le sprint, l’incrément comprend toutes ces tâches, qui étaient prévues dans le Sprint Backlog.

En conclusion

Vous êtes, à présent, familier avec la définition des artefacts Scrum. Dans le prochain article, je définirai les différentes cérémonies ou rituels de Scrum.

N’oubliez pas, Scrum ne représente pas seulement un jargon composé de “buzzwords”. Chacun de ces termes est important. Ils doivent être appliqués afin de profiter au maximum des avantages de la mise en place de Scrum. 


Agathe Penverne

A propos de l'auteur

Je suis Agathe PENVERNE, Product owner, coach et rédactrice depuis 3 ans. Mon aspiration est d'aider mes semblables et mes équipes à s’épanouir dans des environnements agiles et à s'organiser autour de la résolution de problèmes.

Les autres articles du dossier

{"email":"Adresse email invalide","url":"Url du site invalide","required":"Champ obligatoire non renseigné"}

Télécharger le Guide du

Chef de Projet

25 Conseils d'expert en Management de Projet

__CONFIG_colors_palette__{"active_palette":0,"config":{"colors":{"34f05":{"name":"Main Accent","parent":-1}},"gradients":[]},"palettes":[{"name":"Default Palette","value":{"colors":{"34f05":{"val":"var(--tcb-skin-color-0)"}},"gradients":[]},"original":{"colors":{"34f05":{"val":"rgb(19, 114, 211)","hsl":{"h":210,"s":0.83,"l":0.45}}},"gradients":[]}}]}__CONFIG_colors_palette__
Je télécharge le Guide gratuitement
>