Le framework Scrum — Deuxième édition

Ce chapitre conserve le contexte historique et pratique des enseignements de la deuxième édition. Le programme de la troisième édition est également disponible dans le sommaire ci-dessous.

---

Exemple Scrum : un cas concret pour les équipes agiles performantes

Dans cet article, nous souhaitons vous présenter un exemple de méthode Scrum qui pourrait inspirer vos équipes Scrum, les autres parties prenantes de votre entreprise et les personnes concernées par vos projets. Nous avons vu de nombreuses entreprises former des professionnels Scrum qui, faute d’expérience pratique, rencontrent ensuite des difficultés dans leurs activités Scrum quotidiennes et dans la réalisation de leurs produits.

Ce problème empêche généralement les équipes Scrum d’atteindre leur vélocité optimale et de livrer leurs résultats dans les délais et le budget prévus. C’est là tout l’intérêt de cet exemple de méthode Scrum.

Dans ce court article, nous allons donc vous aider à avoir une vue d’ensemble du framework Scrum : de la mise en place de vos processus Scrum, qui créent une valeur sans précédent pour les entreprises, les produits et les services et offrent à vos clients une expérience d’agilité approfondie, jusqu’à la configuration et à l’utilisation de votre burndown chart Scrum pour améliorer et maintenir la vélocité de vos équipes Scrum.

Cet exemple de méthode Scrum vous aidera à comprendre le fonctionnement d’une équipe Scrum et les avantages qu’elle peut apporter à votre organisation. Les données suggèrent que, dans la plupart des entreprises, les équipes Scrum comprennent généralement un Product Owner, un Scrum Master et des développeurs, qui forment ensemble la Scrum Team. Ils travaillent par courtes itérations appelées Sprints pour livrer des Incréments de produit apportant de la valeur. Cette démarche itérative favorise la souplesse, l’adaptabilité et un retour d’information plus rapide.

Voici les principaux protagonistes de cet exemple de méthode Scrum :

• Alex, le Scrum Product Owner.
• Frank, le Scrum Master.
• La Scrum Team.

Avant de commencer le premier Sprint

Alex est nommé Scrum Product Owner d’un nouveau projet de développement logiciel. L’une de ses premières tâches consiste à commencer l’ingénierie des exigences. Il consigne les cas d’utilisation les plus importants et en discute avec les architectes, les représentants du client et les autres parties prenantes. Après avoir recueilli les cas d’utilisation et les exigences de haut niveau, il les inscrit dans le Scrum Product Backlog et organise une séance d’estimation et de priorisation avec les architectes et quelques développeurs expérimentés. À l’issue de cette séance, tous les éléments du Scrum Product Backlog disposent d’une première estimation approximative et d’une priorité. Il commence alors à décomposer les exigences de haut niveau en user stories plus détaillées. Avec cette liste, il convoque ensuite la première réunion de Sprint Planning.

Introduction à Scrum – Un cas concret à travers les différentes phases et les Sprints de Scrum

Sprint 1 - Jour 0

Pendant la réunion de Sprint Planning, Alex présente les éléments du Scrum Product Backlog par ordre de priorité décroissante. L’équipe clarifie les questions en suspens et examine, pour chaque élément, si elle dispose d’une capacité suffisante, des compétences nécessaires et de tous les autres moyens requis. Après cette discussion, elle s’engage à terminer les stories 1, 2, 3, 6, 7 et 8 avant la fin de ce Sprint. Les éléments 4 et 5 ne peuvent pas être réalisés pendant ce Sprint, car une partie de l’infrastructure technique n’est pas encore en place.

Après la réunion de Sprint Planning, Frank, le Scrum Master de l’équipe, réunit celle-ci pour préciser comment les éléments retenus seront réalisés. Les tâches qui en résultent sont inscrites sur les cartes du tableau des tâches du Sprint préparé à cet effet. Chaque membre de la Scrum Team choisit alors une tâche sur laquelle travailler.

Conseil de pro pour les équipes Scrum :

Alex, qui assume le rôle de Scrum Product Owner, conduit un nouveau projet de développement logiciel au sein de son organisation. Son rôle ressemble à celui d’un chef d’orchestre, où chacun joue sa partition. Sa fonction transversale implique d’importantes responsabilités et vise à créer des cadres de développement logiciel agiles et auto-organisés dans lesquels l’amélioration est un processus continu. Ce cadre n’est pas une solution universelle, mais un itinéraire tracé pour guider les développeurs dans leur travail. Alex donne le rythme de l’entreprise en veillant à ce que les produits réalisés correspondent aux besoins des clients. Une telle démarche agile procède par itérations continues et favorise ainsi le perfectionnement constant des produits et des méthodes.

Alex lance ensuite une séance d’estimation et de priorisation à partir des user stories (pour en savoir plus, consultez Les user stories Scrum) et des story points, utilisés comme technique d’estimation relative. Une visualisation de type Kanban peut compléter ce travail en rendant les tâches et le flux de travail visibles pour toute l’équipe. Tous les éléments du Scrum Product Backlog reçoivent ainsi une première estimation et une priorité. Alex s’appuie sur son expérience en gestion de projet pour décomposer les exigences de haut niveau en stories centrées sur l’utilisateur, transformant efficacement ces exigences en ensembles livrables. Ces user stories, exemples concrets de ce que souhaitent les clients, illustrent les chemins permettant d’atteindre les objectifs du projet. Muni de cette liste, il réunit la première séance de Sprint Planning et encourage une culture de collaboration étroite au sein de l’équipe de développement logiciel.

