Guide Scrum

L'objectif du Guide Scrum

Nous avons développé Scrum au début des années 1990. Nous avons rédigé la première version du Guide Scrum en 2010 pour aider les gens du monde entier à comprendre Scrum. Depuis, nous avons fait évoluer le Guide à travers de petites mises à jour fonctionnelles.
Nous le soutenons ensemble.

Le Guide Scrum contient la définition de Scrum. Chaque élément de Scrum sert un objectif spécifique, essentiel à la valeur globale et aux résultats obtenus avec Scrum. Modifier le cœur ou les idées fondamentales de Scrum, omettre des éléments ou ne pas suivre les règles de Scrum masque les problèmes, limite les bénéfices et peut même rendre Scrum inutile.

Nous observons l'utilisation croissante de Scrum dans un monde de plus en plus complexe. Nous constatons avec humilité que Scrum est utilisé dans de nombreux domaines de travail complexe au-delà du développement logiciel – là où Scrum a ses racines. Alors que l'utilisation de Scrum continue de se répandre, ce travail est réalisé par des développeurs et développeuses, des chercheurs et chercheuses, des analystes, des scientifiques et d'autres spécialistes. Nous n'utilisons pas le mot "Developers" dans Scrum pour exclure qui que ce soit, mais pour simplifier. Quiconque bénéficie de l'utilisation de Scrum devrait se sentir concerné.

Lors de l'utilisation de Scrum, des patterns, processus et connaissances peuvent être appliqués et développés en adéquation avec le cadre Scrum tel que décrit dans ce document. Leur description dépasse l'objectif du Guide Scrum, car ils dépendent du contexte et varient considérablement selon la façon dont Scrum est utilisé. De telles tactiques d'application au sein du cadre Scrum varient énormément et sont décrites ailleurs.

Ken Schwaber & Jeff Sutherland, novembre 2020

Définition de Scrum

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

En bref, Scrum exige qu'un Scrum Master favorise un environnement dans lequel

• un Product Owner organise le travail pour un problème complexe dans un Product Backlog ;
• l'équipe Scrum crée un Increment de valeur à partir d'une sélection de ce travail au cours d'un Sprint ;
• l'équipe Scrum et ses parties prenantes examinent les résultats et s'adaptent pour le prochain Sprint ;
• ces étapes sont répétées.

Scrum est simple. Essaie-le tel quel et découvre si sa philosophie, sa théorie et sa structure aident à atteindre les objectifs et à créer de la valeur. Le cadre Scrum est intentionnellement incomplet et ne définit que les éléments nécessaires à la mise en œuvre de la théorie Scrum. Scrum s'appuie sur l'intelligence collective des personnes qui l'utilisent. Plutôt que de donner aux gens des instructions détaillées, les règles de Scrum guident leurs relations et leurs interactions.

Différents processus, techniques et méthodes peuvent être utilisés au sein du cadre. Scrum englobe les pratiques existantes ou les rend superflues. Scrum rend visible l'efficacité relative du management actuel, de l'environnement et des techniques de travail, permettant ainsi d'apporter des améliorations.

Théorie Scrum

Scrum repose sur l'empirisme et le Lean Thinking. L'empirisme signifie que la connaissance provient de l'expérience et que les décisions sont prises sur la base d'observations. Le Lean Thinking réduit le gaspillage et se concentre sur l'essentiel.

Scrum utilise une approche itérative et incrémentale pour optimiser la prévisibilité et maîtriser les risques. Scrum s'appuie sur des groupes de personnes qui possèdent collectivement toutes les compétences et expertises nécessaires pour accomplir le travail, et qui partagent ou acquièrent ces compétences selon les besoins.

Scrum combine quatre Events formels d'inspection et d'adaptation au sein d'un Event englobant, le Sprint. Ces Events fonctionnent parce qu'ils mettent en œuvre les piliers empiriques de Scrum : Transparence, Inspection et Adaptation.

Transparence

Le processus en développement et le travail en cours doivent être visibles aussi bien pour ceux qui exécutent le travail que pour ceux qui le reçoivent. Dans Scrum, les décisions importantes sont basées sur l'état perçu de ses trois artefacts formels. Des artefacts peu transparents peuvent mener à des décisions qui diminuent la valeur et augmentent le risque.

