Guide de démarrage Scrum

Florent Lothon

Temps de lecture estimé : 30 minutes

La méthode Scrum (« Scrum » signifie « Mêlée » en anglais), ou plus exactement le cadre de travail (framework) Scrum est de loin la méthode agile la plus utilisée dans le monde. Expérimentée en 1993, elle bénéficie aujourd’hui de nombreux retours d’expérience. Les conférences, communautés, formations, blogs, outils et ouvrages à son sujet ne manquent pas.

L’objectif de cet article est de vous aider à vous lancer dans la mise en oeuvre de Scrum. Il décrit le processus associé, ses étapes, réunions, rôles, etc. Dès que les limites de cet article seront atteintes, la lecture du Guide Scrum (20 pages, gratuit, complet et traduit en français) puis du livre « Scrum et XP depuis les tranchées » (160 pages, également gratuit, complet et traduit en français) est recommandée. Pour une meilleure compréhension de cet article, il est préférable d’avoir assimilé les principes Agile. Au besoin, je vous invite à lire la fiche pratique « Introduction aux méthodes Agile ».

Au sujet de Scrum

Parler d’une « méthode » concernant Scrum n’est pas ce qu’il y a de plus approprié. Scrum ne se considère pas comme une méthode mais comme un cadre de travail (framework). Une méthode dit généralement « comment » faire les choses. Scrum ne dit pas comment réussir son logiciel, comment surmonter les obstacles, comment développer, comment spécifier, etc. Il se contente d’offrir un cadre de gestion de projet agile (et c’est déjà beaucoup) : des rôles, un rythme itératif, des réunions précises et limitées dans le temps, des artefacts (product backlog, sprint backlog, graphique d’avancement) et des règles du jeu.

Au sein de ce cadre de travail, les acteurs ajustent empiriquement, au fil des itérations, leur propre méthode en fonction de leur contexte. On peut qualifier Scrum de simple, pragmatique, transparent et empirique. Scrum ne couvrant que les aspects de gestion de projet, c’est souvent la méthode eXtreme Programming (XP) qui vient compléter le vide laissé en matière de pratiques de développement. XP apporte ainsi les pratiques de programmation en binôme, de développement piloté par les tests (TDD ou Test Driven Development), intégration continue, etc. Ces dernières jouent un rôle capital pour relever le défi du développement incrémental. Le mouvement Software Craftsmanship est également là pour répondre à ces enjeux techniques.

NB : Sachez que eXtreme Programming couvre également efficacement les aspects de gestion de projet, faisant d’elle l’une des méthodes Agile les plus complète qui existe.

Utilisation de Scrum

Cadre Scrum

Processus Scrum (source des icônes des personnages : Mike Cohn)

Pré requis recommandés

  • Un grand mur libre et dégagé dans l’espace de travail de l’équipe.
  • Blocs de post-it et marqueurs.
  • L’ouvrage « Scrum et XP depuis les tranchées ».
  • Jeu de cartes ou logiciel de Planning Poker.

Les Rôles en bref

Scrum définit seulement 3 rôles :

  • Le Product Owner qui porte la vision du produit à réaliser et travaille en interaction avec les Développeurs. Il s’agit généralement d’un expert du domaine métier du projet.
  • Les Développeurs chargés de transformer les besoins exprimés par le Product Owner en fonctionnalités utilisables. Le terme "Développeur" est à prendre au sens le plus large (pas nécessairement cantonné au secteur du développement de logiciel).
  • Le Scrum Master qui doit maîtriser Scrum et s’assurer que ce dernier est correctement appliqué. Il a donc un rôle de coach à la fois auprès du Product Owner et auprès des Développeurs. Il doit donc faire preuve de pédagogie. Il est également chargé de s’assurer que l’équipe Scrum est pleinement productive. Généralement le candidat tout trouvé au rôle de Scrum Master est le chef de projet. Celui ci devra cependant renoncer au style de management « commander et contrôler » pour adopter un mode de management participatif.

Vision du produit et product backlog

La première étape consiste à formaliser la vision du produit (logiciel) que l’on souhaite réaliser. Cette vision décrit les principaux objectifs, jalons, utilisateurs visés. Elle contribuera à guider et fédérer les acteurs du projet. La suite consiste à établir la liste des exigences fonctionnelles et non fonctionnelles du produit. Chaque exigence est ensuite estimée par les Développeurs avec la technique de Planning Poker. A la lueur des estimations, la liste ainsi complétée et ordonnancée. Les exigences seront converties en fonctionnalités utilisables selon cet ordonnancement. Le principe étant de convertir en premier les exigences qui apportent le plus de valeur ajoutée (ou ROI) au commanditaire. Il s’agit donc de faire remonter les exigences fonctionnelles de la plus haute valeur ajoutée (ou dont le ROI est le plus élevé) en haut de la liste. Cette liste est appelée le Product Backlog. Le Product Backlog servira à piloter les Développeurs et pourra évoluer tout au long du projet. Le changement est non seulement autorisé mais encouragé afin de pouvoir éliminer les idées de départ qui s’avéreront mauvaises et de prendre en compte les nouvelles idées qui arriveront en cours de route. Cette activité de construction du Product Backlog est collaborative, elle implique le Product Owner et les Développeurs.

Et dans le cas d'un appel d'offre ?

Vous répondez à un appel d’offre pour la réalisation du logiciel de votre client ? Vous ne pouvez pas construire le Product Backlog avec lui ? Dans ce cas, vous pouvez partir du cahier des charges, extraire de ce dernier les exigences, les estimer (idéalement avec 3 Développeurs) et initialiser ainsi le Product Backlog. Vous pouvez également aller plus loin en proposant un premier ordonnancement.

