Le framework Scrum : responsabilités, événements et artefacts

Scrum est le framework agile le plus utilisé, et aussi le plus mal décrit. Le document qui le définit fait environ treize pages, a été révisé pour la dernière fois en novembre 2020 et reste volontairement incomplet : il vous dit quels événements tenir, qui est responsable de quoi et ce qu'il faut inspecter, puis s'arrête là. Tout le reste (comment estimer, comment gérer les branches, s'il faut travailler en binôme, à quoi ressemble votre tableau) est délibérément laissé à l'équipe.

Ce minimalisme fait à la fois son utilité et ses difficultés. Parce que le framework est petit, il s'installe dans presque n'importe quelle organisation ; parce qu'il est petit, les organisations comblent les vides avec ce qu'elles faisaient déjà, et se retrouvent avec des réunions d'avancement hebdomadaires baptisées stand-ups et un plan projet baptisé backlog. Ce guide décrit ce que le framework spécifie réellement, puis déroule un sprint de bout en bout. Les guides consacrés au Scrum Master et au Product Owner approfondissent ces deux responsabilités, et celui sur les principes agiles couvre les valeurs que Scrum met en œuvre.

L'empirisme et les trois piliers

Scrum se présente comme fondé sur l'empirisme et le lean thinking. L'empirisme signifie que les décisions se prennent à partir de ce que l'on observe plutôt que de ce que l'on avait supposé, et il repose sur trois piliers que les événements ont pour rôle de servir.

Transparence. L'état du travail est visible et représenté honnêtement pour tous ceux qui en ont besoin. Un tableau qui affiche six éléments en cours alors que neuf sont réellement travaillés brise la transparence, et toute inspection qui s'appuie dessus aboutit à la mauvaise conclusion.

Inspection. L'avancement et les artefacts sont examinés assez souvent pour détecter les problèmes tant qu'ils coûtent encore peu. Chacun des cinq événements est un point d'inspection avec un objet défini.

Adaptation. Quand l'inspection révèle un écart, quelque chose change : le plan, le produit, le processus. Une inspection sans le pouvoir de s'adapter n'est que du théâtre.

Trois responsabilités

La révision de 2020 a supprimé la notion de « Development Team » comme sous-groupe et l'a remplacée par une seule Scrum Team, généralement de dix personnes ou moins, qui porte trois responsabilités. Ce sont des responsabilités, pas des intitulés de poste ; une même personne peut en porter une tout en faisant autre chose.

Product Owner. Responsable de maximiser la valeur du produit issu du travail de l'équipe. Cela signifie porter l'objectif de produit, ordonner le Product Backlog et rendre transparents le contenu et les priorités de ce backlog. Point essentiel : le Product Owner est une personne, pas un comité, et l'organisation doit respecter ses décisions pour que cette responsabilité ait un sens.

Scrum Master. Responsable de l'efficacité de l'équipe et de la bonne compréhension et mise en œuvre de Scrum, dans l'équipe comme dans l'organisation au sens large. C'est un rôle de leadership qui sert l'équipe au lieu de la diriger, et qui s'étend au-delà d'elle : accompagner les parties prenantes, lever les obstacles organisationnels, aider le Product Owner sur les techniques de gestion du backlog.

Developers. Toutes les personnes qui réalisent le travail de création d'un incrément utilisable, quelle que soit leur spécialité : développement, test, design, analyse, exploitation. Ils sont responsables d'établir le plan du sprint, d'ancrer la qualité en respectant la Definition of Done, d'adapter leur plan chaque jour et de se tenir mutuellement responsables en professionnels. L'équipe est pluridisciplinaire : elle dispose de toutes les compétences nécessaires pour passer d'un élément du backlog à un incrément sans dépendre de personnes extérieures.

Trois artefacts et leurs engagements

La révision de 2020 a associé un engagement à chaque artefact, afin que chacun dispose d'une référence à laquelle se mesurer au lieu d'être une liste sans fin.

L'objectif de produit donne une direction au backlog, de sorte que les décisions d'ordonnancement puissent se discuter par rapport à quelque chose. L'objectif de sprint est la raison d'être du sprint ; il est choisi lors du Sprint Planning et donne de la cohérence à des éléments qui ne seraient sinon que des tickets sans lien entre eux. La Definition of Done est le niveau de qualité exigé : un travail qui ne la respecte pas ne fait pas partie de l'incrément, ne peut pas être mis en production et ne peut pas être présenté comme terminé.

Une Definition of Done n'est utile que si elle est honnête et appliquée. Pour un service web, une version réaliste pourrait exiger que le code soit relu et mergé sur la branche principale, que les tests unitaires et d'intégration passent dans le pipeline, que la fonctionnalité soit derrière un feature flag ou déployée en préproduction, que le monitoring et les logs couvrent le nouveau chemin, que la documentation soit à jour et qu'aucun défaut connu de sévérité moyenne ou supérieure ne reste ouvert. Si « testé » figure dans la liste mais que les tests ont en réalité lieu deux sprints plus tard, la définition est une fiction et chaque incrément est surévalué. Le guide sur les fondamentaux du test détaille ce que contient un niveau de qualité défendable.

Cinq événements

Le sprint est le conteneur ; les quatre autres événements ont lieu à l'intérieur. Tous ont une durée limitée (time-box), tous sont des points d'inspection, et aucun n'est un compte rendu d'avancement destiné au management.

Les time-boxes se réduisent avec la durée du sprint : un sprint de deux semaines a droit à quatre heures de planning, deux heures de review et quatre-vingt-dix minutes de rétrospective au maximum. Ce sont des plafonds, pas des cibles.

Le Sprint Planning répond à trois questions. Pourquoi ce sprint a-t-il de la valeur ? Le Product Owner fait une proposition et l'équipe formule l'objectif de sprint. Que peut-on faire ? Les Developers sélectionnent les éléments qu'ils pensent pouvoir terminer selon la Definition of Done. Comment le faire ? Une décomposition suffisante pour que l'équipe se sente en confiance, généralement sous la forme d'un plan d'éléments de travail, même si le guide n'en impose pas le format.

Le Daily Scrum est une séance de travail de quinze minutes pendant laquelle les Developers inspectent la progression vers l'objectif de sprint et ajustent le plan de la journée. Le guide 2020 a délibérément supprimé les trois questions rituelles, parce qu'elles avaient transformé l'événement en un tour de table de comptes rendus individuels. Si personne ne modifie son plan à l'issue du Daily, l'événement ne remplit pas son rôle.

La Sprint Review est une séance de travail avec les parties prenantes, au cours de laquelle l'incrément est présenté et le groupe discute de la suite à la lumière de ce qu'il sait désormais. C'est une conversation sur le produit, pas une étape de validation formelle, et ce qui en ressort alimente directement l'ordonnancement du backlog.

La Sprint Retrospective clôt le sprint en examinant comment le travail s'est déroulé (processus, outils, interactions, Definition of Done) et en identifiant des améliorations. Le résultat est un petit nombre de changements concrets, idéalement un seul que l'équipe s'engage à essayer au sprint suivant. Les rétrospectives qui produisent une longue liste de griefs sans aucun changement sont la raison la plus fréquente pour laquelle une équipe finit par abandonner l'événement sans le dire.

Un sprint de bout en bout

Prenons un sprint de deux semaines pour une équipe qui construit un tableau de bord de paiements.

Le premier jour, l'équipe consacre trois heures au Sprint Planning. Le Product Owner explique que la prochaine étape la plus utile est de permettre aux utilisateurs de la finance de voir les écarts de règlement sans exporter vers un tableur, et l'équipe formule l'objectif de sprint : les utilisateurs de la finance peuvent identifier et expliquer un écart de règlement directement dans le tableau de bord. Elle sélectionne cinq éléments du backlog qui servent cet objectif et en écarte un sixième, un export de reporting : il a de la valeur mais n'a pas de rapport avec l'objectif, et l'inclure diluerait celui-ci.

Chaque matin, les Developers se retrouvent quinze minutes devant le tableau. Le quatrième jour, ils découvrent que le flux de règlements omet un code devise, ce qui rend un élément irréalisable tel qu'il est rédigé. Au lieu d'escalader, ils renégocient le jour même avec le Product Owner : l'élément est restreint aux comptes monodevise, ce qui sert toujours l'objectif. Le Sprint Backlog change ; l'objectif de sprint, non.

Le neuvième jour, un défaut urgent survient en production. L'équipe le corrige et retire du sprint l'élément de moindre valeur pour faire de la place. À la review du dixième jour, elle présente la vue des écarts, fonctionnelle, à deux utilisateurs de la finance, qui demandent aussitôt un filtre par contrepartie : une demande qui devient un nouvel élément du backlog plutôt qu'une modification du travail terminé. La rétrospective de l'après-midi fait ressortir que le code devise manquant a coûté une journée et demie, et l'équipe s'accorde sur un changement : les séances d'affinage incluront une vérification de cinq minutes du contrat de données amont réel avant qu'un élément soit considéré comme prêt.

Ce que Scrum ne dit délibérément pas

Scrum est un framework, pas une méthode, et ses omissions sont intentionnelles. Il ne dit rien de la manière d'estimer, de l'usage des story points, de la durée de l'affinage, de la gestion des branches et des merges, de l'aspect du tableau, du traitement des bugs, du nombre d'équipes pouvant partager un produit, ni d'aucune pratique technique. C'est aux équipes de les apporter, et ces choix comptent plus que le framework lui-même : une équipe qui suit toutes les règles du guide sans tests automatisés et avec un cycle de mise en production de deux mois ne livrera pas d'incrément utilisable à chaque sprint, quelle que soit la rigueur avec laquelle elle anime ses événements. Un pipeline de livraison est le prérequis pratique pour que l'incrément soit réellement livrable.

Le framework se veut aussi explicitement indivisible : le guide affirme que chaque élément de Scrum a une raison d'être, et qu'en retirer certains tout en gardant le nom produit quelque chose qui masque les problèmes au lieu de les révéler. En pratique, la plupart des organisations en retirent, ce qui ne pose pas de problème tant que chacun admet honnêtement que le résultat est un processus maison et non Scrum.

Points clés à retenir

• Le Scrum Guide actuel date de novembre 2020 et définit une équipe unique avec trois responsabilités, cinq événements, trois artefacts et trois engagements, rien de plus.
• Chaque artefact a son engagement : l'objectif de produit pour le Product Backlog, l'objectif de sprint pour le Sprint Backlog, la Definition of Done pour l'incrément.
• Le sprint est un conteneur ; les quatre autres événements sont des points d'inspection avec un objet défini et des time-boxes proportionnées à la durée du sprint.
• Le Sprint Backlog peut changer chaque jour, mais l'objectif de sprint reste fixe pendant le sprint ; seul le Product Owner peut annuler un sprint.
• Une Definition of Done non appliquée fait de chaque incrément une surévaluation, et aucune discipline de processus ne peut compenser cela.
• Scrum omet volontairement l'estimation, les pratiques d'ingénierie et l'outillage ; ce sont ces choix qui déterminent si le framework produit quelque chose d'utile.