Après vous avoir présenté l’agilité dans l’article “L’agilité“, je vous présente aujourd’hui la méthodologie Scrum pour laquelle je suis certifiée.

Scrum ne se définit pas comme étant une méthode mais plutôt un cadre de travail.

Une méthode dit généralement « comment » faire les choses, or Scrum ne dit pas comment surmonter les obstacles, comment développer, comment spécifier, etc. Il offre un cadre composé de rôles, d’événements, d’artéfacts et de règles associées.

Le terme “artefacts” est souvent difficile à maîtriser, nous pouvons dire que se sont des objets que nous créons, comme un outil pour résoudre un problème.

Scrum repose sur 3 piliers :

Transparence

L’équipe Scrum et les parties prenantes doivent avoir accès et partager les informations en se basant sur un langage et des définitions communs. La transparence fait aussi référence à des valeurs comme le courage : courage de dire les choses difficiles, reconnaître et apprendre de ses erreurs, savoir dire non…

Inspection

L’équipe Scrum doit se consulter régulièrement pour détecter rapidement d’éventuels écarts entre l’objectif du sprint et le travail réalisé.

Adaptation

Si des écarts sont constatés lors d’une phase d’inspection, un ajustement doit être entrepris au plus vite afin d’atteindre les objectifs du Sprint.

Nous verrons un peu plus loin 4 événements formels d’inspection et d’adaptation.

Scrum est fondée sur les 5 valeurs suivantes :

L’équipe Scrum

L’équipe Scrum est constituée de 3 rôles :

  • Un Product Owner
  • Une Development Team
  • Un Scrum Master

Ils se réunissent autour de différents événements.

L’équipe Scrum est :

  • auto-organisée, elle prend donc les décisions sur la manière dont le travail sera réalisé pour atteindre l’objectif du sprint.
  • non hiérarchisée, c’est-à-dire qu’il n’y a pas de chef qui dirige les membres de l’équipe.
  • pluridisciplinaire de manière à posséder toutes les compétences requises à la réalisation des tâches.

Product Owner [PO]

Le Product Owner est responsable de la partie fonctionnelle, il est responsable du « QUOI » faire ?

Mais afin de bien comprendre et transmettre, communiquer le « QUOI », le PO doit également bien maîtriser le « POURQUOI », la raison pour laquelle on doit faire chaque chose.

Il est :

  • garant du produit, il a la charge d’en maximiser sa valeur
  • seul responsable de la gestion du Product Backlog

Chez CreativMinds, en tant que Business Analyst, nous pouvons officier en tant que PO.

Development Team [DT]

L’équipe de développement est composée idéalement de 3 à 9 personnes. Suffisamment grande pour avoir un maximum de compétences et suffisamment petite pour ne pas perdre trop de temps en coordination.

Elle s’occupe du « COMMENT » faire (choix techniques, qualité du code, etc. ), elle s’organise et gère son travail comme elle le souhaite.

Scrum Master [SM]

Le Scrum Master est un facilitateur. Il aide tout le monde à comprendre la théorie, les pratiques, les règles et les valeurs de Scrum.

Le Scrum Master doit :

  • faciliter le processus
  • être au service de l’équipe Scrum pour maximiser la valeur créée par celle-ci
  • lever les obstacles
  • protéger l’équipe des perturbations extérieures
  • être le garant du temps lors des événements Scrum.

Il ne fait généralement pas partie de l’équipe de développement, il n’est pas là pour produire, il est là pour accompagner l’équipe.

Les événements Scrum

Tous les événements sont limités dans le temps à une durée maximale. Si la durée du Sprint ne peut être modifiée à partir du moment ou celui-ci a démarré, les autres événements peuvent se terminer dès que leurs objectifs sont atteints.

Chaque événement Scrum est une occasion formelle d’inspecter et d’adapter. Ces événements sont spécifiquement conçus pour permettre la transparence et l’inspection.

Le sprint

Le Sprint est le cœur de Scrum, il a une durée d’un mois ou moins, au cours de laquelle un Incrément publiable du produit est créé. Publiable ne veut pas nécessairement dire mettre en production, le produit délivré est au moins utilisable.

Un nouveau Sprint commence dès la conclusion du Sprint précédent.

L’objectif du Sprint est fixe. Le périmètre peut-être clarifié et négocié entre le PO et la DT, mais les changements qui remettent en cause l’objectif du Sprint ne sont pas permis.

Seul le PO a le pouvoir d’annuler un Sprint avant son échéance. Cette action étant bouleversante pour l’équipe et chronophage, les annulations sont très rares.

