Le Scrum Guide augmenté par l'IA

La Référence de Scrum : Les Règles du Jeu

Version Augmentée (et non retouchée) - Mars 2025

D'après l'œuvre originale de Ken Schwaber & Jeff Sutherland

Définition de Scrum

Scrum est un cadre léger qui aide les individus, les équipes et les organisations à générer de la valeur par des solutions adaptatives pour des problèmes complexes.

En résumé, Scrum nécessite un Scrum Master pour favoriser un environnement où :

1. Un Product Owner hiérarchise le travail pour un problème complexe dans un Product Backlog.
2. L'équipe Scrum transforme une sélection de ce travail en un Incrément de valeur pendant un Sprint.
3. L'équipe Scrum et ses parties prenantes inspectent les résultats et s'ajustent pour le Sprint suivant.
4. Ce cycle se répète.
   
   

Application contextuelle

Voyons comment cela s'applique concrètement dans différents contextes :

• En développement logiciel : Le Product Owner priorise les fonctionnalités dans le Product Backlog, l'équipe développe un logiciel fonctionnel pendant le Sprint, puis tous examinent la démonstration du logiciel et recueillent les commentaires avant de planifier le prochain Sprint.
• Dans le secteur de la santé : Le Product Owner (peut-être un responsable clinique) priorise les améliorations des processus de soins, l'équipe met en œuvre des changements spécifiques pendant une période définie, puis analyse les métriques des résultats patients pour ajuster l'approche.
• Dans l'éducation : Le Product Owner (peut-être un directeur pédagogique) priorise les initiatives d'apprentissage, les enseignants mettent en œuvre des méthodes pédagogiques spécifiques pendant un cycle, puis évaluent les résultats d'apprentissage pour affiner l'approche.

Scrum est simple. Essaye-je tel quel et déterminez si sa philosophie, sa théorie et sa structure vous aident à atteindre vos objectifs et à créer de la valeur. Le cadre Scrum est délibérément incomplet, définissant uniquement les éléments nécessaires pour mettre en œuvre la théorie Scrum. Scrum est construit sur l'intelligence collective des personnes qui l'utilisent. Au lieu de fournir des instructions détaillées, les règles de Scrum guident les relations et les interactions.

Diverses méthodes, techniques et pratiques peuvent être employées au sein du cadre. Scrum s'intègre aux pratiques existantes ou les rend inutiles. Scrum révèle l'efficacité relative des techniques actuelles de gestion, d'environnement et de travail, afin que des améliorations puissent être apportées.

Théorie de Scrum

Scrum est fondé sur l'empirisme et la pensée lean. L'empirisme affirme que la connaissance provient de l'expérience et des décisions basées sur l'observation. La pensée lean réduit le gaspillage et se concentre sur l'essentiel.

Scrum emploie une approche itérative et incrémentale pour optimiser la prévisibilité et contrôler les risques. Scrum engage des groupes de personnes qui, collectivement, possèdent toutes les compétences et l'expertise nécessaires pour accomplir le travail et partager ou acquérir ces compétences selon les besoins.

Application de l'empirisme

Pour illustrer comment l'empirisme fonctionne en pratique :

• Dans le secteur manufacturier : Au lieu de planifier une ligne de production complète et en détails avant le lancement, une équipe Scrum pourrait commencer avec une configuration minimale, mesurer les résultats (qualité, débit), puis adapter progressivement la ligne en fonction des données réelles plutôt que sur des projections théoriques.
• Dans le marketing : Au lieu de développer une campagne entière basée sur des idées, l'équipe lance d'abord des mini-campagnes tests, mesure la réponse du marché, puis adapte la stratégie globale en fonction des résultats observés.

Scrum combine quatre événements formels d'inspection et d'adaptation au sein d'un événement englobant, le Sprint. Ces événements fonctionnent car ils mettent en œuvre les piliers empiriques de Scrum : la transparence, l'inspection et l'adaptation.

Transparence

Le processus émergent et le travail doivent être visibles tant pour ceux qui réalisent le travail que pour ceux qui le reçoivent. Avec Scrum, les décisions importantes sont basées sur l'état perçu de ses trois artefacts formels. Les artefacts manquant de transparence peuvent conduire à des décisions qui diminuent la valeur et augmentent les risques.

La transparence permet l'inspection. L'inspection sans transparence est trompeuse et inutile.

Exemples de transparence

