i

Description

Gravure ancienne d'une mêlée de rugby en train de se former

Source

auteur non indiqué · page d’origine

Licence

PD Domaine public

Photo d’origine, non retouchée. L’arrière-plan en est une version stylisée par le site.

Scrum, le cadre (Scrum Guide 2020)

Vous saurez décrire Scrum tel que le définit le Scrum Guide 2020 : théorie empirique, valeurs, équipe, rôles, cinq événements, trois artefacts et leurs engagements.

En bref

• Vous saurez décrire Scrum tel que le définit le Scrum Guide 2020 : théorie empirique, valeurs, équipe, rôles, cinq événements, trois artefacts et leurs engagements.
• Vous distinguerez ce que le Guide prescrit (le cadre, volontairement minimal) de ce que la pratique ajoute (user stories, points, vélocité : rien de tout cela n'est dans le Guide).
• Vous saurez lire les subtilités d'un expert : pourquoi la Sprint Review n'est pas une démonstration de validation, pourquoi la rétrospective est le moteur du cadre, ce que signifie « incrément utilisable ».
• Vous saurez repérer ce que Scrum n'est pas (une méthode de gestion de projet complète, un outil de contrôle, un planning).
• Les mises en œuvre et pièges sont dans Scrum en pratique ; l'application à la BI dans Scrum et data.

Source et état. Texte de référence : The Scrum Guide (Ken Schwaber et Jeff Sutherland, novembre 2020, scrumguides.org, traduit en français). Vérification (état 2026-10) : la version 2020 reste la version courante publiée ; aucune révision plus récente n'a été confirmée lors de la rédaction. Les formulations ci-dessous sont des paraphrases de l'auteur de ce dossier, non des citations ; seul le texte officiel fait foi.

Sur cette page

1. 🟢 Novice — Scrum en une page
   1. Les éléments, d'un coup d'œil
2. 🟢 Novice — La théorie empirique : trois piliers
3. 🟢 Novice — Les cinq valeurs
4. 🟢 Novice — La Scrum Team
   1. Une équipe, pas des sous-équipes
   2. Le terme « Developers »
5. 🟢 Novice — Les trois responsabilités
   1. Product Owner
   2. Scrum Master
   3. Developers
   4. Tableau synthétique des responsabilités
6. 🟡 Pratique — Les cinq événements
7. 🟡 Pratique — Le Sprint
   1. Pourquoi la durée fixe
   2. L'annulation d'un Sprint
8. 🟡 Pratique — Sprint Planning
   1. Capacité et prévision
9. 🟡 Pratique — Daily Scrum
10. 🟡 Pratique — Sprint Review
11. 🟡 Pratique — Sprint Retrospective
12. 🟡 Pratique — Les trois artefacts et leurs engagements
    1. Product Backlog
    2. Sprint Backlog
    3. Incrément
13. 🟡 Pratique — Product Goal
14. 🟡 Pratique — Sprint Goal
15. 🟡 Pratique — Definition of Done
16. 🔴 Expert — Lectures expertes du Guide
    1. 1. Scrum est un cadre de contrôle de processus empirique, pas un plan
    2. 2. L'asymétrie « objectif ferme, périmètre souple »
    3. 3. « Tout ce qui est visible a-t-il le même statut ? »
    4. 4. Incrément et déploiement : deux notions distinctes
    5. 5. Auto-gestion ne veut pas dire absence de contraintes
    6. 6. Le rôle sous-estimé du Scrum Master : agent de changement organisationnel
    7. 7. La contradiction apparente : « un Sprint, une équipe, un Product Goal »
    8. 8. Prévisibilité : par la durée, non par le contrôle
17. 🔴 Expert — Ce que le Guide ne dit pas
18. 🔴 Expert — Ce que Scrum n'est pas
19. 🔴 Expert — Évolution du Guide : 2010 → 2017 → 2020
20. Métriques : Scrum selon quelques critères
21. Contribution de l'IA
22. Voir aussi

Niveau : 🟢→🔴

🟢 Novice — Scrum en une page#

Scrum est un cadre léger (framework) qui aide des personnes, des équipes et des organisations à créer de la valeur en apportant des solutions adaptatives à des problèmes complexes. Scrum est un cadre et non une méthode complète : on y emploie d'autres processus et techniques. Le Guide le dit volontairement incomplet : il ne définit que les parties nécessaires pour mettre en œuvre la théorie Scrum.

Le principe : une équipe unique et pluridisciplinaire livre, à intervalles courts et réguliers (les Sprints, d'un mois au plus), un Incrément utilisable. À chaque fin de Sprint, on inspecte ce qui a été produit et la manière dont on travaille, puis on adapte.

Les éléments, d'un coup d'œil#

🟢 Novice — La théorie empirique : trois piliers#

Scrum repose sur l'empirisme (la connaissance vient de l'expérience, on décide à partir de ce qu'on observe) et sur la pensée Lean (réduire le gaspillage, se concentrer sur l'essentiel). Il s'oppose à l'idée qu'on pourrait tout prédire dans un problème complexe (voir le cadre Cynefin dans Fondamentaux). Son approche est itérative et incrémentale pour optimiser la prévisibilité et maîtriser le risque.

Trois piliers soutiennent toute mise en œuvre empirique du contrôle de processus :

Ces trois piliers sont interdépendants : la transparence rend l'inspection possible, l'inspection rend l'adaptation pertinente ; sans adaptation, l'inspection n'est qu'un constat. Les cinq événements de Scrum sont conçus comme des occasions d'inspection et d'adaptation.

Le Guide indique aussi que, si l'on change les règles de Scrum, le cadre peut perdre sa cohérence : « Scrum n'est que Scrum » dans son intégralité, ce qui autorise à adopter des éléments isolés mais dont le Guide dit que le bénéfice complet s'obtient avec le tout. Voir les ScrumBut pour les dérives.

🟢 Novice — Les cinq valeurs#

Les valeurs ne sont pas décoratives : elles décrivent le comportement sans lequel les piliers s'effondrent. Le Guide précise que les membres de l'équipe apprennent et explorent ces valeurs en travaillant avec les événements et les artefacts, et que les décisions, les actions et la manière d'utiliser Scrum doivent renforcer ces valeurs et non les diminuer.

🟢 Novice — La Scrum Team#

Une équipe, pas des sous-équipes#

L'unité fondamentale de Scrum est une petite équipe : un Scrum Master, un Product Owner et des Developers. Il n'y a pas de sous-équipes ni de hiérarchies au sein de la Scrum Team : c'est une seule unité vouée au même objectif, le Product Goal.

Caractéristiques décrites par le Guide :

• Pluridisciplinaire : les membres possèdent ensemble toutes les compétences nécessaires pour créer de la valeur à chaque Sprint.
• Auto-gérée (self-managing) : ils décident en interne qui fait quoi, quand et comment. Le Guide 2020 a remplacé « auto-organisée » par « auto-gérée » pour insister sur ce point : l'équipe ne se contente pas de s'organiser, elle décide.
• Taille : en général 10 personnes ou moins. Plus l'équipe grandit, plus la communication se complique ; au-delà, il vaut mieux plusieurs équipes autour d'un même produit (même Product Goal, même Product Backlog, même PO).
• Responsable de toutes les activités liées au produit : collaboration avec les parties prenantes, vérification, maintenance, exploitation, expérimentation, recherche et développement, et tout le reste nécessaire.

Le terme « Developers »#

Dans le Guide 2020, Developers désigne les personnes qui s'engagent à créer n'importe quel aspect d'un Incrément utilisable à chaque Sprint : développeurs de logiciel, mais aussi analystes, testeurs, spécialistes de la donnée, de la BI, de l'UX, etc. Le mot n'est donc pas réservé aux programmeurs. Les compétences précises varient selon le domaine. Le Guide 2020 a abandonné l'expression « Development Team » (équipe de développement) pour supprimer l'idée qu'il existerait une sous-équipe distincte.

🟢 Novice — Les trois responsabilités#

Le Guide parle de responsabilités (accountabilities) plutôt que de rôles : ce dont chacun doit répondre. Un point d'attention : accountability = redevabilité (devoir de rendre compte), plus fort que responsibility.

Product Owner#

Redevable de maximiser la valeur du produit résultant du travail de la Scrum Team. La manière d'y parvenir varie énormément selon les organisations. Il est redevable (et peut déléguer le travail, mais reste le seul redevable) de la gestion efficace du Product Backlog :

• développer et communiquer explicitement le Product Goal ;
• créer et communiquer clairement les éléments du Product Backlog ;
• ordonner les éléments du Product Backlog ;
• s'assurer que le Product Backlog est transparent, visible et compris.

Le PO est une personne, pas un comité. Pour que son pouvoir soit réel, toute l'organisation doit respecter ses décisions, visibles dans le contenu et l'ordre du Product Backlog et dans l'Incrément inspecté en Sprint Review. Les parties prenantes peuvent demander des changements en convainquant le PO, non en le contournant.

Scrum Master#

Redevable de l'établissement de Scrum tel que défini dans le Guide, en aidant tout le monde à comprendre la théorie et la pratique de Scrum, dans l'équipe comme dans l'organisation. Redevable de l'efficacité de la Scrum Team, en l'aidant à améliorer ses pratiques dans le cadre de Scrum. C'est un véritable leader qui sert (true leader who serves) l'équipe et l'organisation.

Il sert :

Le Scrum Master n'est ni un chef de projet, ni un secrétaire de réunion, ni un contrôleur du processus : il n'assigne pas le travail, ne gère pas le planning, ne fait pas de reporting de suivi individuel.

Developers#

Redevables de :

• créer un plan pour le Sprint : le Sprint Backlog ;
• instiller la qualité en respectant une Definition of Done ;
• adapter leur plan chaque jour vers le Sprint Goal ;
• se tenir mutuellement responsables en tant que professionnels.

Ce sont eux qui estiment (le Guide précise que les Developers dimensionnent) et qui décident de la quantité de travail qu'ils peuvent s'engager à produire : ni le PO, ni le SM n'imposent le volume.

Tableau synthétique des responsabilités#

🟡 Pratique — Les cinq événements#

Les événements de Scrum créent une régularité et minimisent le besoin de réunions non prévues. Chacun est une occasion formelle d'inspecter et d'adapter un artefact. Ils sont tenus dans leur timebox (durée maximale) et, idéalement, à la même heure et au même endroit pour réduire la complexité. Le Sprint est le conteneur des autres.

Pour un Sprint plus court, les événements le sont généralement aussi (proportionnellement). Les durées ci-dessus sont des maximums, non des cibles.

🟡 Pratique — Le Sprint#

Cœur de Scrum, le Sprint est un événement d'un mois ou moins, de durée constante, au cours duquel les idées se transforment en valeur. Un nouveau Sprint démarre immédiatement après la fin du précédent. Tout le travail nécessaire pour atteindre le Product Goal (planification, développement quotidien, revue, rétrospective) se passe dans des Sprints.

Pendant le Sprint :

• aucun changement n'est apporté qui mettrait en danger le Sprint Goal ;
• la qualité ne baisse pas ;
• le Product Backlog est raffiné si nécessaire ;
• le périmètre peut être clarifié et renégocié avec le PO à mesure qu'on en apprend davantage.

Pourquoi la durée fixe#

Un Sprint de durée constante crée un rythme : l'équipe apprend sa capacité, les parties prenantes savent quand elles auront de l'information, la prévisibilité émerge. Sprints courts : plus de cycles d'apprentissage, risque limité à moins d'un mois de coût. Le Guide autorise « un mois ou moins » ; la majorité des équipes choisit une à deux semaines (ordre de grandeur de pratique, non une règle du Guide).

L'annulation d'un Sprint#

Un Sprint peut être annulé avant la fin de sa timebox, uniquement par le Product Owner, typiquement quand le Sprint Goal est devenu obsolète (changement de cap de l'organisation, évolution du marché ou de la technologie). C'est rare, coûteux (tout le travail de planification est perdu) et traumatisant ; l'item déjà terminé et conforme à la DoD est examiné, le reste est replacé dans le Product Backlog. Il vaut mieux des Sprints courts qu'une annulation.

🟡 Pratique — Sprint Planning#

La Sprint Planning initie le Sprint en définissant le travail à réaliser. Ce plan est le résultat du travail collaboratif de toute la Scrum Team. Le PO s'assure que les participants sont prêts à discuter des items les plus importants du Product Backlog et de leur relation avec le Product Goal. La Scrum Team peut inviter d'autres personnes pour conseil.

Le Guide structure la Planning en trois sujets :

Le Sprint Goal, les items choisis et le plan pour les livrer forment ensemble le Sprint Backlog.

Capacité et prévision#

Le Guide ne prescrit ni vélocité, ni story points. Les Developers utilisent ce qu'ils savent de leur capacité (disponibilités, congés, dépendances) et de leur historique pour prévoir. Les techniques détaillées d'estimation sont dans Scrum en pratique.

🟡 Pratique — Daily Scrum#

But : inspecter la progression vers le Sprint Goal et adapter le Sprint Backlog en fonction des besoins, en ajustant le travail planifié à venir.

• 15 minutes, chaque jour de travail du Sprint, à la même heure et au même endroit pour réduire la complexité.
• Participants : les Developers. Si le PO ou le SM travaillent activement sur des items du Sprint Backlog, ils participent en tant que Developers.
• La structure est libre : les Developers choisissent le format (le Guide 2020 a supprimé les trois questions rituelles « qu'ai-je fait hier ? Que ferai-je aujourd'hui ? Quels obstacles ? » — souvent conservées par habitude, mais non prescrites), du moment qu'elle se concentre sur la progression vers le Sprint Goal et produit un plan d'action pour la journée suivante.
• Elle améliore la communication, identifie les obstacles, favorise la prise de décision rapide, et supprime ainsi le besoin d'autres réunions.
• Ce n'est pas la seule occasion d'ajuster le plan : les Developers se retrouvent souvent juste après pour des discussions détaillées.

🟡 Pratique — Sprint Review#

But : inspecter le résultat du Sprint et déterminer les adaptations futures. La Scrum Team présente les résultats de son travail aux parties prenantes clés et on discute de la progression vers le Product Goal.

Déroulé décrit par le Guide : la Scrum Team et les parties prenantes examinent ce qui a été accompli dans le Sprint et ce qui a changé dans leur environnement ; sur cette base, les participants collaborent pour déterminer quoi faire ensuite. Le Product Backlog peut être ajusté pour saisir de nouvelles opportunités. C'est une séance de travail, pas une présentation : le Guide précise qu'elle ne doit pas être limitée à une démonstration. Elle comprend un examen des tendances (calendrier, budget, ce qui est probable de livrer) et de la ligne du temps.

🟡 Pratique — Sprint Retrospective#

But : planifier des moyens d'augmenter la qualité et l'efficacité. La Scrum Team inspecte comment s'est déroulé le Sprint en ce qui concerne les personnes, les interactions, les processus, les outils et la Definition of Done. Elle identifie ce qui a bien fonctionné, les problèmes rencontrés, comment ils ont été (ou non) résolus, et sélectionne les changements les plus utiles. Les améliorations les plus impactantes sont adoptées au plus vite ; elles peuvent même être ajoutées au Sprint Backlog du prochain Sprint.

Elle conclut le Sprint ; 3 heures max pour un Sprint d'un mois ; elle a lieu après la Review et avant le Sprint suivant.

🟡 Pratique — Les trois artefacts et leurs engagements#

Les artefacts de Scrum représentent du travail ou de la valeur. Ils sont conçus pour maximiser la transparence des informations clés. Chacun contient un engagement (commitment) qui améliore la transparence et le focus :

Product Backlog#

Liste émergente et ordonnée de ce qui est nécessaire pour améliorer le produit. Source unique du travail entrepris par la Scrum Team. Les items suffisamment petits pour être terminés dans un Sprint sont considérés comme prêts à être sélectionnés en Planning, généralement après des activités de raffinement.

Le raffinement (refinement) est l'activité qui consiste à décomposer et définir davantage les items du Product Backlog en items plus petits et plus précis. C'est une activité continue : on ajoute détails, descriptions, ordre et taille. Les attributs varient selon le domaine. Ce sont les Developers qui sont responsables du dimensionnement ; le PO peut les aider en clarifiant et arbitrant. Le Guide 2017 indiquait que le raffinement ne devait pas excéder environ 10 % de la capacité des Developers ; le Guide 2020 n'en parle plus (cette fourchette reste un repère de pratique courant).

Le Guide 2020 ajoute : « Product Goal », « le Product Backlog évolue à mesure que le produit et l'environnement évoluent, il est vivant ». Un Product Backlog n'est jamais complet.

Sprint Backlog#

Composé du Sprint Goal (pourquoi), de l'ensemble des items du Product Backlog sélectionnés pour le Sprint (quoi), et d'un plan actionnable pour livrer l'Incrément (comment). C'est un plan par et pour les Developers, une image très visible, en temps réel, du travail planifié, mis à jour tout au long du Sprint à mesure qu'on apprend. Il doit contenir assez de détail pour que les progrès soient inspectables lors de la Daily Scrum.

Incrément#

Un Incrément est une étape concrète vers le Product Goal. Chaque Incrément est additif à tous les Incréments précédents et vérifié en profondeur, afin de garantir que tous les Incréments fonctionnent ensemble. Pour apporter de la valeur, l'Incrément doit être utilisable. Plusieurs Incréments peuvent être créés dans un même Sprint, et leur somme est présentée en Sprint Review. Le travail ne peut être considéré comme faisant partie d'un Incrément que s'il respecte la Definition of Done. Un item qui ne la respecte pas ne peut pas être publié ni présenté en Review ; il retourne dans le Product Backlog.

🟡 Pratique — Product Goal#

Le Product Goal décrit un état futur du produit qui peut servir de cible de planification à la Scrum Team. Il se trouve dans le Product Backlog : le reste du backlog émerge pour définir ce qui accomplit le Product Goal.

• Un seul à la fois : la Scrum Team doit remplir ou abandonner un objectif avant d'en adopter un autre.
• C'est l'engagement à long terme de l'équipe, qui doit pouvoir dire si elle l'a atteint.
• Un produit est un véhicule de livraison de valeur : il a des limites claires, des parties prenantes identifiées, des utilisateurs ou clients bien définis ; il peut être un service, un produit physique ou un objet plus abstrait.

🟡 Pratique — Sprint Goal#

Le Sprint Goal est l'objectif unique du Sprint. Bien qu'il soit un engagement des Developers, il offre de la flexibilité quant au travail exact nécessaire pour l'atteindre. Il crée de la cohérence et du focus, encourage l'équipe à travailler ensemble plutôt que sur des initiatives séparées. Il est créé pendant la Sprint Planning, ajouté au Sprint Backlog. Si le travail s'avère différent de ce que les Developers avaient prévu, ils collaborent avec le PO pour négocier le périmètre du Sprint Backlog, sans affecter le Sprint Goal.

🟡 Pratique — Definition of Done#

La Definition of Done (DoD) est une description formelle de l'état de l'Incrément quand il satisfait aux mesures de qualité requises pour le produit. Au moment où un item du Product Backlog respecte la DoD, un Incrément est né.

• Elle crée une compréhension partagée de ce que « terminé » signifie : transparence.
• Si la DoD d'un Incrément fait partie des normes de l'organisation, toutes les Scrum Teams doivent la suivre au minimum. Sinon, la Scrum Team doit en créer une adaptée au produit.
• Les Developers doivent s'y conformer ; si plusieurs Scrum Teams travaillent ensemble sur un produit, elles doivent définir et respecter la même DoD.
• Elle évolue : à chaque rétrospective, l'équipe peut resserrer sa DoD ; elle ne la relâche jamais pour tenir une date (ce serait détruire la transparence).

Une DoD adaptée à la data est détaillée dans Scrum et data ; la distinction avec la Definition of Ready est dans Scrum en pratique.

🔴 Expert — Lectures expertes du Guide#

1. Scrum est un cadre de contrôle de processus empirique, pas un plan#

Une lecture fine du Guide montre que presque tout dans Scrum sert une seule idée : raccourcir la boucle de rétroaction pour que l'inspection conduise à l'adaptation. Les événements ne sont pas des réunions mais des points de synchronisation d'apprentissage ; le Sprint est une limite de risque (au pire, on perd un Sprint) ; la DoD est une limite de qualité (rien de moins que « utilisable ») ; le Sprint Goal est un degré de liberté (flexibilité du périmètre, fermeté de l'intention).

2. L'asymétrie « objectif ferme, périmètre souple »#

L'un des gestes les plus profonds de Scrum : on fige le temps et la qualité et on négocie le périmètre. Le Product Owner peut changer le contenu du Sprint Backlog si l'objectif est menacé ; les Developers peuvent réduire le périmètre pour préserver la DoD. Cela contredit le réflexe prédictif (périmètre ferme, qualité variable) et explique pourquoi Scrum est mal compris dans des organisations qui contractualisent un périmètre.

3. « Tout ce qui est visible a-t-il le même statut ? »#

Le Guide ne définit pas d'état « presque terminé ». Un item est Terminé ou pas : cela empêche le « 90 % fait », illusion classique qui masque le travail restant. La conséquence opérationnelle : découper pour que chaque item tienne dans un Sprint et soit terminé plutôt que de commencer beaucoup de choses.

4. Incrément et déploiement : deux notions distinctes#

L'Incrément doit être utilisable ; la mise en production reste une décision du PO (le Guide ne dit pas « à chaque Sprint »). Les équipes à déploiement continu publient souvent plusieurs fois par jour (plusieurs Incréments par Sprint), d'autres livrent en fin de Sprint ; d'autres encore accumulent plusieurs Sprints avant une version commerciale (cas du datamart livré en kits). Dans tous les cas l'Incrément existe à chaque Sprint, et il est potentiellement livrable : la qualité est la même que s'il allait en production. La question de la fréquence de livraison est traitée dans CI/CD et CI/CD pour la data.

5. Auto-gestion ne veut pas dire absence de contraintes#

L'auto-gestion opère dans un cadre : le Product Goal, la DoD, les standards de l'organisation. L'équipe décide du comment, de la répartition, de la quantité ; elle ne décide pas seule de la valeur (PO) ni ne contourne les standards. Elle est aussi redevable : l'autonomie est inséparable de la transparence et de l'inspection.

6. Le rôle sous-estimé du Scrum Master : agent de changement organisationnel#

Le Guide 2020 élargit explicitement le SM au-delà de l'équipe : il aide l'organisation à adopter Scrum, supprime les barrières entre parties prenantes et équipes, conseille sur la planification. C'est pourquoi un SM purement « facilitateur de réunions » est considéré comme une dérive (voir anti-patterns).

7. La contradiction apparente : « un Sprint, une équipe, un Product Goal »#

Plusieurs équipes sur un produit : même Product Backlog, même PO, même DoD, un Incrément intégré (voir scaling). Un seul Product Goal à la fois est un puissant filtre contre la dispersion : « multiples priorités » signifie en réalité « pas de priorité ».

8. Prévisibilité : par la durée, non par le contrôle#

Scrum produit de la prévisibilité par la régularité (cadence, qualité constante, apprentissage de la capacité), non par un plan détaillé. Les prévisions à long terme se font sur des plages (fourchettes) issues de l'historique, avec mise à jour à chaque Sprint. Voir la prévision probabiliste (Monte-Carlo sur le débit) dans Scrum en pratique.

🔴 Expert — Ce que le Guide ne dit pas#

Une quantité de pratiques répandues et associées à Scrum n'appartiennent pas au Guide. Les connaître évite de reprocher à Scrum ce qui est une convention locale, et d'imposer comme « règle Scrum » une préférence personnelle.

Le Guide ne dit rien non plus sur :

• les contrats (comment contractualiser un produit dont le périmètre varie ; voir Scrum et contrats) ;
• les équipes distribuées (voir remote) ;
• la dette technique, sinon à travers la DoD ;
• les spécificités du domaine : data, matériel, réglementaire (voir Scrum et data).

Cette incomplétude est un choix de conception : le Guide laisse l'équipe choisir la technique tant qu'elle respecte les principes. Elle crée aussi une zone grise où prospèrent consultants, certifications et frameworks concurrents.

🔴 Expert — Ce que Scrum n'est pas#

🔴 Expert — Évolution du Guide : 2010 → 2017 → 2020#

Le Guide a été publié pour la première fois en 2010, révisé notamment en 2011, 2013, 2016, 2017 et 2020. Le résumé qui suit couvre les changements les plus marquants de 2020 (d'après les notes de version publiques et l'expérience de la communauté ; pour le détail exact, se référer au Guide) :

Les révisions 2016–2017 avaient déjà ajouté les valeurs (2016) et précisé la DoD. Ce qui a toujours été au cœur : timebox, trois piliers, trois responsabilités. Prudence sur toute affirmation qui prétend que « Scrum a changé de nature » : la version 2020 retire de la prescription plutôt qu'elle n'en ajoute.

Métriques : Scrum selon quelques critères#

Appréciations d'expert, contextuelles (cf. Notation). Contexte de la note : équipe de 5 à 9 personnes, produit évolutif, sponsor disponible ; pour un projet réglementaire à périmètre figé ou une équipe de 2 personnes, les notes bougent.

Contribution de l'IA#

Exemple de prompt : « Voici notre Product Goal et les cinq derniers Sprint Goals. Dis-moi lesquels sont des listes d'items déguisées et propose une reformulation orientée résultat. »

Ce que l'IA ne remplace pas : l'engagement mutuel, le courage de dire non, le jugement du PO sur la valeur, la responsabilité des Developers sur la qualité, la confiance. Des résumés d'IA faits à la place de la conversation détruisent la transparence qu'ils prétendent servir. Voir IA et conduite de projet et IA et outils.

Voir aussi#

• Préalable : Fondamentaux (cycle de vie, Cynefin, valeur).
• Suite : Scrum en pratique (user stories, estimation, anti-patterns, scaling) et Scrum et data.
• Autres cadres agiles et Lean : Méthodes agiles et Lean ; confrontation : Comparatif des méthodes ; choix : Choisir et hybrider.
• Outils de mise en œuvre : Azure DevOps / TFS en profondeur, Jira et alternatives, Métriques et reporting.
• Mesurer votre pratique : Gouvernance et pilotage, Équipe et collaboration, Amélioration continue.
• Termes : Glossaire.

✻ Rédigé par Claude Sonnet 5.5