La transparence permet l'inspection. Une inspection sans transparence est trompeuse et source de gaspillage.

Inspection

Les artefacts Scrum et la progression vers les objectifs convenus doivent être examinés fréquemment et soigneusement afin de détecter d'éventuels écarts ou problèmes indésirables. Pour faciliter cette inspection, Scrum propose 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 le changement.

Adaptation

Lorsque certains aspects d'un processus s'écartent des limites acceptables ou lorsque le produit résultant n'est pas acceptable, le processus appliqué ou les résultats produits doivent être adaptés. L'adaptation doit être effectuée le plus rapidement possible afin de minimiser les écarts supplémentaires.

L'adaptation devient plus difficile lorsque les personnes impliquées ne sont pas habilitées (empowered) ou ne peuvent pas s'auto-gérer. On attend d'une Scrum Team qu'elle s'adapte dès qu'elle apprend quelque chose de nouveau grâce à l'inspection.

Valeurs Scrum

L'application réussie de Scrum dépend de la capacité des personnes à vivre de mieux en mieux cinq valeurs :

• Engagement
• Focus
• Ouverture
• Respect
• Courage

L'équipe Scrum s'engage à atteindre ses objectifs et à se soutenir mutuellement. Son focus principal est le travail du Sprint, afin de réaliser les meilleurs progrès possibles 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 compétentes et autonomes, et sont également respectés en tant que tels par les personnes avec lesquelles ils travaillent. Les membres de l'équipe Scrum ont le courage de faire ce qui est juste : travailler sur des problèmes difficiles.

Ces valeurs donnent à l'équipe Scrum la direction à suivre en ce qui concerne son travail, ses actions et son comportement. Les décisions prises, les étapes entreprises et la manière dont Scrum est appliqué devraient renforcer ces valeurs, et non les diminuer ou les saper. Les membres de l'équipe Scrum apprennent et explorent les valeurs en travaillant avec les événements et les artefacts de 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 et construisent la confiance.

Scrum Team

L'élément central de Scrum est une petite équipe de personnes, une Scrum Team. La Scrum Team se compose d'un·e Scrum Master, d'un·e Product Owner et de Developer·euse·s. Au sein d'une Scrum Team, il n'y a ni sous-équipes ni hiérarchies. Il s'agit d'une unité cohésive de professionnels qui se concentrent sur un seul objectif, le Produkt-Ziel.

Les Scrum Teams sont interdisciplinaires, c'est-à-dire que les membres possèdent toutes les compétences nécessaires pour créer de la valeur à chaque Sprint. Elles s'autogèrent également, c'est-à-dire qu'elles décident en interne qui fait quoi, quand et comment.

La Scrum Team est suffisamment petite pour rester agile et suffisamment grande pour accomplir un travail significatif au cours d'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. Lorsque les Scrum Teams deviennent trop grandes, elles devraient envisager de se réorganiser en plusieurs Scrum Teams cohérentes, toutes concentrées sur le même produit. Elles devraient donc partager le Produkt-Ziel, le Product Backlog et le·la Product Owner.

La Scrum Team est responsable (responsible) 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 ce qui pourrait être nécessaire. Elle est structurée et habilitée par l'organisation pour gérer son propre travail. Travailler en Sprints à un rythme soutenable améliore la concentration et la continuité de la Scrum Team.

L'ensemble de la Scrum Team est redevable (accountable) de créer un Increment précieux et utile à chaque Sprint. Scrum définit trois responsabilités spécifiques au sein de la Scrum Team : les Developer·euse·s, le·la Product Owner et le·la Scrum Master.

Developer·euse·s

Les Developer·euse·s sont les personnes de la Scrum Team qui s'engagent à créer chaque aspect d'un Increment utilisable à chaque Sprint.

Les compétences spécifiques requises des Developer·euse·s sont souvent variées et dépendent du contexte de travail. Cependant, les Developer·euse·s sont toujours redevables de :

• créer un plan pour le Sprint, le Sprint Backlog ;
• intégrer la qualité en respectant une Definition of Done ;
• adapter quotidiennement leur plan pour atteindre le Sprint-Ziel ; et
• se tenir mutuellement responsables en tant qu'expert·e·s.

Product Owner