• Exemple concret : Une équipe de développement logiciel maintient un tableau Kanban physique ou digital qui montre clairement quelles tâches sont en attente, en cours et terminées. Toute personne passant devant ce tableau peut instantanément comprendre l'état du travail sans avoir à demander.
• Contre-exemple : Une équipe maintient son suivi de progression dans des documents individuels ou des emails, rendant impossible pour les parties prenantes de comprendre l'état réel du projet sans demander spécifiquement.

Inspection

Les artefacts Scrum et les progrès vers les objectifs convenus doivent être inspectés fréquemment et avec diligence pour détecter les écarts ou problèmes potentiellement indésirables. Pour faciliter l'inspection, Scrum fournit une cadence sous la forme de ses cinq événements.

L'inspection permet l'adaptation. L'inspection sans adaptation est considérée comme inutile. Les événements Scrum sont conçus pour provoquer des changements.

Techniques d'inspection efficace

• Daily Scrum amélioré : Au-delà des trois questions classiques, les équipes peuvent utiliser des techniques comme "l'analyse des blocages" où chaque blocage est discuté brièvement avec une personne désignée pour le résoudre hors réunion.
• Tableaux de bord visuels : Des indicateurs visuels pour la qualité du code (couverture des tests, dette technique), la vélocité de l'équipe, et la satisfaction des utilisateurs permettent une inspection rapide et significative.

Adaptation

Si des aspects d'un processus s'écartent des limites acceptables ou si le produit résultant est inacceptable, le processus appliqué ou les matériaux produits doivent être ajustés. L'ajustement doit être effectué dès que possible pour minimiser tout écart supplémentaire.

L'adaptation devient plus difficile lorsque les personnes impliquées ne sont pas habilitées ou auto-organisées. Une équipe Scrum est censée s'adapter dès qu'elle apprend quelque chose de nouveau par l'inspection.

Exemples d'adaptation efficace

• Adaptation technique : Une équipe découvre pendant un Sprint que l'approche technique choisie ne performe pas comme prévu. Au lieu d'attendre la fin du Sprint, ils organisent une session de conception improvisée, ajustent leur approche et communiquent le changement lors du prochain Daily Scrum.
• Adaptation business : Le feedback client recueilli en milieu de Sprint révèle que les utilisateurs préfèrent une approche différente. Le Product Owner et l'équipe collaborent immédiatement pour ajuster le champ du Sprint sans compromettre l'objectif principal.

Valeurs Scrum

L'utilisation réussie de Scrum dépend de la maîtrise par les personnes de cinq valeurs : Engagement, Focus, Ouverture, Respect et Courage

L'équipe Scrum s'engage à atteindre ses objectifs et à se soutenir mutuellement. Leur focus principal est le travail du Sprint pour faire le meilleur progrès possible vers ces objectifs. L'équipe Scrum et ses parties prenantes sont ouvertes concernant le travail et les défis. Les membres de l'équipe Scrum se respectent mutuellement en tant que personnes capables et indépendantes, et sont respectés comme tels par les personnes avec lesquelles ils travaillent. Les membres de l'équipe Scrum ont le courage de faire ce qui est juste et de s'attaquer à des problèmes difficiles.

Cultiver les valeurs dans la pratique

• Engagement : Une équipe fait face à un problème technique majeur en fin de Sprint. Au lieu de reporter le travail, les membres s'organisent pour trouver collectivement une solution, certains restant plus tard volontairement par solidarité et engagement envers l'objectif commun.
• Focus : Malgré les demandes urgentes provenant d'autres départements, l'équipe maintient son attention sur l'objectif du Sprint actuel. Le Scrum Master aide à protéger l'équipe des distractions externes.
• Ouverture : Lors d'une rétrospective, un développeur admet avoir pris un raccourci technique qui pourrait causer des problèmes futurs. L'équipe reçoit cette information sans blâme et travaille ensemble pour réduire la dette technique.
• Respect : Dans une équipe diversifiée, un membre moins expérimenté propose une solution non conventionnelle. Au lieu de rejeter l'idée, l'équipe explore son potentiel, reconnaissant que les perspectives différentes peuvent mener à l'innovation.
• Courage : Le Product Owner défend la décision de reporter une fonctionnalité demandée par un client important car elle compromettrait la qualité du produit. L'équipe soutient cette position difficile mais nécessaire.