Le Sprint est le conteneur pour tous les autres événements Scrum.

Sprint planning

Chaque Sprint démarre avec un Sprint Planning lors duquel l’équipe doit déterminer le travail à effectuer pendant le Sprint.

L’équipe :

  • détermine l’objectif du Sprint (Sprint Goal)
  • sélectionne les éléments du Product Backlog permettant d’atteindre l’objectif
  • détermine comment atteindre cet objectif en élaborant un plan à partir des éléments sélectionnés

Le Sprint Planning à une durée maximum de 8h (2h pour un Sprint d’1 semaine), et l’équipe Scrum au complet y participe (PO, DT, SM).

Les éléments nécessaires pour le démarrage de la séance sont le Product Backlog, le dernier incrément du produit, la capacité projetée par la DT pendant le script et les performances passées de la DT.

Daily Scrum

Le Daily Scrum d’une durée maximum de 15 mn est destiné à la DT uniquement, tous les jours du Sprint.

L’équipe planifie le travail pour les 24h à venir.

En général chaque membre de l’équipe indique ce qu’il a fait depuis le dernier Daily Scrum, ce qu’il compte faire et surtout s’il a rencontré des difficultés.

Sprint Review

A la fin du Sprint, l’ensemble de l’équipe Scrum ainsi que les parties prenantes se réunissent pour une durée maximum de 4h pour effectuer la Sprint Review, c’est-à-dire un bilan du Sprint.

Le PO indique les éléments du Product Backlog qui ont été finis et ceux qui ne l’ont pas été.

La DT :

  • discute de ce qui s’est bien passé dans le Sprint
  • relate quels sont les problèmes rencontrés et les solutions apportées
  • démontre le travail fini.
  • se tient à disposition pour répondre aux éventuelles questions.

L’ensemble du groupe décide de ce qu’il faut faire pour la suite.

Sprint Retrospective

La Sprint Retrospective une opportunité pour l’équipe Scrum de s’auto-inspecter et de créer un plan d’améliorations pour les prochains Sprints.

D’une durée maximum de 3h elle a lieu après la Sprint Review et avant le prochain Sprint Planning.

Le but est d’inspecter le déroulement du Sprint d’un point de vue :

  • des personnes
  • des relations
  • des process
  • des outils

En résumé, de faire bilan de ce qui a bien fonctionné et ce qui était moins bien, et de mettre en place des améliorations.

Plusieurs méthodes assez ludiques existent pour mener à bien cet événement, elles feront l’objet d’un prochain article.

Les artéfacts

Les artéfacts sont au nombre de 4

Product Backlog

Le Product Backlog est l’élément clé de tous les projets Scrum, c’est la liste des besoins du produit (fonctionnalités, fonctions, exigences, améliorations, corrections, etc.).

Il est dynamique, réajusté en permanence, en fonction de l’avancée du projet et du contexte.

Les éléments du Product Backlog se composent comme suit :

  • une description
  • un ordre
  • une estimation
  • une valeur

Mais aussi souvent des descriptions de tests permettant de valider le point. Ces éléments sont la plupart du temps représentés par des Epics et des User Stories.

Le PO en est responsable, y compris de son contenu, sa disponibilité et son ordonnancement.

Sprint Backlog

Le Sprint Backlog représente l’ensemble des éléments du Product Backlog sélectionnés pour le Sprint, plus un plan pour livrer l’incrément du produit et réaliser l’objectif du Sprint.

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.

Backlog Refinement

Le Backlog Refinement regroupe l’équipe Scrum pour détailler les éléments du Product Backlog (ajout de détails, estimations ou ordonnancement). Les éléments sont revisités ou révisés. Cette activité ne devrait pas occuper plus de 10% de la capacité de DT.

L’incrément

L’Incrément est la somme de tous les items du Product Backlog réalisés 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”, ce qui signifie qu’il doit être publiable par le Product Owner qu’il décide d’une livraison en production ou non.

L’Incrément est un pas vers une vision ou un but.

La définition de fini (Definition of done ou DOD) permet d’avoir une transparence totale sur ce qui a été fait à la fin de chaque Sprint. Elle 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”. Il n’y a plus d’activité sur cette story à prévoir.

En conclusion

Scrum en un coup d’oeil

Voilà un article qui se veut complet mais pas trop pour ne pas perdre le lecteur. D’autres articles viendront présenter plus en détails des points précis de cette méthodologie.

Cet article se base principalement sur Le Guide Scrum (The Scrum Guide) dont vous pouvez télécharger la version complète ici : https://www.scrumguides.org/index.html