Pondérer chaque exigence d’une valeur ajoutée n’est pas toujours évident pour une équipe métier (MOA) novice. Différentes techniques s’offrent à vous. Le fameux Planning Poker (voir paragraphe ci dessous) peut s’avérer utile pour déterminer collectivement les pondérations en « points » de valeur ajoutée. On peut également utiliser des échelles de valeur plus ou moins fine (exemple : « faible », « moyenne », « haute » ou encore les tailles de tee-shirt : XS, S, M, L, XL, XXL).

Estimations des exigences

L’ensemble des fonctionnalités de la liste doivent être estimées par les Développeurs afin de permettre les futurs engagements de cette dernière. Impliquant plusieurs développeurs, le Planning Poker permet de mettre à profit les expériences de chacun et de parvenir rapidement à une estimation optimale et objective. Avant ou pendant les estimations, le Product Owner pourra être sollicité afin de répondre aux questions des Développeurs. A ce stade, le besoin pourra être approfondi, mais sans aller trop loin (il s’agit simplement d’estimer le coût de chaque exigence). La conception détaillée se fera pendant les itérations (sprints).

Démarrage

Vous pouvez commencer par déterminer ensemble (Développeurs et Product Owner) la durée des itérations ou Sprints (4 semaines maximum). Cette durée devra être la même pour l’ensemble des sprints afin de maintenir un rythme régulier propice aux automatismes et pouvoir construire des indicateurs de pilotage fiables.

Un projet démarre généralement par les travaux préparatoires du projet tels que la construction du product backlog et de la vision du produit, initiation des acteurs à Scrum (sur un projet de développement logiciel, on peut étendre à la préparation des environnements, mise en place de l’intégration continue, définition de l’architecture générale du projet, etc.). Inutile de le faire durer trop longtemps cette phase, souvenez vous (cf. fiche pratique « introduction aux méthodes Agile »), l’idée est de se lancer sans élaborer au préalable un plan et une architecture millimétrés qui risqueraient de nous enfermer, de nous frustrer, voire de nous coûter cher à courts et longs termes. L’architecture doit être souple et émerger au fil des sprints.

Disparition de la notion de
"Sprint 0"

Il fut un temps où cette étape préparatoire ou étape de cadrage s'appelait le "Sprint 0" (y compris dans le guide officiel Scrum de l'époque). Etant entendu que ce sprint 0 pouvait avoir une durée différente des sprints "normaux" qui suivent. Malheureusement, beaucoup d'équipes ont trouvé en ce sprint 0 l'opportunité d'en faire une phase de "conception" et retombaient dans le piège de l'approche traditionnelle consistant à tout anticiper. Cette étape n'est absolument pas une phase de conception/planification détaillée. Vous voilà donc averti.

Réunion de planification de sprint

Durée maximum : 2 heures par semaine de sprint (autrement dit : 4 heures pour des sprints de 2 semaines).

Phase 1 : Le « Quoi »

Une fois que le Product Backlog est suffisamment complet et ordonnancé, on peut planifier un sprint. LeProduct Owner revoit alors avec les développeurs la vision du produit, la roadmap, le plan de livraison (jalons et deadline), l’objectif du sprint et le Product Backlog. Les développeurs vérifient les estimations, confirme qu’elles sont exactes et sélectionne en haut du Product Backlog les exigences qu’elle se sent capable de convertir en fonctionnalités utilisables d’ici la fin du sprint (il s’agit d’une prévision et non pas d’un engagement « contractuel »).

Phase 2 : Le « Comment »

Les développeurs font ensuite l’inventaire des tâches qui permettront de convertir les exigences sélectionnées en fonctionnalités utilisables d’ici la fin du sprint. Toutes les exigences n’ont pas nécessairement besoin d’être découpées en tâches. En cas de manque de temps, les Développeurs peuvent se contenter de découper celles qui seront réalisées au cours des premiers jours du sprint (elle découpera en cours de sprint les autres exigences). Ils doivent cependant aller suffisamment loin dans l’effort de conception pour pouvoir vérifier sa prévision. Si ils constatent après analyse des exigences sélectionnées, que leur prévision est erronée, ils peuvent réajuster avec le Product Owner la liste des exigences sélectionnées.

Les tâches de développement sont centralisées dans le Sprint Backlog et ajoutées au tableau des tâches physique (aussi appelé Kanban, même si Kanban veut dire bien plus). L’idéal est de parvenir à un découpage relativement fin (inférieur ou égal à une journée de travail).

Exemple de tableau des tâches

Exemple de tableau des tâches

Chacun peut personnaliser les colonnes de son tableau des tâches, ou code couleur des post-it. A titre d’exemple, voici la photo du tableau que nous avons utilisé sur l’un de nos premiers projets (au passage, voici le lien vers l'article dans lequel je décris le retour d'expérience associé et à la fin duquel vous trouverez une vidéo tournée sur le projet : Retour d'expérience d'un projet Agile SNCF). Les User Stories (une User Story représente une exigence, voir annexe pour plus de détails) sont les gros post-it larges (rose et orange), les sous tâches des User Stories sont en jaune, on trouve en bleu des tâches imprévues indépendantes. Au dessus du tableau figurent les obstacles courants, un graphique d’avancement appelé burdown chart ainsi qu’un calendrier géant avec les dates clefs et les congés de chacun. Sur la droite on trouve des maquettes d’IHM, des documents métier, etc. Cette réunion de planification est l’occasion de préciser ou rappeler à l’équipe la définition de « terminé » pour une user story ou exigence. Exemple de définition de « terminé » : code commité, testé unitairement, documenté, testé en intégration, revue par un pair, tests d’acceptation de la user story passants.

Photo d'un tableau des tâches

Photo d'un tableau des tâches

Sprint (4 semaines max)

Au cours du Sprint, l’équipe se concentre sur l’accomplissement des tâches du Sprint Backlog. En cas de retard (indiqué par le Burndown Chart), des exigences ou tâches seront retirées du Sprint Backlog en cours de route en essayant de préserver l’objectif du sprint (pour cela, il est conseillé d’ordonnancer les exigences au sein du sprint). Et inversement, si l’équipe avance plus vite que prévu, des exigences ou tâches y seront ajoutées. En accord avec le Product Owner dans les deux cas.