Ces valeurs donnent une orientation à l'équipe Scrum concernant leur travail, leurs actions et leur comportement. Les décisions prises, les étapes franchies et la façon dont Scrum est utilisé devraient renforcer ces valeurs, non les diminuer ou les saper. Les membres de l'équipe Scrum apprennent et explorent ces valeurs en travaillant avec les événements et les artefacts Scrum. Lorsque ces valeurs sont incarnées par l'équipe Scrum et les personnes avec lesquelles elle travaille, les piliers empiriques de Scrum - transparence, inspection et adaptation - prennent vie en établissant la confiance.

Équipe Scrum

L'unité fondamentale de Scrum est une petite équipe de personnes, l'équipe Scrum. L'équipe Scrum se compose d'un Scrum Master, d'un Product Owner et de Développeurs. Au sein d'une équipe Scrum, il n'y a pas de sous-équipes ou de hiérarchies. C'est une unité cohésive de professionnels concentrés sur un objectif à la fois, l'Objectif de Produit.

Les équipes Scrum sont multifonctionnelles, ce qui signifie que les membres possèdent toutes les compétences nécessaires pour créer de la valeur à chaque Sprint. Elles sont également auto-organisées, ce qui signifie qu'elles décident en interne qui fait quoi, quand et comment.

Taille et structure optimales

L'équipe Scrum est suffisamment petite pour rester agile et suffisamment grande pour accomplir un travail significatif dans un Sprint, généralement 10 personnes ou moins. En général, nous avons constaté que les équipes plus petites communiquent mieux et sont plus productives. Si les équipes Scrum deviennent trop grandes, elles devraient envisager de se réorganiser en plusieurs équipes Scrum cohésives, chacune concentrée sur le même produit. Par conséquent, elles devraient partager le même Objectif de Produit, Product Backlog et Product Owner.

Adaptation aux différentes échelles

• Petites entreprises (5-20 personnes) : Une à deux équipes Scrum peuvent fonctionner de manière autonome avec une coordination minimale.
• Moyennes entreprises (20-100 personnes) : Plusieurs équipes Scrum peuvent nécessiter une coordination légère via des techniques comme le "Scrum de Scrums" où des représentants de chaque équipe se réunissent régulièrement.
• Grandes entreprises (100+ personnes) : Des cadres de mise à l'échelle plus formels peuvent être nécessaires, mais doivent toujours préserver l'autonomie et l'auto-organisation des équipes individuelles. Considérez des modèles comme LeSS (Large-Scale Scrum) ou Nexus qui préservent l'essence de Scrum tout en ajoutant des mécanismes de coordination.

L'équipe Scrum est responsable de toutes les activités liées au produit, de la collaboration avec les parties prenantes à la vérification, la maintenance, l'exploitation, l'expérimentation, la recherche et le développement, et tout ce qui pourrait être nécessaire. Ils sont structurés et habilités par l'organisation à gérer leur propre travail. Travailler en Sprints à un rythme soutenable améliore la concentration et la constance de l'équipe Scrum.

Toute l'équipe Scrum est responsable de la création d'un Incrément précieux et utile à chaque Sprint. Scrum définit trois responsabilités spécifiques au sein de l'équipe Scrum : les Développeurs, le Product Owner et le Scrum Master.

Développeurs

Les Développeurs sont les personnes de l'équipe Scrum qui s'engagent à créer tout aspect d'un Incrément utilisable à chaque Sprint.

Les compétences spécifiques requises par les Développeurs sont souvent larges et varient selon le domaine de travail. Cependant, les Développeurs sont toujours responsables de :

• Créer un plan pour le Sprint, le Sprint Backlog ;
• Instiller la qualité en adhérant à une Definition of Done ;
• Adapter leur plan chaque jour en fonction de l'Objectif du Sprint ; et
• Se tenir mutuellement responsables en tant que professionnels.

Exemples de compétences des développeurs par domaine

• Développement logiciel : Programmation, architecture, test, UX design, DevOps
• Marketing : Analyse de marché, création de contenu, conception graphique, analyse de données
• Soins de santé : Conception de protocoles, analyse clinique, gestion de données patients, formation

Product Owner

Le Product Owner est responsable de maximiser la valeur du produit résultant du travail de l'équipe Scrum. La façon dont cela est fait peut varier considérablement selon les organisations, les équipes Scrum et les individus.

Le Product Owner est également responsable de la gestion efficace du Product Backlog, ce qui inclut :