Sprint 1 - Jour 1

Le matin, toute l’équipe se réunit pour son Daily Scrum. Chacun explique brièvement ce qui a été accompli, actualise l’estimation des heures restantes sur les cartes du tableau des tâches du Sprint, présente ce qu’il prévoit de faire aujourd’hui et signale les éventuels obstacles qui freinent sa progression. Ce jour-là, un membre de l’équipe explique qu’il rencontre un problème : il a besoin d’une nouvelle licence pour l’un des outils logiciels qu’il utilise. Frank vérifie si d’autres membres rencontrent le même problème et annonce qu’il s’en occupera après la réunion. Au bout de 15 minutes, chacun reprend son travail.

Après la réunion, Frank actualise le Sprint Burndown. Il appelle ensuite l’éditeur de l’outil, commande les licences et les transmet aux personnes qui en ont besoin.

Conseil de pro pour les équipes Scrum :

Pendant le Sprint Planning, Alex présente les éléments du Scrum Product Backlog classés par priorité. Il lui revient, au sein de son organisation, de s’assurer que chacun comprend l’objectif global du projet. Les réunions debout de l’équipe favorisent des échanges ouverts qui clarifient les rôles et permettent de résoudre les problèmes potentiels.

Frank, le Scrum Master, joue lui aussi un rôle essentiel dans cette équipe aux profils variés. Il accompagne chaque réunion quotidienne et aide, si nécessaire, à recentrer les échanges sur l’Objectif de Sprint. Les développeurs sont responsables de leur plan et choisissent leurs tâches ensemble ; Frank ne leur attribue pas leur travail.

Sprint 1 - Jour 2

Le matin, toute l’équipe se retrouve à nouveau pour son Daily Scrum. Dans l’après-midi, un membre de l’équipe Scrum s’interroge sur certains détails d’une user story. Il appelle Alex, le Scrum Product Owner, et discute avec lui des points à clarifier. Une fois qu’il sait quoi faire, il peut poursuivre son travail de réalisation.

Sprint 1 - Jour 28

C’est le dernier jour du premier Sprint et Frank, le Scrum Master, a invité l’équipe à la Sprint Review. L’équipe a préparé une machine sur laquelle est installée la version actuelle du logiciel. Alex, le Scrum Product Owner, s’installe devant la machine et vérifie si la réalisation répond à ses attentes et si les fonctionnalités sont documentées comme prévu. À la fin de la séance de revue, il conclut :

• Les stories 1, 2, 6 et 7 sont terminées comme prévu.
• La story 3 n’a pas pu être terminée à temps et n’a donc pas été présentée.
• La story 8 comporte des points qui nécessitent une refactorisation.

Dans l’après-midi, l’équipe se réunit pour la Sprint Retrospective et discute de ce qui s’est bien passé pendant le Sprint et de ce qui pourrait être amélioré. L’un des retours est que l’équipe estime ne pas suffisamment connaître l’architecture globale du système. Frank se charge d’inviter l’architecte système à en faire une présentation plus détaillée.

Exemple de méthode Scrum

Conseil de pro pour les équipes Scrum :

Au dernier jour du premier Sprint, Frank accompagne l’équipe pendant la Sprint Review. Leur collaboration constante aboutit à un prototype concret qui reflète l’engagement de l’équipe et le travail accompli.

Dans l’après-midi, l’équipe se retrouve pour la Sprint Retrospective. Les membres y échangent sur leurs progrès et reviennent sur les aspects à améliorer pour les prochains Sprints. Cette réunion est un élément essentiel de la démarche agile et apporte une valeur considérable à l’ensemble du projet.

Lors de la préparation du Sprint suivant, le rôle déterminant d’Alex en tant que Scrum Product Owner se manifeste à nouveau : il ajoute au Scrum Product Backlog de nouveaux éléments issus de ses récentes réunions avec les clients. Au démarrage du deuxième Sprint, les principes du travail d’équipe, de la transparence et d’une gestion de projet efficace continuent manifestement de faire avancer cette équipe guidée par l’information vers la réussite.

Sprint 2 - Jour 1

Alex, le Scrum Product Owner, ajoute de nouveaux éléments au Scrum Product Backlog à la suite de ses récentes réunions avec les clients. Il ajoute également des éléments pour la refactorisation de la story 8. Alex invite ensuite l’équipe à la réunion de Sprint Planning du Sprint 2. L’équipe discute des stories et s’engage à les réaliser avec l’accompagnement de Frank, le Scrum Master, puis le deuxième Sprint commence.

Conseil de pro pour les équipes Scrum :

Le deuxième Sprint met en pratique les apprentissages de l’équipe : le Product Backlog révisé reflète les retours des clients, le travail inachevé est réexaminé et la collaboration se poursuit autour du prochain Objectif de Sprint.

L’étude d’exemples et de cas pratiques Scrum est indispensable aux organisations qui souhaitent développer des équipes Scrum efficaces et performantes. L’analyse de situations réelles apporte des enseignements précieux sur les mises en œuvre réussies et permet, tout aussi utilement, de repérer les écueils courants à éviter. En tirant les leçons de ces exemples, les équipes peuvent progresser plus rapidement vers un haut niveau de performance, appliquer les bonnes pratiques, éviter les erreurs potentielles et obtenir des résultats rapides dans leur pratique de Scrum.

Restez à l’écoute : d’autres situations concrètes et études de cas viendront enrichir votre compréhension du framework Scrum et de ses applications pratiques.