Les développements se font verticalement et non pas horizontalement par couche. Le but est de développer les fonctionnalités de bout en bout (de la conception aux tests) au fil de l’eau au cours du sprint. Autrement dit d’éviter un mini cycle en V au sein du sprint, voire de se retrouver avec une surcharge d’effort de test en fin de sprint. Les développeurs doivent donc éviter de trop paralléliser les exigences et encore moins les tâches de développement. Pour cela, le pair programming peut se révéler utile ainsi que la définition d’une limite maximum d’éléments au sein d’une colonne du tableau des tâches (voir notion de Work In Progress du Kanban). Si les Développeurs ne sont pas convaincue, le « jeu du prénom en mode multitâche » peut s’avérer utile.

Le tableau des tâches physique rempli de post-it est pratiquement indispensable. Il permet d’avoir une vision claire du travail à accomplir, en cours et terminé. Il peut également s’avérer précieux lors des réunions quotidiennes (voir § suivant), surtout si vous calculez à la main le « reste à faire » du Sprint afin de tracer le graphique d’avancement (voir plus loin le « Burndown Chart »). Le tableau facilite également l’affectation des tâches par l’équipe en ayant une vision d’ensemble du sprint en un coup d’œil. Inutile de se torturer à planifier à l’avance dans le détail l’activité de chaque développeur sur toute la durée du sprint. Il faut se détacher d’une approche prédictive et des diagrammes de Gantt et renoncer au style de management « commander et contrôler ». Ce sont les développeurs qui « tirent » les tâches et non pas le Scrum Master qui les affecte.

Pendant le sprint, les Développeurs assisteront le Product Owner dans ses activités d’affinage du Product Backlog. Cette assistance peut consister en des ateliers de conception anticipés, de priorisation ou d’estimation. Il faut compter environ 10% de la capacité à faire les Développeurs pour leurs activités.

Mêlée quotidienne ou « stand-up meeting »

Durée maximum : 15 minutes.

Cette réunion qui se fait debout (ça évite de s’éterniser) est très importante. Elle permet quotidiennement aux membres de l’équipe de se synchroniser, de remonter les obstacles rencontrés, de s’entraider, de vérifier l’avancement du sprint. Elle contribue également à faire naître l’esprit d’équipe. A condition bien entendu de ne pas transformer cette réunion de « synchronisation » en réunion de « reporting » vers le Scrum Master.

Chaque personne répond à 3 questions :

  • Qu'ai-je fait hier qui a aidé l'équipe à atteindre l'objectif Sprint ?
  • Que vais-je faire aujourd'hui pour aider l'équipe à atteindre l'objectif Sprint ?
  • Est ce que je vois des obstacles susceptibles de m'empêcher ou d'empêcher l'équipe d'atteindre l'objectif du Sprint ?
Photo d'une mêlée quotidienne

Photo d'une mêlée quotidienne

Le Scrum Master est ainsi immédiatement au courant des obstacles rencontrés, il doit impérativement les prioriser, les suivre et bien sûr s’efforcer de les lever au plus tôt afin de garder l’équipe pleinement concentrée et productive.

La mêlée quotidienne se déroule à lieu et heure fixes (devant le tableau des tâches physique de préférence) déterminés par les Développeurs. Au début le Scrum Master peut avoir à rappeler qu’il est l’heure de la mêlée et animer cette dernière en rappelant les 3 questions et évitant l’instruction des problèmes ou obstacles en séance afin de ne pas dépasser les 15 minutes imparties. L’objectif du Scrum Master consiste cependant à viser l’appropriation de la mêlée par les Développeurs.

Graphique d’avancement (Burndown Chart)

Pour connaître votre avancement, vous allez avoir besoin de tracer le Burndown Chart du sprint en cours. Ce graphique est simple, il s’agit du tracé de la charge de travail restante (généralement en heures) en fonction du temps (en jours). Pour tracer ce graphique, il suffit de mettre à jour (lors de chaque mêlée quotidienne par exemple) le sprint backlog (voir illustration). 

Exemple de Sprint Backlog

Exemple de Sprint Backlog

Vous pouvez également construire un indicateur d’avancement de Release à mettre à jour en fin de chaque sprint (voir outillage proposé via le bouton ci dessous).

Exemple de Burndown Chart de Sprint

Exemple de Burndown Chart de Sprint

Revue de Sprint

Durée maximum : 1 heure par semaine de sprint (autrement dit : 2 heures pour des sprints de 2 semaines).

Fréquence : A la fin de chaque sprint.

L’objectif de la revue de sprint est d’inspecter l’incrément produit au cours du sprint écoulé, faire un point sur l’avancement de la Release et adapter au besoin le plan et le Product Backlog. Les Développeurs présentent à tout acteur projet intéressé (à minima le Product Owner idéalement accompagné d’utilisateurs finaux) les nouvelles fonctionnalités développées au cours du sprint. Le Product Owner donne un feedback aux développeurs, il accepte ou refuse les fonctionnalités présentées.

Les Développeurs calculent leur vélocité en additionnant les points d’estimation associées aux fonctionnalités acceptées. Une fonctionnalité partiellement terminée ne rapportera aucun point car une telle fonctionnalité n’est pas utilisable. La vélocité ainsi calculée va permettre de mettre à jour le graphique d’avancement de Release et de vérifier l’avancement de cette dernière. C’est l’occasion de vérifier que le nombre de sprints de la Release demeure adapté ou non.

La livraison à la fin de chaque sprint n’est pas obligatoire.

Photo d'une revue de sprint

Photo d'une revue de sprint

Rétrospective de sprint

Durée maximum : 45 minutes par semaine de sprint (autrement dit : 1 heure 30 pour des sprints de 2 semaines).

Fréquence : A la fin de chaque sprint.

