Les outils Scrum

← Scrum

Les artefacts de Scrum

L’ Incrément

L’ Increment est la somme de tous les items du Product Backlog complété durant le Sprint ajoutée à la valeur des Incréments des précédents Sprints. A la fin d’un Sprint, l’incrément doit remplir la “ Definition of Done” (voir DOD ci-dessous), ce qui signifie qu’il doit être utilisable par le Product Owner si il décide une livraison en production. Un Incrément doit être inspectable afin de favoriser l’empirisme. L’ Incrément est un pas vers une vision ou un but.

Le Product Backlog

Le Product Backlog est l’élément clé de tous les projets Scrum. Il rassemble tous les besoins des utilisateurs du produit ou service en construction en adéquation avec la stratégie business. Le backlog est un artéfact vivant ! Jamais figé il est réajusté en permanence, de façon empirique en fonction de l’avancée du projet. En général un backlog produit est composé majoritairement d’ Epics(collections de User Stories) et de User Stories.

Découper son backlog produit pour le rendre lisible et actionable

Pour des projets de grande envergure, il est parfois d’usage de rajouter deux niveaux supplémentaires : Les Thèmes . Au sommet, ils représentent les grands piliers fonctionnels d’un projet et englobent les Epics et les User Stories. Ces découpages vont dépendre de la taille du projet et du niveau de granularité que l’on souhaite atteindre. Si l’on se contente de deux niveaux de granularité dans un projet, les epics ou épopées représentent un bloc fonctionnel du produit comme une commande en ligne par exemple. Les Users Stories représentent les différentes actions que l’utilisateur a besoin de réaliser pour arriver à son objectif ( Par exemple, mettre un produit au panier, remplir un formulaire etc.)

Faire vivre son backlog tout au long du projet

Contrairement aux spécifications fonctionnelles détaillées , première étape d’un projet classique en cycle en V, le backlog produit n’est pas figé, présente un corpus léger et se construit tout au long du projet. Une épopée non prioritaire, qui ne sera pas développée dans les prochaines itérations, ne sera pas nécessairement détaillée et découpée en stories tout de suite.

Cette approche itérative de la gestion du backlog permet de ne pas perdre de temps à spécifier en détail des éléments qui pourraient être remis en question en cours de projet. Le backlog produit ne contient pas non plus de spécification technique. Seul le besoin fonctionnel est décrit de manière légère et claire pour tous et s’incrémente en permanence avec la production de nouvelles stories.

Régulièrement, le backlog produit est affiné (on parlait auparavent de grooming qui s’est tansformé au fil des versions de Scrum en refinement) avec l’aide de l’équipe de développement pour analyser la complexité des items à produire. Devenant de plus en plus précis au fil du temps, le backlog constitue également l’élément central pour planifier les releases d’un projet.

Le backlog comme socle de la planification projet

Dans tout projet, qu’il soit réalisé en interne, au forfait ou en régie, la planification joue un rôle cruciale dans la détermination du délai projet. Le macro chiffrage d’un projet va être réalisé grâce aux Epics .

Chaque Epic peut-être estimée grâce à des abaques et à l’expérience de l’équipe Scrum en fonction de la complexité analysée. Des points de complexité peuvent-être ainsi attribués à chaque Epic ou story si celle-ci sont déjà exprimées et cette somme de complexité va être confrontée à une estimation de la vélocité de l’équipe si celle-ci est déjà connue.

Ainsi, en estimant la complexité absorbable par une équipe Scrum durant un Sprint (par exemple 50 points de complexité), il sera possible de réaliser une projection pour estimer également une délai de réalisation (Par exemple, une complexité totale estimée à 500 points donnera un ordre de grandeur de 10 Sprints de deux semaines soit 5 mois).

Attention, cela doit être une estimation. Il est important de le prendre comme tel, sous peine de se retrouver en projet cycle en V masqué. Si on a une estimation qui devient prise pour acquise, que le coût est totalement défini suite à ce délai, on a déjà 2 des 3 variables clefs de l’agilité prise. Pour peu que les Epics soient prises comme vérité absolue du scope, on arriverait au fameux Triangle de Fer (Iron Triangle) où tout est fixé (coût, temps, scope). Ce qui rendrait l’agilité impossible.

Le backlog de Sprint

Le backlog de Sprint représente l’ensemble des items du backlog produit embarqués dans un Sprint pour en atteindre l’objectif. Il représente une prévision de ce que l’équipe de développement a estimé pouvoir livrer en fin de Sprint à la suite du Sprint Planning.

Les non artefacts de Scrum non optionnels

Definition of Done (DOD)