Le·la Product Owner est redevable de maximiser la valeur du produit résultant du travail de la Scrum Team. La manière dont cela se fait peut varier considérablement selon l'organisation, la Scrum Team et l'individu.

Le·la Product Owner est également redevable d'une gestion efficace du Product Backlog, ce qui inclut :

• développer et communiquer explicitement le Produkt-Ziel ;
• créer et communiquer clairement les éléments du Product Backlog ;
• définir l'ordre des éléments du Product Backlog ; et
• s'assurer que le Product Backlog est transparent, visible et compris.

Le·la Product Owner peut effectuer les travaux mentionnés ci-dessus ou déléguer la responsabilité de leur exécution à d'autres. Quoi qu'il en soit, le·la Product Owner reste redevable.

Pour que le·la Product Owner réussisse, toute l'organisation doit respecter ses décisions. Ces décisions sont visibles dans le contenu et l'ordre du Product Backlog, ainsi que dans l'Increment vérifiable lors du Sprint Review.

Le·la Product Owner est une personne, pas un comité. Le·la 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·la Product Owner.

Scrum Master

Le·la Scrum Master est redevable de l'adoption de Scrum tel que défini dans le Scrum Guide. Il·elle y parvient en aidant tout le monde à comprendre la théorie et la pratique Scrum, tant au sein de la Scrum Team que dans l'organisation.

Le·la Scrum Master est redevable de l'efficacité de la Scrum Team. Il·elle y parvient en permettant à la Scrum Team d'améliorer ses pratiques dans le cadre du framework Scrum.

Les Scrum Masters sont de véritables leaders qui servent la Scrum Team et l'organisation dans son ensemble.

Le·la Scrum Master sert la Scrum Team de différentes manières, notamment en :

• coachant les membres de l'équipe sur l'autogestion et la collaboration interdisciplinaire ;
• aidant la Scrum Team à se concentrer sur la création d'Increments de haute valeur qui répondent à la Definition of Done ;
• faisant éliminer les obstacles (impediments) à la progression de la Scrum Team ; et
• s'assurant que tous les Events Scrum ont lieu, sont positifs, productifs et respectent la Timebox.

Le·la Scrum Master sert le·la Product Owner de différentes manières, notamment en :

• aidant à trouver des techniques pour définir efficacement le Produkt-Ziel et gérer le Product Backlog ;
• aidant la Scrum Team à comprendre la nécessité d'éléments du Product Backlog clairs et précis ;
• aidant à établir une planification produit empirique pour un environnement complexe ; et
• facilitant la collaboration avec les parties prenantes selon les souhaits ou les besoins.

Le·la Scrum Master sert l'organisation de différentes manières, notamment en :

• dirigeant, formant et coachant l'organisation dans l'adoption de Scrum ;
• planifiant et recommandant des adoptions de Scrum au sein de l'organisation ;
• aidant les employé·e·s et les parties prenantes à comprendre et à mettre en œuvre une approche empirique pour un travail complexe ; et
• éliminant les barrières entre les parties prenantes et les Scrum Teams.

Événements Scrum

Le Sprint est un conteneur pour tous les autres événements. Chaque événement Scrum est une occasion formelle d'inspecter et d'adapter les artefacts Scrum. Ces événements sont spécifiquement conçus pour créer la transparence nécessaire. Si un événement n'est pas réalisé comme prévu, on rate l'opportunité d'inspecter et de s'adapter. Les événements Scrum servent à 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 au même endroit pour réduire la complexité.

Le Sprint

Les Sprints sont le battement de cœur de Scrum, là où les idées se transforment en valeur.

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

Tout le travail nécessaire pour atteindre l'Objectif de Produit, y compris le Sprint Planning, les Daily Scrums, la Sprint Review et la Sprint Retrospective, a lieu pendant les Sprints.

Pendant le Sprint

• aucun changement susceptible de mettre en danger l'Objectif du Sprint n'est effectué ;
• la qualité ne diminue pas ;
• le Product Backlog est affiné selon les besoins ; et
• le périmètre peut être clarifié et renégocié avec le Product Owner au fur et à mesure que de nouvelles connaissances émergent.