Cette réunion est généralement animée par le « Scrum Master » qui s’adresse à son équipe. Elle a pour but d’améliorer continuellement le processus de développement de l’équipe en mettant les idées de chacun à contribution. Il existe différentes techniques d’animation de rétrospectives. Voir le livre « Agile Retrospective: Making Good Teams Great » pour en savoir plus.

L’une d’elle consiste à identifier et pondérer les éléments positifs (éléments à cultiver ou source de motivation) du sprint écoulé, puis les éléments à améliorer, puis de définir un plan d’action d’amélioration (en commençant par améliorer les éléments dont la pondération est la plus forte). Si les membres de l’équipe sont à l’aise pour s’exprimer, un simple tour de table permet de remplir le paper-board d’éléments. Dans le cas contraire, on peut avoir recours aux post-it (chacun se voit remettre des post-it vierges et un marqueur et inscrit ses idées dessus pour ensuite les transmettre à l’animateur. Une idée par post-it.). Pour pondérer les éléments, il suffit d’allouer un certain nombre de points (5 par exemple) à chaque membre. Chaque membre peut ventiler ses points à sa guise (exemple : 4 points sur un sujet qu’il considère très important, 1 point sur un autre sujet également important à ses yeux mais quatre fois moins que le premier). Pendant la phase d’inventaire des éléments à améliorer, veillez à ne pas essayer de trouver des solutions avant la phase dédiée au plan d’action d’amélioration. Vous risqueriez de ne pas faire remonter à la surface la majorité des « problèmes ». Ce serait dommage car, j’ai pu constater que parfois, le simple fait d’évoquer un problème sans forcément avoir le temps de trouver une solution entraîne une amélioration au sprint suivant.

Commencer par les points positifs peut être vital lorsque le sprint a été éprouvant. L’équipe aura peut être besoin de se nourrir des éléments positifs avant de s’attaquer aux éléments à améliorer.

Tous les domaines peuvent être abordés en rétrospective : humain, organisationnel, pratiques, processus, outillage, qualité de vie au travail, conflits, interactions avec le métier. Le compte rendu de la dernière rétrospective, les graphiques d’avancement de sprint et release, les événements du sprint, les feedbacks de la revue de sprint sont autant d’éléments qui alimentent les conversations.

Photo d'une rétrospective de sprint

Photo d'une rétrospective de sprint

Projet Scrum et MOA

Il est important de prendre conscience que les méthodes Agile ne considèrent pas à juste titre de séparation MOA MOE contractuelle (typiquement française empruntée au secteur du BTP). Il est donc primordial de s’efforcer de décloisonner au maximum MOA et MOE, ces deux entités doivent collaborer étroitement tout au long du projet. Etant donné que l’on touche ici à des habitudes bien ancrées, ce chapitre explique quel rôle peut jouer la MOA dans un projet Agile.

Le rôle du consultant métier

Dans le cadre d’une approche Agile, les tâches d’un profil fonctionnel peuvent rester les même que dans le cadre d’une approche traditionnelle :

  • Participation au reengineering des processus et à la conduite du changement.
  • Modélisation des processus métier.
  • Participation aux ateliers de conception.
  • Rédaction des tests d’acceptation (en amont des développements).
  • Vérification de la conformité des fonctionnalités (en aval des développements).

Le changement réside dans l’organisation du travail. L’approche séquentielle propice à l’effet tunnel est remplacée par un mode itératif, le travail est donc lissé dans le temps sur toute la durée du projet. De plus, un responsable métier devra jouer le rôle clairement défini de « product owner ».

Rôle du Product Owner

Le Product Owner (ou Directeur/Responsable Produit) est chargé de :

  • Construire le Product Backlog.
  • Ordonnancer ces dernières en fonction de leur importance métier.
  • Répondre aux questions des Développeurs.
  • Valider/Rejeter une fonctionnalité « terminée ».
  • Prendre des décisions importantes en temps voulu.

Les Développeurs s’engagent à rester concentrés sur l'objectif de sprint et faire une démonstration à la fin de chaque sprint le produit enrichi de nouvelles fonctionnalités. A la fin de chaque sprint, le Product Owner peut :

  • Ajouter une exigence manquante.
  • Retirer une exigence finalement inutile.
  • Redéfinir la priorité des exigences.

Renfort du Product Owner

Le Scrum Master enseigne au besoin au Product Owner les règles du jeu de Scrum et la maîtrise des techniques associées. En particulier celles qui tournent autour de la gestion de Product Backlog, la planification de releases et l’utilisation des indicateurs de pilotage. Il facilitera également les interactions entre le Product Owner et les Développeurs. Les Développeurs l’aident quant à eux à ordonnancer le Product Backlog en fonction des dépendances, risques et estimation qu’elle révèle. Enfin, une équipe de consultants métier peut l’aider sur :

  • Les réponses à apporter aux questions des Développeurs tout au long du projet.
  • La prise de décisions.
  • La rédaction des tests d’acceptation.
  • L’ordonnancement du Product Backlog.
  • La fourniture des feedbacks à la fin de chaque sprint.
  • D’autres sujets : logistique, conduite du changement, déploiement, etc.

Par ailleurs, il est recommandé de solliciter quelques utilisateurs finaux représentatifs des utilisateurs visés par le produit afin de vérifier pas à pas (à minima en revue de chaque sprint) la bonne couverture de leur besoin.

Les pièges à éviter

Scrum est simple mais difficile

Nous l’avons vu, Scrum est un cadre de gestion de projet qui laisse à d’autres méthodes agilecomplémentaires, le soin d’apporter les pratiques de développement appropriées. C’est le cas de eXtreme Programming et software craftsmanship. Il est donc primordial de ne pas se contenter d’utiliser Scrum sans s’assurer que les pratiques de développement Agile sont ou seront maîtrisées in fine. Constatant de nombreuses dérives liées à cette erreur courante, les créateurs de Scrum alertent :