• Développer et communiquer explicitement l'Objectif du Produit ;
• Créer et communiquer clairement les éléments du Product Backlog ;
• Ordonner les éléments du Product Backlog ; et
• S'assurer que le Product Backlog est transparent, visible et compris.

Stratégies pour un Product Owner éfficace

• Gestion des parties prenantes : Établir une cartographie claire des parties prenantes avec leur niveau d'influence et d'intérêt pour guider les interactions.
• Critères de priorisation transparents : Utiliser des modèles comme RICE (Reach, Impact, Confidence, Effort) ou WSJF (Weighted Shortest Job First) pour rendre les décisions de priorisation objectives et défendables.
• Communication de la vision : Maintenir un document de vision de produit concis que l'équipe et les parties prenantes peuvent facilement référencer pour comprendre la direction stratégique.

Le Product Owner peut effectuer le travail ci-dessus ou peut en déléguer la responsabilité à d'autres. Néanmoins, le Product Owner reste responsable.

Pour que les Product Owners réussissent, l'organisation entière doit respecter leurs décisions. Ces décisions sont visibles dans le contenu et l'ordonnancement du Product Backlog, et à travers l'Incrément inspectable lors de la Sprint Review.

Le Product Owner est une personne, pas un comité. Le Product Owner peut représenter les besoins de nombreuses parties prenantes dans le Product Backlog. Ceux qui souhaitent modifier le Product Backlog peuvent le faire en essayant de convaincre le Product Owner.

Scrum Master

Le Scrum Master est responsable d'établir Scrum tel que défini dans le Guide Scrum. Ils le font en aidant tout le monde à comprendre la théorie et la pratique Scrum, à la fois au sein de l'équipe Scrum et de l'organisation.

Le Scrum Master est responsable de l'efficacité de l'équipe Scrum. Ils le font en permettant à l'équipe Scrum d'améliorer ses pratiques, dans le cadre de Scrum.

Les Scrum Masters sont de véritables leaders qui servent l'équipe Scrum et l'organisation au sens large.

Techniques de coaching et de facilitation

• Coaching individuel : Utiliser des techniques comme le modèle GROW (Goal, Reality, Options, Will) pour des sessions de coaching one-to-one avec les membres de l'équipe.
• Facilitation de conflits : Appliquer des techniques comme "les six chapeaux de la réflexion" ou la "résolution de conflits non-violente" pour aider l'équipe à surmonter les désaccords productifs.
• Enseignement systémique : Utiliser des exercices comme "le jeu de la balle" ou "la simulation de chaîne de production" pour illustrer les principes de flux, de travail en cours limité et d'optimisation systémique.

Le Scrum Master sert l'équipe Scrum de plusieurs façons, notamment :

• Coacher les membres de l'équipe en matière d'auto-organisation et de multifonctionnalité ;
• Aider l'équipe Scrum à se concentrer sur la création d'Incréments de grande valeur qui répondent à la Definition of Done ;
• Éliminer les obstacles au progrès de l'équipe Scrum ; et
• S'assurer que tous les événements Scrum ont lieu, sont positifs, productifs et respectent le time-box.

Le Scrum Master sert le Product Owner de plusieurs façons, notamment :

• Aider à trouver des techniques pour une définition efficace de l'Objectif du Produit et une gestion du Product Backlog ;
• Aider l'équipe Scrum à comprendre la nécessité d'éléments du Product Backlog clairs et concis ;
• Aider à établir une planification empirique du produit pour un environnement complexe ; et
• Faciliter la collaboration des parties prenantes selon les besoins.

Le Scrum Master sert l'organisation de plusieurs façons, notamment :

• Diriger, former et coacher l'organisation dans son adoption de Scrum ;
• Planifier et conseiller les implémentations de Scrum au sein de l'organisation ;
• Aider les employés et les parties prenantes à comprendre et à mettre en œuvre une approche empirique pour un travail complexe ; et
• Éliminer les barrières entre les parties prenantes et les équipes Scrum.

Événements Scrum

Le Sprint est un conteneur pour tous les autres événements. Chaque événement dans Scrum est une opportunité formelle d'inspecter et d'adapter les artefacts Scrum. Ces événements sont spécifiquement conçus pour permettre la transparence requise. Ne pas opérer les événements comme prescrit entraîne des opportunités perdues d'inspection et d'adaptation. Les événements sont utilisés dans Scrum pour créer de la régularité et minimiser le besoin de réunions non définies dans Scrum.