Les Sprints permettent la prévisibilité en garantissant l'inspection et l'adaptation des progrès vers un Objectif de Produit au moins une fois par mois calendaire. Lorsque l'horizon d'un Sprint est trop long, l'Objectif du Sprint peut devenir obsolète, la complexité peut augmenter et le risque peut croître. Des Sprints plus courts peuvent être utilisés pour générer plus de cycles d'apprentissage et limiter le risque de coûts et d'efforts à une période plus courte. Chaque Sprint peut être considéré comme un projet court.

Il existe diverses pratiques pour prévoir les progrès, comme les graphiques Burn-Down, les graphiques Burn-Up ou les diagrammes de flux cumulés. Bien qu'elles se soient révélées utiles, elles ne remplacent pas l'importance de l'empirisme. Dans les environnements complexes, ce qui va se passer est inconnu. Seul ce qui s'est déjà produit peut servir à 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

Le Sprint Planning lance le Sprint en définissant le travail à réaliser pendant 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 de leur lien avec l'Objectif de Produit. L'équipe Scrum peut également inviter d'autres personnes à participer au Sprint Planning à des fins de conseil.

Le Sprint Planning aborde les sujets suivants :

Sujet un : Pourquoi ce Sprint a-t-il de la valeur ?

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

Sujet deux : Que peut-on accomplir (Done) pendant ce Sprint ?

En discussion avec le Product Owner, les Developers 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.

Choisir combien peut être accompli pendant un Sprint peut représenter un défi. Cependant, plus les Developers en savent sur leurs performances passées, leur capacité future et leur Definition of Done, plus ils seront confiants dans leurs prévisions de Sprint.

Sujet trois : Comment le travail sélectionné sera-t-il réalisé ?

Pour chaque élément du Product Backlog sélectionné, les Developers planifient le travail nécessaire pour créer un Increment conforme à la Definition of Done. Cela se fait souvent en décomposant les éléments du Product Backlog en unités de travail plus petites d'une journée ou moins. La façon dont cela se fait relève de la seule discrétion des Developers. Personne d'autre ne leur dit comment transformer les éléments du Product Backlog en Increments de valeur.

L'Objectif du Sprint, les éléments du Product Backlog sélectionnés pour le Sprint et le plan pour leur livraison sont collectivement appelés Sprint Backlog.

Le Sprint Planning est limité à 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 (ou Daily Stand-up) est d'inspecter les progrès vers l'Objectif du Sprint et d'adapter le Sprint Backlog si nécessaire pour ajuster le travail planifié à venir.

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

Les Developers peuvent choisir 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 actionnable pour la journée de travail suivante. Cela crée du focus et favorise l'autogestion.

Les Daily Scrums améliorent la communication, identifient les obstacles, favorisent la prise de décision rapide et éliminent systématiquement le besoin d'autres réunions.

Le Daily Scrum n'est pas la seule occasion pour les Developers d'ajuster leur plan. Ils se réunissent souvent pendant la journée pour des discussions plus détaillées sur l'adaptation ou la replanification du travail restant 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 de Produit sont discutés.

Pendant l'événement, l'équipe Scrum et les parties prenantes examinent ce qui a été accompli pendant 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 saisir de nouvelles opportunités. La Sprint Review est une session de travail, et l'équipe Scrum devrait éviter de la limiter à une présentation.

La Sprint Review est l'avant-dernier événement du Sprint et est limitée à un maximum de quatre heures pour un Sprint d'un mois. Pour des Sprints plus courts, l'événement est généralement plus court.

Sprint Retrospective

L'objectif de la Sprint Retrospective est de planifier des moyens d'améliorer la qualité et l'efficacité.

L'équipe Scrum inspecte comment le dernier Sprint s'est déroulé en ce qui concerne les individus, les interactions, les processus, les outils et sa Definition of Done. Les éléments inspectés varient souvent selon le domaine de travail. Les hypothèses qui ont induit l'équipe en erreur sont identifiées et leurs origines explorées. L'équipe Scrum discute de ce qui s'est bien passé pendant le Sprint, des problèmes rencontrés et de la façon dont ces problèmes ont été résolus (ou non).

L'équipe Scrum identifie les changements les plus utiles pour améliorer son efficacité. Les améliorations les plus impactantes sont abordées dès que possible. Elles peuvent même être ajoutées au Sprint Backlog du prochain Sprint.

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