« Début 2009, davantage d’organisations utilisaient des processus agiles plutôt que des processus en cascade. Cependant, moins de 50% de celles utilisant Scrum développaient les itérations de façon incrémentale, ce qui est le cœur de Scrum. Un des plus grands défis de l’utilisation de Scrum a toujours été la courbe d’apprentissage des développeurs de l’équipe Scrum. »

Gestion du changement

Selon la culture de votre organisation, Scrum peut être porteur de nombreux changements qui impliquent une véritable gestion du changement Agile.

Plusieurs équipes Scrum

Idéalement, pour être efficace, une équipe Scrum ne devrait pas dépasser 10 membres en comptant le Scrum Master et le Product Owner. Si votre projet nécessite plusieurs équipes, évitez dans la mesure du possible de constituer des équipes spécialisées par compétence (exemple : une équipe qui développe les IHM et une autre les services métier et l’accès à la base de données). Constituez des équipes pluridisciplinaires capables de développer intégralement une fonctionnalité (donc de coder toutes les couches). Comprenons nous bien, le principe n’est pas que chaque membre d’une équipe dispose de toutes le compétences mais plutôt que toutes les compétences requises soient couvertes par au moins un membre de l’équipe. De cette façon, chaque équipe peut avancer de façon autonome sans dépendre étroitement d’une autre, la coordination est plus simple. Chacune étant spécialisé sur un ou des domaines fonctionnels plutôt que technologiques. L’intégration du code de l’ensemble des équipes sera également plus facile.

Il y aurait davantage à dire sur l’utilisation de Scrum à grande échelle mais nous dépassons l’objectif de ce guide de démarrage.

Annexes

Caractéristiques d’une User Story

Une fonctionnalité peut être rédigée selon le principe de la « User Story » défini par la méthode Agile eXtreme Programming (XP). Une « User Story » doit être :

  • Courte : généralement une ou trois phrases environ.
  • Négociable : elle peut être discutée avec l’équipe chargée de la réalisation du produit, notamment lors de l’estimation.
  • Source de valeur : elle doit être porteuse d’une valeur pour le client ou l’utilisateur.
  • Indépendante des autres histoires d’utilisateur (dans la mesure du possible).
  • Estimable : elle peut être estimée par l’équipe de réalisation avec un risque d’erreur faible.
  • D’une taille appropriée : sa taille doit être relativement petite afin de faciliter son estimation. Elle doit pouvoir être conçue, développée et testée au sein d’une itération.
Exemple de User Story

Exemple de User Story (simpliste pour l’exemple)

Quid des spécifications ?

La conception fonctionnelle voire technique d’une fonctionnalité se fait au fil de l’eau dans chaque itération. Ce n’est qu’au moment où on s’apprête à l’implémenter qu’on rentre dans les détails du besoin (pour rappel, le besoin lié à cette fonctionnalité à été abordé dans les grandes lignes lors de la phase amont d’estimation). Cette approche a le mérite de permettre au client d’ajuster ou approfondir son besoin sur les fonctionnalités implémentées plus tard. Elle lui permet aussi (ainsi qu’à l’équipe) de retarder certaines décisions sans risque pour le projet (c’est souvent plus sage quand on manque de visibilité).

La méthode Agile eXtreme Programming considère que les User Stories, les tests associés et le code source constituent les spécifications fonctionnelles du projet. D’autres méthodes vont plutôt préconiser la rédaction de cas d’utilisation avec un niveau de détail variable selon le contexte du projet, les exigences du client et la complexité de la fonctionnalité à spécifier.

Il faut bien comprendre que rédiger des spécifications ultra détaillées n’a de sens que dans une approche traditionnelle. Car dans ce cas de figure, le client ne verra son produit qu’à la fin des développements. Il doit donc avoir une vision précise de ce qu’il aura en fin de projet grâce aux spécifications détaillées. Or l’approche Agile apporte au client une visibilité sur le produit dès le début du projet ainsi qu’une possibilité d’ajustement du besoin. On privilégie donc le développement de l’application à une documentation exhaustive et pléthorique (d’ailleurs souvent indigeste pour le client qui tarde à valider et retarde ainsi son propre projet. Ou pire, valide sans vraiment lire et analyser).

Pour la partie technique on peut souvent se limiter à un dossier d’architecture, un modèle conceptuel de données (voir physique) émergeant, aux commentaires du code (Javadoc) et à une spécification détaillant les modules éventuellement complexes pour faciliter la maintenance du produit par la suite.

En appliquant ce principe, on assiste généralement à un gain de productivité par rapport à une approche traditionnelle, puisqu’on ne perd pas un temps considérable en rédaction, validation puis mises à jour de spécifications détaillées. Il est sans doute bon de préciser également que l’on ne néglige pas la conception du produit pour autant. La conception fait partie des tâches sous-jacentes à la réalisation d’une fonctionnalité.

Vous souhaitez aller plus loin ?

Vous pouvez poursuivre votre apprentissage en consultant la page des ressources clés.

Et vous pouvez faire le choix d’être formé par nos soins. Découvrez nos parcours de formation sur cette page et prenez un RDV téléphonique avec nous pour en discuter ensemble.

A propos de l'auteur

Florent Lothon