Idéalement, tous les événements se tiennent au même moment et lieu pour réduire la complexité.

Le Sprint

Les Sprints sont le cœur de Scrum, où les idées sont transformées en valeur.

Ce sont des événements à durée fixe d'un mois ou moins pour créer de la cohérence. Un nouveau Sprint commence immédiatement après la conclusion du Sprint précédent.

Tout le travail nécessaire pour atteindre l'Objectif du Produit, y compris la Sprint Planning, les Daily Scrums, la Sprint Review et la Sprint Retrospective, se déroule au sein des Sprints.

Adaptation de la durée des sprints

• Sprints courts (1-2 semaines) : Idéaux pour les environnements à changement rapide comme les startups, les produits en phase initiale, ou les marchés volatils. Permettent des pivots rapides et un feedback fréquent.
• Sprints moyens (2-3 semaines) : Un bon équilibre pour la plupart des produits établis. Offrent suffisamment de temps pour accomplir des travaux substantiels tout en maintenant l'agilité.
• Sprints longs (4 semaines) : Adaptés aux produits très complexes ou aux environnements avec des cycles de validation étendus (comme les dispositifs médicaux ou les systèmes embarqués). Utilisez avec prudence car ils augmentent le risque d'écart par rapport aux besoins.

Pendant le Sprint :

• Aucun changement n'est effectué qui mettrait en danger l'Objectif du Sprint ;
• La qualité ne diminue pas ;
• Le Product Backlog est affiné selon les besoins ; et
• La portée peut être clarifiée et renégociée avec le Product Owner à mesure que l'on en apprend davantage.

Les Sprints permettent la prévisibilité en assurant l'inspection et l'adaptation des progrès vers un Objectif de Produit au moins tous les mois calendaire. Lorsque l'horizon d'un Sprint est trop long, l'Objectif du Sprint peut devenir invalide, la complexité peut augmenter et le risque peut s'accroître. Des Sprints plus courts peuvent être employés pour générer plus de cycles d'apprentissage et limiter le risque de coût et d'effort à un cadre temporel plus restreint. Chaque Sprint peut être considéré comme un petit projet.

Diverses pratiques existent pour prévoir les progrès, comme les burn-downs, burn-ups ou flux cumulatifs. Bien qu'elles se soient avérées utiles, elles ne remplacent pas l'importance de l'empirisme. Dans des environnements complexes, ce qui se passera est inconnu. Seul ce qui s'est déjà produit peut être utilisé pour la prise de décision prospective.

Un Sprint pourrait être annulé si l'Objectif du Sprint devient obsolète. Seul le Product Owner a l'autorité d'annuler le Sprint.

Sprint Planning

La Sprint Planning initie le Sprint en établissant le travail à effectuer pour le Sprint. Ce plan résultant est créé par le travail collaboratif de toute l'équipe Scrum.

Le Product Owner s'assure que les participants sont préparés à discuter des éléments les plus importants du Product Backlog et comment ils correspondent à l'Objectif du Produit. L'équipe Scrum peut également inviter d'autres personnes à assister à la Sprint Planning pour fournir des conseils.

Techniques avancées de sprint planning

• Story Mapping : Organiser visuellement les user stories par catégories d'utilisateurs et flux de travail pour mieux comprendre les relations entre les éléments et faciliter la sélection cohérente.
• Planification basée sur le risque : Identifier explicitement les éléments à haut risque (techniques, business, ou organisationnels) et les intégrer stratégiquement dans les Sprints pour réduire l'incertitude le plus tôt possible.
• Planning Poker avec calibration : Avant d'estimer, réviser les éléments passés de différentes tailles pour établir une compréhension commune des points de référence, améliorant ainsi la cohérence des estimations.

La Sprint Planning aborde les sujets suivants :

Sujet un : Pourquoi ce Sprint est-il précieux ?

Le Product Owner propose comment le produit pourrait augmenter sa valeur et son utilité dans le Sprint actuel. L'équipe Scrum collabore ensuite pour définir un Objectif de Sprint qui communique pourquoi le Sprint est précieux pour les parties prenantes. L'Objectif du Sprint doit être finalisé avant la fin de la Sprint Planning.

Sujet deux : Que peut-on faire dans ce Sprint ?

Par la discussion avec le Product Owner, les Développeurs sélectionnent des éléments du Product Backlog à inclure dans le Sprint actuel. L'équipe Scrum peut affiner ces éléments pendant ce processus, ce qui augmente la compréhension et la confiance.