La définition de fini(Definition of done ou DOD) s’applique aux user stories du backlog. Chaque équipe se met d’accord pour définir les critères qui feront passer une story en “fini” Par exemple ces critères de DOD peuvent-être : La story a été déployée sur un environnement distant. Les tests demandés sont tous en statut “ok” La qualité de code est à niveau et une revue de code a été réalisée. Il n’y a plus d’activité sur cette story à prévoir.

Les outils de Scrum utilisés comme bonne pratique

Definition of Ready (DOR)

La définition de prêt (Definition of ready ou DOR) s’applique aux user stories du backlog. Chaque équipe se met d’accord pour définir les critères qui feront passer une story en DOR, C’est à dire prête à être injecter dans le backlog de Sprint. Pour qu’une user story soit prête, elle doit respecter le principe INVEST :

Independent : Elle doit pouvoir être réalisée durant le Sprint sans être bloquée par des dépendances techniques,
Negotiable : Elle est négociable avec l’équipe de développement. Exprimée de façon très simple, la story n’a pas pour vocation de rentrer dans le détail et de donner des indications sur sa réalisation. Elle exprime un besoin fonctionnel,
Valuable : Elle apporte une valeur business au produit. Elle reflète un vrai besoin de l’utilisateur de la solution,
Estimable : Elle doit être suffisamment claire et bien comprise pour pouvoir être estimée par les développeur,
Small : Elle doit pouvoir être réalisée dans le Sprint. Si la story est trop importante, elle doit être découpée,
Testable : Elle soit pouvoir être testée selon un scénario utilisateur qui possède un début et une fin. ces scénarii peuvent-être ajouté à la story delon le principe du Behavior Driven Development ou BDD.

La User Story (US)

Une User Story sert à exprimer clairement un besoin utilisateur. Autrement dit, une US est une exigence à développer, formulée en quelques mots clairs et définie au cours d’ateliers de travail menés avec les utilisateurs. Elles sont souvent structurées de la manière suivante : En tant que [Profil utilisateur] Je veux [Actions à réaliser] Afin de [Bénéfice] Les US composent ainsi une Product Backlog et y seront injectées selon leur priorité. Pour se faire, l’US doit répondre à certains critères.

Test Driven Development

Le Test Driven Development ou TDD a été inventé en 2003 par Kent Beck. L’origine date de l’Extreme Programming (XP) de 1999 de la notion de test-first programming. Voici les étapes couramment utilisées lors du TDD:

Ajouter un test avec une condition
Faire tourner les tests et voir que le nouveau test plante après avoir mis l’inverse de la condition. Cela valide le fait que l’on passe bien dans le test.
Ecrire le code afin de faire passer le test. Il ne faut se préoccuper que de fairer passer le test.
Lancer les tests pour voir si on n’a pas fait de régression
Refactorer le code

Behavior Driven development

Le Behavior Driven Development ou BDD est une méthodologie proposée par Dan North en 2009 pour aller au delà du TDD.

Il permet d’intégrer à la US un test d’acceptation (User Test Acceptance) du point de vue de l’utilisateur qui doit “driver” le développement de la story : Ce test s’écrit généralement de la façon suivante :

(Given) some context (When) some action is carried out (Then) a particular set of observable consequences should be obtained

Exemple :

Étant donné que je suis connecté sur la login page en tant que Admin Interne.
Lorsque je clique sur “Me connecter” sans avoir cocher la cas eUser Interne.
Alors un message d’erreur apparaît en rouge indiquant à que ses informations sont erronées.

Burndown Chart

Le Burndown Chart est un outil graphique qui permet de visualiser le travail réalisé par l’équipe de développement et le travail restant à produire pour terminer le Sprint.

Il permet de comparer la courbe de travail effectuée avec une courbe idéale pour voir les écarts et potentiellement mieux s’adapter.

Valeur métier

La valeur métier retranscrit la vision métier des priorités des utilisateurs finaux pour chaque user story. Elle peut-être évaluée avec les critères de la méthode MoSCoW (Must have, Should have, Could have, Won’t have)

Complexité

La complexité exprime la difficulté technique pour l’équipe de développement de la mise en œuvre d’une user story. Il s’agit d’un chiffrage relatif qui peut être fait via la suite de Fibonacci (1, 2, 3, 5, 8, 13, 21, …), taille de tshirt (XS, S, M, L, XL, XXL, XXXL).

La vélocité mesure la capacité d’une personne de l’équipe de réalisation à produire un certain nombre de points de complexité par jour. Exemple : une équipe de 5 personnes qui produit 24 points pour un Sprint d’une semaine (5 jours ouvrés), a donc une vélocité de 0,96. Elle est historisée et permet de suivre la capacité de l’équipe à s’améliorer au fil du temps.

A lire sur le même thème :