Expert de terrain en gestion de projet et management d'équipe. Florent fait partie des pionniers dans l'usage des méthodes agiles sur des projets à forts enjeux en France dès 2007. Co-auteur du livre "Devenir une Entreprise Agile".

  • sylvie marchand dit :

    j’ai trouvé cela intéressant

  • Radhouane GOURCHENE dit :

    Un article intéressant et aborde presque toutes les phases d’un projet dès son démarrage.
    Cependant, à plusieurs reprises, on sent une nostalgie du cycle en V. Par exemple le découpage des « exigences » en sous tâches (User-Stories) style ‘IHM’ et ‘service métier’ se rapproche plus du cycle en V que de l’agile.
    Ce découpage n’est as I.N.V.E.ST. En effet, la couche IHM toute seule sans service ne peut avoir de la valeur pour le PO ni le métier.

    • Bonjour Radhouane et merci pour ton observation.

      En réalité, dans cet article, je précise bien qu’une exigence est considérée comme synonyme de User Story. Or le découpage INVEST s’applique aux User Stories en soi comme tu le précises bien. Donc aux exigences en soi. Et non pas à leurs sous-tâches.

      Amicalement
      Florent

  • Bonjour Florent,

    merci pour cette belle et claire introduction au principe Scrum.

    A la recherche de nouvelles méthodologies pour bousculer les habitudes et surtout apprendre à être plus efficace dans le développement des projets de mes équipes, j’espère pouvoir en tirer partie, je crois beaucoup en cette façon de faire.

    Reste à voir si ceci s’applique aussi bien pour la R&D de l’industrie !

    Au plaisir de vous lire de nouveau.

    Marc.

    • Bonjour Marc et merci pour ce retour.

      Scrum a l’énorme avantage de n’être qu’un cadre méthodologique, et léger avec ça (le guide officiel Scrum ne fait que 19 pages). Il est donc applicable et appliqué à d’autres domaines que celui de l’informatique et des projets de développement logiciel.

      Bonnes expérimentations à toi
      Florent

  • Merci pour ce résumé très clair, cela m’a permis de me rafraîchir la mémoire après avoir passé 5 années à faire du « scrum » tellement arrangé que cela n’en n’avait plus que le nom.

  • Bérenger GERMAIN dit :

    Un très bon article, qui permet de dépoussiérer les fondamentaux quelques peu érodés avec le temps. Merci 🙂

    Mais comme à chaque article/livre que je lis sur SCRUM, je manque d’info et/ou de retour sur la façon de le mettre en œuvre dans un contexte mono-équipe et multi-clients (multi-projet). Je suis pourtant sûr de ne pas être le seul dans ce cas là :p

    Actuellement mes problématiques se concentrent autour de la mise en place d’un cadre de contractualisation convenable avec un client qui ne maîtrise pas du tout SCRUM.

    Comment contractualiser une prestation SCRUM sans mettre la liste des fonctionnalités attendus sur un devis traditionnel.

    Ou bien, comment « faire passer la pilule » et insuffler la confiance pour mettre en place une facturation au sprint ?

    Auriez-vous quelques références sur ce sujet ? Existe-t-il un SPOC qui aborde cette thématique ?

    Bonne continuation et au plaisir d’échanger avec vous 🙂

    • Bonjour Bérenger et merci pour vos compliments sur l’article 😉

      Je vois 2 questions : « comment utiliser Scrum avec une seule équipe gérant plusieurs projets » et « comment contractualiser un projet agile dans le cadre d’une relation Client/Fournisseur ».

      Pour la première, la réponse la plus sage (et la plus facile, il faut bien le dire :-)), en tant que coach agile est « tout dépend du contexte ». Ce qui est sûr c’est qu’il faut voir Scrum pour ce qu’il est : un simple cadre méthodologique et non une méthode. A chacun d’y insérer les bonnes pratiques, outils, processus qui correspondent au contexte. Cependant dans le cas d’une équipe multi projets (de moins de 10 personnes), j’ai tendance à plutôt utiliser la méthode Kanban. Egalement pas mal adaptée à du « RUN » (maintenance d’applications). Ce n’est qu’une piste à soumettre à votre sens critique selon votre contexte.

      Pour la seconde question, les solutions de contractualisation agile ne manquent pas. On peut par exemple forfaitiser un Sprint 0 de cadrage, voire même les 2 ou 3 suivants pour étalonner la vélocité puis s’engager au forfait pour la suite (sur un volume de Story Points par exemple avec un simple principe de troc pour l’ouverture aux changements, la souplesse qu’un client peut légitimement attendre d’une démarche agile).

      J’aborde la notion de troc dans mes formations. Dans le format SPOC, ça fait partie des sujets pouvant être approfondis au cours des sessions live hebdo ou discussions partagées sur le forum de la formation.

      J’espère que cette réponse vous sera utile.

      Amicalement,
      Florent

  • Bonjour,

    Merci pour ce très bon article pour la découverte de cette méthode.
    Nous avons adopté l’agilité depuis peu dans l’équipe et je dois avouer que cela a rapidement créé une bonne dynamique de groupe et une « compréhension » entre les différents intervenants (graphique, design, équipe de développement ET le client) a naturellement pris place dans nos réunions.

    Quid du client difficile justement : celui qui ne teste pas, qui ne communique pas (hormis quelques « rien ne marche »), qui revient toujours sur ces décisions, celui qu’on pensait être agile et qui ne l’est pas du tout ?

    Amicalement,

    Michael

    • Bonjour Michael,
      Merci pour les feedbacks à propos de l’article 😉
      Et ravi de voir que l’agilité porte déjà ses fruits dans ton équipe.

      D’abord, il faut bien se dire que toutes les conditions idéales de mise en oeuvre de l’agilité sont rarement réunies. L’implication du Client et son appropriation du rôle de Product Owner (aussi bien l’état d’esprit que les pratiques) est souvent un point d’achoppement. D’où la posture de Coach du Scrum Master pour former et accompagner la personne côté client qui incarnera le rôle de Product Owner. La personne devra comprendre ce que ce rôle peut lui apporter aussi bien que les responsabilités associées. D’où l’importance d’avoir un bon Scrum Master, bien formé, avec les bonnes qualités en terme de pédagogie, patience & détermination et communication. Si ces efforts ne payent pas, il reste le recours à un coach agile pour poser le cadre et les règles du jeu, avec un accompagnement sur 3 sprints minimum (c’est ma recommandation en tout cas). Enfin, dernier recours si ça n’a pas déjà été fait avant (c’est mieux de le prévoir avant) : le sponsor. Une personne suffisamment haut placée pour dire : ok l’agilité peut nous apporter des bénéfices absolument indispensables à la réussite de nos projets, donc on se forme et on joue le jeu avec mon soutien : le droit à l’erreur (nécessaire pour tout changement de façon de travailler et pour l’amélioration continue) et si nécessaire un budget formation & coaching agile.

      Est ce que ça répond à ta question Michael ?

      Amicalement,
      Florent

  • Bonjour,

    Très intéressant et très didactique. Je me permettrait juste une petite remarque (dans un but d’échanger et non de critiquer bien entendu). Vous parlez de ROI au début lorsque vous abordez le classement des fonctionnalités, vous expliquez que l’on classe les fonctionnalités pour avoir le ROI le plus important pour le client. Hors, pour moi le plus important pour le client c’est la business value. Le ROI n’est que le résultat du calcul entre la BV et l’effort et qui permettra une priorisation des fonctionnalités dans le sprint. Je sais j’ergote mais le sujet est intéressant. ;o)
    Félicitation encore une fois pour ce très bon article

  • Sawâné dit :

    Bonjour,

    Excellent article : clarté, pédagogie ! En novice, j’ai passé la nuit et la matinée à lire et à relire…
    Merci pour la générosité de partage et félicitations pour votre brillant parcours.

  • ALPHA BAH dit :

    Bonsoir M. Florent Lothon,

    J’ai suivais aujourd’hui un cours sur agile scrum, j’avoue que votre article est vraiment pertinent.

    Vous avez résumé les milliers de slides qui m’ont totalement endormi en formation.

    Franchement félicitations.

    merci

  • Clémence dit :

    Excellent article. Super didactique autant par son contenu que par les commentaires. Merci!

  • Article très intéressant.
    Juste une réserve sur la Doc, vous semblez oublier des « Personnas » dans les user stories des Documents de spécification de besoins et techniques :
    – L’infogérance des solutions
    – Les acteurs de contrat de TMA

  • Que répondre à un développeur qui prétend que le chiffrage en j/h d’un projet est illusoire, car la méthode SCRUM suppose une adaptation au fil de l’eau et donc potentiellement un réajustement de la charge également au fil de l’eau ?
    Merci

    • En effet, sur un projet Scrum on estime (on ne chiffre pas) en unités d’oeuvre appelés des « Story Points » (ou points tout courts). Les j/h ont tendance à entretenir l’illusion qu’une estimation peut être fiable. Hors une estimation reste une estimation (fausse par définition). Ce qui n’empêche pas de s’engager sur un budget, un délai, un volume de points, la qualité et d’être aussi précis que possible grâce à l’intelligence collective mise à profit lors des séances d’estimation (avec la technique du Planning Poker).

      Et au bout de plusieurs itérations, l’équipe sait concrètement quelle quantité de points elle peut embarquer en moyenne à chaque itération/sprint. Là les projections deviennent bien plus fiables qu’avec de savants calculs théoriques. Autre avantage pour le « client », les estimations données sont faites sur chaque élément individuellement, en toute transparence et en collaboration avec lui. Autrement dit, en découvrant une première estimation, il a l’opportunité de simplifier son besoin pour la faire baisser avant même d’engager les travaux en conception détaillée puis réal, test, etc.

      Bien sûr il faudrait aller plus loin dans l’explication et je pourrais notamment parler de la façon dont j’ai pu engager des projets agiles dans le cadre de contrats au forfait avec succès. Mais ce n’est pas vraiment le lieu.

  • Bonjour, merci pour votre article qui permet de comprendre simplement les concepts clés.

    Pour autant, j’aimerai avoir votre point de vue sur une notion qui reste compliquée car il y a de nombreux avis contradictoire.

    Bien que relisant votre article, j’ai un avis tranché sur la réponse mais je me permets de vous poser ces questions avec un contexte en préambule :
    – Il s’agit d’un produit informatique (en mode agil, quelle différence pour un cycle en v) orienté relation client qui sera verticalisé avec des maj régulières
    – D’après vous, qui a la charge de faire respecter la philosophie du produit tout au long de son cycle de vie ? Des solutions possibles le PO, l’architecte fonctionnel, le MAO, le chef de projet, les développeurs, le commerce ou autres
    – Quel est le RACI que vous préconisez avec les fonctions suivantes : Avant-vente, PO, l’architecte fonctionnel, Scrum Master, le MAO, le chef de projet, les développeurs, le commerce ou autres

    Je reste à votre disposition,
    cordialement

    • Bonjour Pitchs 🙂

      Celui qui a la charge de gérer et partager la vision produit/utilisateur est le Product Owner. Ce qui ne signifie pas qu’il est seul pour autant. Il peut être influencé par la direction de l’entreprise et la stratégie de cette dernière, les éventuels sponsors, les utilisateurs bien sûr et l’équipe de développement. Mais ça reste sa responsabilité opérationnelle.

      Le RACI pour autant de rôles (si RACI il y a besoin) sera à définir en fonction du contexte, il n’y a pas de réponse unique.

      Pour les rôles définis par Scrum en revanche, c’est très clair et en résumé ça donne à peu près ça :
      – Product Owner responsable du « quoi » et de l’ordre dans lequel on fait les choses
      – Scrum Master responsable de la bonne compréhension et respect du cadre méthodologique Scrum (ce n’est ni un secrétaire comme je l’entends parfois ni un coordinateur)
      – Equipe de dev responsable de la réalisation du produit et de comment on le réalise

      Je réponds quand même sur le rôle « sensible » de chef de projet : ce rôle au sens strict perd alors de son sens puisque ce n’est pas lui qui est chargé du comment, du quoi, de l’ordre, ni de la planification. Il ne contrôle plus non plus les tâches ni leur estimation. Généralement (et ce fut mon cas), le chef de projet bascule dans le rôle de Scrum Master et garde une casquette de chef de projet à l’extérieur de l’équipe (exemple : pour le reporting budgétaire, le staffing, etc).

      Est-ce que ça répond à la question ?

  • Guillaume dit :

    Le manifeste agile dit :
    « Les individus et leurs interactions plus que les processus et les outils
    Des logiciels opérationnels plus qu’une documentation exhaustive
    La collaboration avec les clients plus que la négociation contractuelle
    L’adaptation au changement plus que le suivi d’un plan »

    Hors SCRUM met en oeuvre des processus et des outils, et un plan (au sens large).
    Peut-on alors continuer à dire que SCRUM est une méthode Agile ?

    • Merci pour votre message Guillaume.
      D’une part les créateurs de Scrum font parti des rédacteurs et des signataires du manifeste agile. D’autre part, à la première lecture trop rapide de ce manifeste, on a malheureusement tendance à voir les choses en noir et blanc en oubliant les nuances de gris ou autres couleurs. Le manifeste agile ne s’arrête pas là, il dit aussi « Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers. » Cette précision est essentielle à une bonne compréhension de l’état d’esprit agile. Enfin, Scrum est processus (plus exactement, c’est un cadre) qui est « inclusif » et non pas « prescriptif ». Ainsi, il permet de s’adapter au contexte projet de chacun et laisse la place aux pratiques, techniques et outils que l’équipe projet décidera d’adopter au sein de ce cadre.

  • Article intéressant et très complet. Pour ma part je suis convaincu par la méthodologie. Avec l’explosion du télétravail, j’ai voulu apporter ma pierre sur la partie qui me pose problème en distanciel, le planning poker. je partage maintenant cet outil. un planning poker en ligne simple et sans inscription. voici le lien https://planningpoker.fr j’esperes qu’il vous plaira pour ceux que ça concernera.

  • Bonjour

    merci pour cette page. Une des grandes questions qu'on me pose souvent est comment gérer les bugs lors de la revue de sprint?

    je parle de VRAIS bugs techniques de la part des devs.

    En principe selon la méthode, ils donnent lieu à de nouvelles tâches sans user points pour le sprint suivant.
    Mais la grande question est la FACTURATION: comment faire comprendre au client qu'au sprint suivant il payera x % pour corriger des bugs qu'on a fait.

    merci pour vos réponses
    Cyril

    • Bonjour Cyril,
      Tout d’abord, une bonne équipe agile limite considérablement les bugs grâce aux pratiques d’eXtreme Programming (pilotage des développements par les tests, intégration continue / tests automatisés, pair programming, etc). Par ailleurs, un processus agile permet de détecter ces défauts au plus tôt et on sait bien que plus un défaut est détecté tard (lors de la phase de recette en approche classique par exemple) plus il coûte cher.

      D’autre part, tout dépend de la contractualisation. J’imagine qu’on parle d’un engagement au « forfait » (délai, budget, volume d’unités d’oeuvre) ? Sur un projet classique, on prévoit toujours (par abaque généralement) une provision pour la résolution de bugs/support de recette. Rien n’interdit de procéder de la même façon lors de la détermination du budget.

      En espérant être clair,
      Florent

      • Merci Florent pour cette réponse très intéressante car elle ouvre plusieurs pistes de réflexions:

        1- l'eXterme Programming n'est que rarement mis en place en tous cas dans sa totalité. On est souvent amené à faire de l'agile avec une équipe de devs réduite (2 personnes ). donc les bugs arrivent 🙁

        2- en quoi un processus agile permet de détecter plus tôt les bugs ? La méthode permet surement de mieux définir ce qui a le plus de valeur pour le client et en réduisant les risques de 'surprise' pendant le dev mais encore une fois… les bugs arrivent

        3- non, je ne parle pas de forfait (qui est contraire à l'idée d'agile) mais de véritable contractualisation où le client paye au réel (temps passé). Dans ce cas, comment faire comprendre au client qu'au sprint suivant il payera x % pour corriger des bugs qu'on a fait au sprint précédent.

        merci pour vos réponses

        Cyril

        • De rien Cyril 😉
          1 – En effet, d’où pas mal d’écueils hélas (être 2 pour pratiquer l’essentiel d’XP ou équivalent est plutôt un atout qu’un handicap d’après mon expérience, idem pour limiter les bugs)
          2 – L’effet tunnel est considérablement réduit (principalement – mais pas seulement – par la durée/fréquence des itérations : 4 semaines max Versus X mois d’une phase de réalisation en Cycle en V sans compter la phase de conception)
          3 – L’engagement sur un délai, un budget, qualité et un volume d’unités d’oeuvre n’est pas du tout contraire à l’agilité fort heureusement. C’est même la majorité des projets que j’ai pu mener (en m’appuyant d’ailleurs sur des mécanismes simples prévus par les créateurs de Scrum en personne).

          C’est typiquement le genre de questions que nous abordons en détail en formation.
          Par écrit, c’est toujours plus compliqué de se comprendre et d’apporter une réponse précise, complète et adaptée au contexte.

          Amicalement,
          Florent

          • oui merci
            mais au final dans un sprint vous vous engagez sur un livrable et que se passe t il avec les bugs memes réduits ??
            le prestataire doit il les corriger et donc passer du temps non facturé avant de commencer un nouveau sprint ou ce temps de debut est il compris dans le sprint suivant (qui sera facturé) ?

          • Bonjour Cyril,
            C’est au Product Owner de décider si un bug doit être corrigé et à quel moment, au même titre que les autres éléments du Product Backlog.
            En termes de facturation, en régie le client peut arrêter la prestation à tout moment si il en marre de « payer » pour des bugs. Si le volume de bugs est tel que la confiance commence à se déliter, on en revient aux bonnes pratiques évoquées au début. Ce qui fera un bon sujet de discussion en rétrospective en s’assurant que le Product Owner est bien présent. Evidemment, c’est une réponse générale à adapter en fonction du contexte.

  • {"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

    Vous voulez d'autres contenus de qualité ?

    Découvrez ces articles

    >