Sélectionner combien peut être accompli dans un Sprint peut être difficile. Cependant, plus les Développeurs connaissent leurs performances passées, leur capacité à venir et leur Definition of Done, plus ils seront confiants dans leurs prévisions de Sprint.

Sujet Trois : Comment le travail choisi sera-t-il réalisé ?

Pour chaque élément du Product Backlog sélectionné, les Développeurs planifient le travail nécessaire pour créer un Incrément qui répond à la Definition of Done. Ceci est souvent fait en décomposant les éléments du Product Backlog en éléments de travail plus petits d'un jour ou moins. La façon dont cela est fait est à la seule discrétion des Développeurs. Personne d'autre ne leur dit comment transformer les éléments du Product Backlog en Incréments de valeur.

L'Objectif du Sprint, les éléments du Product Backlog sélectionnés pour le Sprint, ainsi que le plan pour les livrer sont ensemble appelés le Sprint Backlog.

La Sprint Planning est limitée à un maximum de huit heures pour un Sprint d'un mois. Pour des Sprints plus courts, l'événement est généralement plus court.

Daily Scrum

L'objectif du Daily Scrum est d'inspecter les progrès vers l'Objectif du Sprint et d'adapter le Sprint Backlog si nécessaire, en ajustant le travail planifié à venir.

Le Daily Scrum est un événement de 15 minutes pour les Développeurs de l'équipe Scrum. Pour réduire la complexité, il se tient à la même heure et au même endroit chaque jour ouvrable du Sprint. Si le Product Owner ou le Scrum Master travaillent activement sur des éléments du Sprint Backlog, ils participent en tant que Développeurs.

Formats efficaces de daily scrum

• Format orienté obstacles : Identifiez d'abord les blocages qui empêchent l'équipe d'avancer, puis organisez la discussion autour de leur résolution.
• Format orienté flux : Concentrez-vous sur le mouvement des éléments à travers le tableau, en identifiant spécifiquement les éléments qui n'ont pas bougé depuis la veille.
• Format walkboard : Passez en revue chaque élément sur le tableau de Sprint en commençant par ceux qui sont proches de la définition de "terminé", focalisant ainsi l'attention sur la livraison.

Les Développeurs peuvent sélectionner la structure et les techniques qu'ils souhaitent, tant que leur Daily Scrum se concentre sur les progrès vers l'Objectif du Sprint et produit un plan d'action pour la journée de travail suivante. Cela crée de la concentration et améliore l'auto-gestion.

Les Daily Scrums améliorent les communications, identifient les obstacles, favorisent une prise de décision rapide et, par conséquent, éliminent le besoin d'autres réunions.

Le Daily Scrum n'est pas le seul moment où les Développeurs sont autorisés à ajuster leur plan. Ils se réunissent souvent tout au long de la journée pour des discussions plus détaillées sur l'adaptation ou la replanification du reste du travail du Sprint.

Sprint Review

L'objectif de la Sprint Review est d'inspecter le résultat du Sprint et de déterminer les adaptations futures. L'équipe Scrum présente les résultats de son travail aux principales parties prenantes et les progrès vers l'Objectif du Produit sont discutés.

Techniques pour des review engageantes

• Démos basées sur les scénarios utilisateurs : Présenter les fonctionnalités dans le contexte des parcours utilisateurs complets plutôt que comme des fonctionnalités isolées.
• Stations d'expérimentation : Permettre aux parties prenantes d'interagir directement avec l'incrément via plusieurs stations où les développeurs facilitent l'expérience et recueillent des feedbacks détaillés.
• Collecte de feedback structurée : Utiliser des techniques comme le "feedback en quatre quadrants" (ce qui a plu, ce qui pourrait être amélioré, les questions, les idées) pour organiser les commentaires des parties prenantes.

Pendant l'événement, l'équipe Scrum et les parties prenantes examinent ce qui a été accompli dans le Sprint et ce qui a changé dans leur environnement. Sur la base de ces informations, les participants collaborent sur ce qu'il faut faire ensuite. Le Product Backlog peut également être ajusté pour répondre à de nouvelles opportunités. La Sprint Review est une session de travail et l'équipe Scrum devrait éviter de la limiter à une présentation.

[Etc... etc... etc...] je vous laisse imaginer la suite :-)

Francois MANGIORAKOS