Artefacts Scrum

Les artefacts de Scrum représentent le travail ou la valeur. Ils sont conçus pour maximiser la transparence des informations clés. Ainsi, toutes les personnes qui les examinent disposent de la même base pour les adaptations.

Chaque artefact comprend un engagement pour s'assurer que des informations sont fournies, améliorant la transparence et le focus, afin de rendre les progrès mesurables :

• Pour le Product Backlog, c'est l'Objectif de Produit.
• Pour le Sprint Backlog, c'est l'Objectif de Sprint.
• Pour l'Increment, c'est la Definition of Done.

Ces engagements servent à renforcer l'empirisme et les valeurs Scrum pour l'équipe Scrum et ses parties prenantes.

Product Backlog

Le Product Backlog est une liste émergente et ordonnée de ce qui est nécessaire pour améliorer le produit. C'est la seule source de travail réalisé par l'équipe Scrum.

Les éléments du Product Backlog qui peuvent être terminés (Done) par l'équipe Scrum au cours d'un Sprint sont considérés comme prêts pour la sélection lors d'un événement de Sprint Planning. Ils atteignent généralement ce degré de transparence grâce aux activités de refinement. Le refinement du Product Backlog est le processus par lequel les éléments du Product Backlog sont décomposés en éléments plus petits et plus précis, puis définis davantage. C'est une activité continue par laquelle des détails supplémentaires comme la description, l'ordre et la taille sont ajoutés. Les attributs varient souvent selon l'environnement de travail.

Les Developers qui réaliseront le travail sont responsables de l'estimation de la taille. Le Product Owner peut influencer les Developers en les aidant à comprendre les éléments du Product Backlog et à faire des compromis.

Engagement : Objectif de Produit

L'Objectif de Produit décrit un état futur du produit qui peut servir de cible de planification pour l'équipe Scrum. L'Objectif de Produit se trouve dans le Product Backlog. Le reste du Product Backlog émerge pour définir « ce qui » permettra d'atteindre l'Objectif de Produit.

Un produit est un moyen de livrer de la valeur. Il a des limites claires, des parties prenantes connues, des utilisateurs ou clients clairement définis. Un produit peut être un service, un produit physique ou quelque chose de plus abstrait.

L'Objectif de Produit est l'objectif à long terme de l'équipe Scrum. L'équipe Scrum doit atteindre (ou abandonner) un objectif avant de passer au suivant.

Sprint Backlog

Le Sprint Backlog se compose de l'Objectif de Sprint (Pourquoi), des éléments du Product Backlog sélectionnés pour le Sprint (Quoi) et d'un plan actionnable pour la livraison de l'Increment (Comment).

Le Sprint Backlog est un plan créé par et pour les Developers. C'est une image en temps réel, clairement visible, du travail que les Developers prévoient d'accomplir pendant le Sprint pour atteindre l'Objectif de Sprint. Par conséquent, le Sprint Backlog est mis à jour tout au long du Sprint à mesure que de nouveaux apprentissages émergent. Il doit contenir suffisamment de détails pour qu'ils puissent examiner leur progression lors du Daily Scrum.

Engagement : Objectif de Sprint

L'Objectif de Sprint est l'unique objectif du Sprint. Bien que l'Objectif de Sprint soit un engagement des Developers, il offre de la flexibilité quant au travail exact nécessaire pour l'atteindre. L'Objectif de Sprint crée également de la cohérence et du focus, encourageant ainsi l'équipe Scrum à travailler ensemble plutôt que sur des initiatives séparées.

L'Objectif de Sprint est créé lors de l'événement de Sprint Planning, puis ajouté au Sprint Backlog. Pendant que les Developers travaillent au cours du Sprint, ils gardent l'Objectif de Sprint à l'esprit. S'il s'avère que le travail diffère de leurs attentes, ils collaborent avec le Product Owner pour négocier le périmètre du Sprint Backlog au sein du Sprint, sans affecter l'Objectif de Sprint.

Increment

Un Increment est un pas concret vers l'Objectif de Produit. Chaque Increment s'ajoute à tous les Increments précédents et est rigoureusement vérifié pour s'assurer qu'ils fonctionnent tous ensemble. Pour apporter de la valeur, l'Increment doit être utilisable.

Plus d'un Increment peut être créé au cours d'un Sprint. Leur somme est présentée lors du Sprint Review, ce qui soutient l'empirisme. Cependant, un Increment pourrait également être livré aux parties prenantes avant la fin du Sprint. Le Sprint Review ne devrait jamais être considéré comme une barrière à la livraison de valeur.

Le travail ne peut pas être considéré comme faisant partie d'un Increment tant qu'il ne répond pas à la Definition of Done.

Engagement : Definition of Done

La Definition of Done est une description formelle de l'état de l'Increment lorsqu'il répond aux mesures de qualité requises pour le produit.

Au moment où un élément du Product Backlog répond à la Definition of Done, un Increment naît.

La Definition of Done crée de la transparence en donnant à tous une compréhension commune du travail accompli dans le cadre de l'Increment. Si un élément du Product Backlog ne répond pas à la Definition of Done, il ne peut être ni releasé ni présenté lors du Sprint Review. Il retourne plutôt dans le Product Backlog pour une considération future.

Si la Definition of Done pour un Increment fait partie des standards de l'organisation, toutes les équipes Scrum doivent la suivre comme minimum. Si ce n'est pas un standard organisationnel, l'équipe Scrum doit créer une Definition of Done appropriée pour le produit.

Les Developers doivent respecter la Definition of Done. Si plusieurs équipes Scrum travaillent ensemble sur un produit, elles doivent définir une Definition of Done commune et toutes s'y conformer.

Remarque finale

Scrum est gratuit et proposé dans ce guide. Le cadre Scrum, tel qu'il est décrit ici, est immuable. Bien qu'il soit possible de n'implémenter que certaines parties de Scrum, le résultat n'est pas Scrum. Scrum n'existe que dans sa totalité et fonctionne bien comme conteneur pour d'autres techniques, méthodologies et pratiques.

Remerciements

Personnes
Parmi les milliers de personnes qui ont contribué à Scrum, nous devrions mettre en avant celles qui ont été particulièrement importantes au début : Jeff Sutherland a travaillé avec Jeff McKenna et John Scumniotales, et Ken Schwaber a travaillé avec Mike Smith ainsi que Chris Martin - et ils ont tous travaillé ensemble. Beaucoup d'autres ont apporté leur contribution au cours des années suivantes. Sans leur aide, Scrum ne serait pas aussi abouti qu'il l'est aujourd'hui.

Historique du Scrum Guide
Ken Schwaber et Jeff Sutherland ont présenté Scrum ensemble pour la première fois à la conférence OOPSLA en 1995. Cette présentation documentait essentiellement les enseignements que Ken et Jeff avaient acquis au cours des années précédentes en appliquant Scrum, et représentait la première publication formelle de la définition de Scrum.

Le Scrum Guide documente Scrum tel qu'il a été développé, a évolué et a été maintenu par Jeff Sutherland et Ken Schwaber pendant plus de 30 ans. D'autres sources fournissent des modèles, des processus et des enseignements qui complètent le cadre Scrum. Ceux-ci peuvent contribuer à améliorer la productivité, la valeur, la créativité et la satisfaction vis-à-vis des résultats.

L'histoire complète de Scrum est décrite ailleurs. Pour honorer les premiers lieux où il a été testé et a fait ses preuves, nous reconnaissons Individual Inc., Newspage, Fidelity Investments et IDX (maintenant GE Medical) comme tels.

© 2020 Ken Schwaber and Jeff Sutherland

This publication is offered for license under the Attribution Share-Alike license of Creative Commons, accessible at https://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at https://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Les modifications par rapport à la version 2017 ont été résumées par Sohrab Salimi, le CEO de la Scrum Academy.

Cette version (3.2) est une traduction entièrement nouvelle à l'occasion de la publication du Scrum Guide 2020. Date : 03.12.2020

Traduction

Ce guide a été traduit à partir de la version originale anglaise, fournie par Ken Schwaber et Jeff Sutherland. Y ont contribué :
2020 : Silke von der Bruck, Sabine Canditt, Jan Gretschuskin, Eva Gysling, Martin Hoppacher, Björn Jensen, Ralph Jocham, Dominik Maximini, Wolf Dieter Moggert, Peter Schmidt, Boris Steiner