En juillet 2011, Ken Schwaber et Jeff Sutherland ont édité une nouvelle version du Scrum Guide. Ce “Scrum Body of Kowledge” a l’air anodin, mais de mon point de vue, celu-ci annonce de profond changement dans le “framework”.
Lors de la sortie du Scrum Guide, la réaction a été vive et les débats sulfureux dans les listes de discussions. Scrum est en amélioration permanente, pourquoi cette version serait-elle différente des autres?
Le contexte est tendu dans le milieu des coaches et des trainers certifiés par la Scrum Alliance: abandon des certifications par Tobias Mayer et Boris Gloger; luttes entre Scrum Alliance et Scrum.org... en fin, de l’humain.. quoi!!! Stuckmann dirait que nous sommes étions en phase “storming”,
Ce Scrum Guide a été co-écrit par Schwaber et Sutherland, nos deux somités avaient déjà la capacité de calmer les esprits les plus échaufés (et il y a du lourd là dessous). Donc, cet écrit n’est pas anodin. Stuckmann dirait que nous abordons la phase “norming”.
M’étant engagé lors de l’Agile Tour de dispenser des Master Classes sur Scrum 2.0 et, après avoir revu mes formations Scrum et les ayant testé avec mes clients (les pauvres!), je me suis permis de faire une traduction non-officielle de ce Scrum Guide 2011 et je vous invite à la découvrir ci-dessous mon incrément de mon inspect-and-adapt:
Le Scrum Guide, Les régles du Jeu (adaptation P.Neis)
Parmi les milliers de personnes qui ont contribué à Scrum, nous devrions distinguer ceux qui ont contribué à ses dix premières années. D’abord, il y a eu Jeff Sutherland travaillant avec Jeff McKenna, et Ken Schwaber travaillant avec Mike Smith et Chris Martin.
Beaucoup d'autres ont contribué les années suivantes et, sans leur aide Scrum ne se serait pas affiné tel qu‘il est aujourd'hui.
David Starr a fourni des informations clés et des compétences rédactionnelles dans la formulation de cette version du Guide de Scrum.
Historique
Au début, Ken Schwaber et Jeff Sutherland ont co-présenté Scrum à la conférence OOPSLA en 1995.
Cette présentation était essentiellement documentée par l'apprentissage de la mise en application de Scrum que Ken et Jeff ont eu au cours des quelques années précédentes.
L’histoire de Scrum est déjà considérée comme longue.
Pour honorer les premiers endroits où il a été testé et amélioré, nous remercions Individuals Inc, Fidelity Investments, et IDX (maintenant GE Medical).
Les Révisions
L’édition du Scrum Guide de Juillet 2011 est différente de son prédécesseur l’édition de février 2010.
En particulier, nous avons tenté d'enlever des techniques ou des bonnes pratiques du cœur de Scrum.
Celles-ci varient en fonction des circonstances. Nous démarrerons un recueil de "Best Practices" pour offrir certaines de nos expériences ultérieurement.
Le Scrum Guide documente Scrum tel qu’il a été développé et entretenu pendant vingt ans et + par Jeff Sutherland et Ken Schwaber.
D'autres sources vous fourniront des modèles, des processus, et des idées dont les pratiques, les facilitations et les outils qui complètent le cadre Scrum.
Cela pour optimiser la productivité, la valeur, la créativité et la fierté.
Les notes de version couvrant les différences entre celle-ci et la version de Février 2010 sera publié ultérieurement, y compris des discussions sur
1. Release Planning
2. Release Burndown
3. Sprint Backlog
4. Product et Sprint Backlog Burndown
5. L’engagement est maintenant l’estimation
6. Team (to Development Team)
7. Pigs and Chickens … le savoir de Scrum
8. Ordonné au lieu de priorisé
Objectif du Scrum Guide
Scrum est un cadre pour l'élaboration et le maintien des produits complexes.
Ce guide contient la définition de Scrum.
Cette définition comprend les rôles Scrum, les événements, les artefacts et les règles qui les unissent.
Ken Schwaber et Jeff Sutherland ont développés Scrum; le Scrum Guide est écrit et fournis par eux.
Ensemble, ils se tiennent derrière le Scrum Guide.
Aperçu de Scrum
Scrum (nm): Un cadre dans lequel les gens peuvent aborder des problèmes complexes adaptatifs, tandis que productivité et créativité offrent des produits de la valeur la plus élevée possible.
Scrum est:
· Léger
· Simple à comprendre
· Extrêmement difficile à maîtriser
Scrum est un cadre de processus qui a été utilisé pour gérer le développement de produits complexes depuis le début des années 1990.
Scrum n'est pas un processus ou une technique pour construire des produits; c'est plutôt un cadre dans lequel vous pouvez utiliser divers procédés et techniques.
Scrum met en évidence l'efficacité relative de la gestion de vos produits et des pratiques de développement de sorte que vous pouvez améliorer.
Le cadre de Scrum
Le cadre de Scrum se compose des Scrum Teams et de leurs rôles associés, des événements, des artefacts et des règles.
Chaque composant dans ce cadre sert un but spécifique et est essentiel à la réussite et de l’usage de Scrum.
Des stratégies spécifiques pour l'utilisation du cadre Scrum varient et sont décrits par ailleurs.
Les règles de Scrum lient les événements, les rôles et les artefacts, qui régissent les relations et les interactions entre eux.
Les règles de Scrum sont décrites dans le corps du présent document.
Scrum, la théorie
Scrum est fondé sur la théorie de contrôle des processus empiriques, ou l'empirisme.
L'empirisme affirme que la connaissance vient de l'expérience et de la prise de décision basée sur ce qui est connu.
Scrum utilise une approche itérative et incrémentale pour optimiser la prévisibilité et la maîtrise des risques.
Trois piliers supportent chaque implémentation du contrôle des processus empiriques : la transparence, l’inspection et l’adaptation.
La transparence,
Les aspects importants du processus doivent être visibles pour les responsables du résultat.
La transparence exige que ces aspects soient définis par une norme commune de sorte que les observateurs partagent une compréhension commune de ce qui est vu.
Par exemple :
- Une langue commune se référant au processus doit être partagée entre tous les participants, et,
- Une définition commune du "Done" doit être partagée par ceux qui effectuent le travail et ceux qui acceptent le produit du travail.
L’inspection,
Les utilisateurs de Scrum doivent inspecter fréquemment.
Les Artefacts de Scrum mesurent le progrès vers un objectif de détecter les écarts indésirables, leur inspection ne doit pas être si fréquente de sorte que l'inspection soit la façon d’agir.
Les inspections sont plus bénéfiques quand elles sont diligentées par des inspecteurs qualifiés sur le point de travail.
Et l’adaptation
Si l'inspecteur détermine que un ou plusieurs aspects d'un processus s'écarte des limites acceptables, et que le produit résultant sera inacceptable, le processus ou le matériel en cours de traitement doit être ajusté.
Un ajustement doit être effectué dès que possible afin de minimiser l'écart d'autres.
Scrum prescrit quatre occasions formelles pour l'inspection et l'adaptation, tel que décrit dans la section Événements Scrum de ce document
- Sprint Planning Meeting
- Daily Scrum
- Sprint Review Meeting
- Sprint Rétrospective
Scrum
Scrum est un cadre structuré pour soutenir le développement de produits complexes.
Scrum se compose d'équipes Scrum et leurs rôles associés, des événements, des artefacts et des règles.
Chaque composant dans le cadre sert un but spécifique et est essentiel à la réussite et l’usage de Scrum.
Les règles de Scrum lient les événements, les rôles et les artefacts, qui régissent les relations et les interactions entre eux.
Les règles de Scrum sont décrites tout au long du présent document.
La Scrum Team
La Scrum Team est constituée d’un Product Owner, d’une Development Team, et d’un Scrum Master.
Les Scrum Teams sont autogérées et inter-fonctionnelles (transverses).
Les équipes autogérées choisissent la meilleure façon d'accomplir leur travail, plutôt que d'être dirigées par d'autres en dehors de l'équipe.
Les Équipes inter-fonctionnelles ont toutes les compétences nécessaires pour accomplir le travail sans dépendre des autres ne faisant pas partie de l'équipe.
Le modèle d'équipe dans Scrum est conçu pour optimiser la flexibilité, la créativité et la productivité.
Les Scrum Teams livrent des produits de façon itérative et incrémentale, en maximisant les possibilités de feedback.
Les livraisons incrémentales de produit "Done" assurent qu’une version potentiellement utile du produit qui fonctionne est toujours disponible.
Le Product Owner
Le Product Owner est responsable pour maximiser la valeur du produit et le travail de la Development Team.
Comment cela se fait peut varier considérablement selon les organisations, les Scrum Teams, et les individus.
Le Product Owner est la seule personne responsable de la gestion du Product Backlog.
La gestion du Product Backlog comprend:
- Exprimer clairement les éléments du Product Backlog;
- Ordonner les éléments du Product Backlog pour mieux atteindre les objectifs et les missions ;
- Assurer la valeur du travail réalisée par la Development Team;
- Assurer que le Product Backlog, est transparent et clair pour tous, et montrer ce sur quoi la Scrum Team va travailler la prochaine fois et,
- Assurer que la Development Team comprend les éléments dans le Product Backlog au niveau nécessaire.
Le Product Owner peut faire le travail ci-dessus, ou avoir la Development Team qui le fait. Toutefois, le Product Owner demeure responsable.
Le Product Owner est une personne, pas un comité.
Le Product Owner peut représenter les désirs d'un comité dans le Product Backlog, mais ceux qui veulent changer la priorité d'un élément de Backlog doivent convaincre le Product Owner.
Pour que Product Owner réussisse, toute l’organisation doit respecter ses décisions.
Les décisions du Product Owner sont visibles dans le contenu et l'ordonnancement du Product Backlog.
Personne n'est autorisé à dire à la Development Team de travailler à partir d'un ensemble d’exigences différentes, et la Development Team n'est pas autorisée à agir sur ce que quelqu'un d'autre dit.
La Development Team
La Development Team se compose de professionnels qui font le travail de fournir un incrément potentiellement libérable de produit "Done" à la fin de chaque Sprint.
Seuls les membres de la Development Team créent l'incrément.
Les Development Teams sont structurées et habilitées par l'organisation pour organiser et gérer leur propre travail.
La synergie résultante optimise l'efficacité globale de la Development Team et son efficacité.
Les Development Teams ont les caractéristiques suivantes:
Elles sont auto-organisées. Personne (pas même le Scrum Master) dit à la Development Team la façon de tourner Product Backlog en incréments de fonctionnalités potentiellement libérable.
Les Development Teams sont transverses, avec toutes les compétences nécessaires à l’équipe pour créer un incrément du produit.
Scrum ne reconnaît pas les titres des membres de la Development Team autres que développeur, quel que soit le travail effectué par la personne, il n'y a aucune exception à cette règle.
Les membres individuels de la Development Team peuvent avoir des compétences spécialisées et expertises domaine, mais la responsabilité appartient à la Development Team dans son ensemble et, la Development Team ne contient pas de sous-équipes dédiées à des domaines particuliers comme les tests ou des analyses fonctionnelles.
La taille optimale de la Development Taille de la Development Team
Team est assez petite pour rester agile et assez grande pour terminer un travail important.
Moins de trois membres diminuent l'interaction et des résultats en gains de productivité moindre. Les petites Development Teams peuvent rencontrer des contraintes de compétences pendant le Sprint, entrainant l’incapacité de la Development Team de délivrer un incrément potentiellement livrable.
Avec plus de neuf membres cela nécessite trop de coordination.
De grandes Development Teams génèrent trop de complexité à gérer pour un processus empirique.
Les rôles de Product Owner et de Scrum Master ne sont pas inclus dans ce décompte sauf s’ils contribuent dans l’exécution des travaux du Sprint Backlog.
Le Scrum Master
Le Scrum Master est chargé de veiller à ce que Scrum soit compris et adopté.
Le Scrum Master le fait en veillant à ce que la Scrum Team adhère à la théorie Scrum, ses pratiques et ses règles.
Le Scrum Master est un servant-leader pour la Scrum Team.
Le Scrum Master aide ceux qui se trouvent à l’extérieur de la Scrum Team à comprendre lesquelles de leurs interactions aident et lesquelles n’aident pas.
Le Scrum Master permet à chacun de modifier ces interactions afin de maximiser la valeur créée par l'équipe Scrum.
Le Scrum Master pour le Product Owner
Le Scrum Master sert le Product Owner de plusieurs manières, y compris
- Trouver des techniques pour la gestion efficace du Product Backlog ;
- Communiquer clairement la Vision, les objectifs et les éléments du Product Backlog à la Development Team;
- Éduquer la Development Team pour créer des éléments clairs et concis du Product Backlog;
- Comprendre la planification des produits à long terme dans un environnement empiriques;
- Comprendre et pratiquer l'agilité et,
- Faciliter les évènements Scrum comme demandés ou nécessaires.
Le Scrum Master pour la Development Team
Le Scrum Master sert la Development Team de plusieurs façons, y compris
- Coaching la Development Team en autogestion et transversalité;
- Éduquer et leader la Development Team pour créer des produits de forte valeur;
- Supprimer les obstacles au progrès de la Development Team;
- Faciliter les évènements Scrum comme demandés ou nécessaires et,
- Coacher la Development Team dans des environnements organisationnels dans lesquels Scrum n'est pas encore totalement adopté et compris.
Le Scrum Master pour l’Organisation
Le Scrum Master sert l’Organisation de plusieurs façons, y compris
- Diriger et coacher l'organisation dans son adoption de Scrum;
- Planifier des implémentations Scrum au sein de l'organisation;
- Aider les employés et les intervenants à comprendre et à adopter Scrum et le développement de produits empirique;
- Provoquer des changements qui augmentent la productivité de l'équipe Scrum et,
- Travailler avec d'autres Scrum Masters pour accroître l'efficacité de l'application de Scrum dans l'organisation.
Les évènements Scrum
Des événements prescrits sont utilisés dans Scrum afin de créer la régularité et de minimiser le besoin pour les réunions pas définies dans Scrum.
Scrum utilise des évènements time-boxés, de telle sorte que chaque événement a une durée maximale.
Cela garantit une quantité appropriée de temps consacrée à la planification, sans permettre des déchets dans le processus de planification.
Autre que le sprint lui-même, qui est un conteneur pour tous les autres événements, chaque événement dans Scrum est une opportunité d'inspecter et d'adapter quelque chose.
Ces événements sont spécifiquement conçus pour permettre la transparence critique et l'inspection.
L'omission d'inclure un de ces événements induit la réduction de la transparence et une occasion perdue pour inspecter et d'adapter.
Le Sprint
Le cœur de Scrum est un sprint, une time-box d'un mois ou moins au cours de laquelle un incrément produit « Done", utilisable et potentiellement livrable est créé.
Les Sprints ont une durée consistante en adéquation avec un effort de développement.
Un nouveau Sprint commence immédiatement après la conclusion du précédent Sprint.
Les Sprints contiennent et se composent du Sprint Planning, des Daily Scrums, le travail de développement, de la Sprint Review, et la Sprint Rétrospective.
Pendant le Sprint
Aucune modification n'est apportée qui pourraient affecter l'objectif de Sprint.
La composition de la Development Team et les objectifs de qualité restent constants et, le cadre peut être clarifié et renégocié entre le Product Owner et la Development Team au fur et à mesure des connaissances acquises.
Chaque Sprint peut être considéré comme un projet avec un horizon d'un mois.
Comme les projets, les sprints sont utilisés pour accomplir quelque chose, chaque Sprint a une définition de ce qui doit être construit, un plan de conception flexible qui guidera sa construction, le travail, et le produit résultant.
Les Sprints sont limités à un mois.
Lorsque l'horizon d'un Sprint est trop long, la définition de ce qui se construit peut changer, la complexité peut augmenter, et le risque peut augmenter.
Les Sprints permettent la prévisibilité en assurant l'inspection et l'adaptation de progrès vers un objectif d’au moins tous les mois du calendrier.
Les Sprints limitent aussi le risque financier d'un mois calendaire.
Annulation d’un Sprint
Un Sprint peut être annulé avant la fin de la Sprint time-box.
Seul le Product Owner a le pouvoir d'annuler le sprint, même si il ou elle peut le faire sous l'influence des parties prenantes, la Development Team, ou le Scrum Master.
Un Sprint serait annulé si l’objectif de Sprint devient obsolète.
Cela peut se produire si l'entreprise change de direction ou s’il y a changement des conditions du marché ou la technologie.
En général, un Sprint devrait être annulé s’il n'a plus de sens étant donné les circonstances.
Mais, en raison de la courte durée des sprints, l'annulation fait rarement sens.
Quand un sprint est annulé, tout items de Product Backlog complets et « Done » sont passés en revue.
Si une partie du travail est potentiellement livrable, le Product Owner l’accepte généralement.
Tous les items incomplets du Product Backlog sont ré-estimés et remis dans le Product Backlog. Le travail effectué sur les items se déprécie rapidement et ceux-ci doivent être fréquemment ré-estimés.
Les annulations de Sprint consomment des ressources, étant donné que chacun doit se regrouper dans une autre Sprint Planning Meeting pour lancer un autre Sprint.
Les annulations de Sprint sont souvent traumatisantes pour la Scrum Team, et donc très rares.
Sprint Planning Meeting
Les travaux à effectuer dans le Sprint sont prévus au Sprint Planning Meeting.
Ce plan est créé avec la collaboration de toute la Scrum Team.
Le Sprint Planning Meeting est time-boxé à huit heures pour un sprint d'un mois.
- Pour les Sprints courts, l'événement est proportionnellement plus court.
- Par ex., des Sprints de 2 semaines ont des Sprint Planning Meetings de 4 heures.
Le Sprint Planning Meeting se compose de deux parties, chacune étant une fois la moitié de la durée de la time-box du Sprint Planning Meeting.
Les deux parties du Sprint Planning Meeting répondent aux questions suivantes, respectivement :
- Qu’est-ce qui sera livré dans l’incrément résultant su Sprint?
- Quel sera le travail nécessaire pour que l’incrément soit réalisé?
Part 1: Qu’est-ce qui sera livré dans l’incrément résultant su Sprint?
Dans cette partie, la Development Team travaille pour prévoir les fonctionnalités qui seront développées au cours du Sprint.
Le Product Owner présente les items du Product Backlog ordonnés à la Development Team et toute la Scrum Team collabore à la compréhension du travail du Sprint.
L’input de cette réunion est le Product Backlog, le dernier incrément produit, la capacité projetée de la Development Team au cours du Sprint, et le rendement passé de la Development Team.
Le nombre d’items sélectionnés à partir du Product Backlog pour le Sprint est à la seule appréciation de la Development Team.
Seule la Development Team peut évaluer ce qu'elle peut accomplir au cours des prochains Sprint.
Après, la Development Team prévoit les items du Product Backlog qu'elle livrera dans le Sprint, la Scrum Team conçoit un objectif de Sprint.
L'objectif de Sprint est un objectif qui sera atteint dans le Sprint grâce à la mise en œuvre du Product Backlog, il fournit des conseils à la Development Team, sur quoi elle construit de l'incrément.
Part 2: Quel sera le travail nécessaire pour que l’incrément soit réalisé?
Après avoir choisi le travail du Sprint, la Development Team décide comment elle va transformer cette fonctionnalité en un incrément de produit "Done" pendant le Sprint.
Les items de Product Backlog sélectionnés pour ce Sprint ainsi que le plan pour les livrer est appelé le Sprint Backlog,
La Development Team commence généralement par la conception du système et le travail nécessaire pour convertir le Product Backlog dans un incrément de produit qui fonctionne.
Le travail peut être de taille variable, ou d'effort estimé.
Cependant, assez de travail est prévu lors du Sprint Planning Meeting pour la Development Team pour prévoir ce qu'elle croit pouvoir faire dans le prochain Sprint.
Les travaux prévus par la Development Team pour les premiers jours du Sprint sont décomposés en unités d'une journée ou moins d'ici la fin de cette réunion.
La Development Team s'auto-organise pour entreprendre les travaux dans le Sprint Backlog, à la fois lors du Sprint Planning Meeting et au besoin tout au long du Sprint.
Le Product Owner peut être présent lors de la deuxième partie du Sprint Planning Meeting pour clarifier les éléments sélectionnés du Product Backlog et de contribuer à faire des compromis.
Si la Development Team détermine qu'elle a trop de travail ou trop peu, elle peut renégocier les items du Sprint Backlog avec le Product Owner.
La Development Team peut également inviter d'autres personnes à y assister afin de fournir des conseils techniques ou de domaine.
À la fin du Sprint Planning Meeting, la Development Team devrait être en mesure d'expliquer au Product Owner et au Scrum Master comment elle entend travailler en équipe autogérée pour atteindre l'objectif de Sprint et de créer l'incrément prévu.
L’objectif de Sprint
L'objectif de Sprint donne à la Development Team une certaine souplesse quant à la fonctionnalité implémentée dans le Sprint.
Tout au long de son travail, la Development Team garde cet objectif en tête.
Afin de satisfaire l'objectif de Sprint, elle implémente la fonctionnalité et la technologie.
Si le travail se révèle être différent de ce que la Development Team avait prévu, elle collabore avec le Product Owner pour négocier le scope du Sprint Backlog dans le Sprint.
L'objectif de Sprint peut être un jalon dans l'objectif plus général de la Product Roadmap.
Daily Scrum
Le Daily Scrum est une time-box de 15 minutes pour la Development Team pour synchroniser les activités et créer un plan pour les prochaines 24 heures.
Ceci est fait en inspectant les travaux depuis de dernier Daily Scrum et la prévision de travail qui pourrait être fait avant le prochain.
Le Daily Scrum est tenu au même moment et au même endroit chaque jour afin de réduire la complexité.
Pendant la réunion, chaque membre de la Development Team explique
- Qu'est-ce qui a été accompli depuis la dernière réunion?
- Quelles mesures seront prises avant la prochaine réunion?
- Quels sont les obstacles sur le chemin?
La Development Team utilise le Daily Scrum pour évaluer les progrès vers l‘objectif de Sprint et d'évaluer comment les progrès sont orientés vers la réalisation des travaux dans le Sprint Backlog.
Le Daily Scrum optimise la probabilité que la Development Team va atteindre l'objectif du Sprint.
La Development Team se retrouve souvent immédiatement après le Daily Scrum pour re-planifier le Sprint Backlog.
Chaque jour, la Development Team devrait être en mesure d'expliquer au Product Owner et au Scrum Master comment elle entend travailler ensemble comme une équipe autogérée pour atteindre l'objectif et de créer l'incrément prévu dans Sprint Backlog.
Le Scrum Master s'assure que la Development Team a tenu la réunion, mais la Development Team est chargée de mener le Daily Meeting.
Le Scrum Master enseigne à la Development Team de maintenir un Daily Scrum dans une time-box de 15-minutes.
Le Scrum Master applique la règle selon laquelle seuls les membres de la Development Team participent au Daily Scrum Meeting.
Le Daily Scrum n'est pas un point de situation, mais il est fait pour les personnes transformant les items du Product Backlog en un incrément.
Les Daily Scrums permettent d’améliorer la communication, d'éliminer les autres réunions, d'identifier et d'éliminer les obstacles au développement, à souligner et à promouvoir la prise de décision rapide, et améliorer le niveau de l'équipe de développement de la connaissance du projet.
C’est une réunion clé d’inspection et d’adaptation.
La Sprint Review
Un Sprint Review Meeting est tenu à la fin du Sprint pour inspecter l'incrément et adapter le Product Backlog si nécessaire.
Pendant le Sprint Review, la Scrum Team et les intervenants collaborent sur ce qui s’est fait dans le Sprint.
Basé sur cela, et tout changement du Product Backlog pendant le Sprint, les participants collaborent sur les prochaines choses qui pourraient être développées.
Ceci est une réunion informelle et la présentation de l'incrément qui est destinée à susciter des réactions et de favoriser la collaboration.
Ceci est une réunion time-boxée de 4 heures pour un Sprint d’un mois.
- Proportionnellement moins de temps est alloué pour des Sprints courts.
- Par exemple: un Sprint de deux semaines a une time-box de quatre heures pour la Sprint Review.
La Sprint Review comprend les éléments suivants
- Le Product Owner identifie ce qui a été "Done" et ce qui n'a pas été «Done»;
- la Development Team explique ce qui s'est bien passé pendant le Sprint, quels problèmes elle a été confrontée, et comment ces problèmes ont été résolus;
- la Development Team démontre le travail «Done» et répond aux questions sur incrément;
- le Product Owner discute du Product Backlog tel qu'il est.
- Il ou elle projette des dates prévisionnelles d’achèvement en fonction des progrès à ce jour, et,
- l'ensemble du groupe collabore sur ce qui est à faire ensuite, de sorte que la Sprint Review fournit une contribution précieuse aux futurs Sprint Planning Meetings.
Le résultat de la Sprint Review est un Product Backlog révisé qui définit les éléments probables du Product Backlog pour le prochain Sprint.
Le Product Backlog peut également être ajusté pour répondre à l'ensemble des nouvelles opportunités.
La Sprint Rétrospective
La rétrospective Sprint est une occasion pour la Scrum Team de s’inspecter et de créer un plan d'améliorations pour être promulguée au cours du Sprint suivant.
La Sprint Rétrospective survient après la Sprint Review et avant le Sprint Planning Meeting suivant.
C’est une time-box de trois heures pour un Sprint d’un mois
- Proportionnellement moins de temps est alloué pour des Sprints courts.
Le but de la Sprint Rétrospective est de
- Inspecter la manière dont le dernier Sprint s’est déroulé eut égard aux personnes, aux relations, aux processus et aux outils;
- Identifier et ordonner les items majeurs qui ont bien fonctionnés ainsi que les améliorations potentielles, et,
- La Création d'un plan de mise en œuvre des améliorations à la façon dont l'équipe Scrum fait son travail.
Le Scrum Master encourage la Scrum Team à s’améliorer dans le cadre du processus Scrum, son processus de développement et des pratiques pour le rendre plus efficace et agréable lors du prochain Sprint.
Lors de chaque Sprint Rétrospective, la Scrum Team planifie les moyens pour accroître la qualité des produits, en adaptant la définition de "Done", le cas échéant.
À la fin de la Sprint Rétrospective, la Scrum Team devrait avoir identifié les améliorations qu’elle mettra en œuvre dans le prochain Sprint.
La mise en œuvre de ces améliorations dans le prochain Sprint est l'adaptation et l'inspection de la Scrum Team elle-même.
Bien que des améliorations puissent être mises en œuvre à tout moment, la Sprint Rétrospective fournit un événement dédié axée sur l'inspection et l'adaptation.
Les Scrum Artefacts
Les Scrum artefacts représentent le travail ou la valeur de diverses façons qui sont utiles en matière de transparence et des possibilités de contrôle et d'adaptation.
Les artefacts définis par Scrum sont spécifiquement conçus pour maximiser la transparence de l'information, clé nécessaire pour assurer que les Scrum Teams ont réussi à fournir un incrément « Done ».
Le Product Backlog
Le Product Backlog est une liste ordonnée de tout ce qui pourrait être nécessaire dans le produit et est la source unique d'exigences pour toutes les modifications à apporter au produit.
Le Product Owner est responsable du Product Backlog, y compris de son contenu, de sa disponibilité et de son ordonnancement.
Un Product Backlog n’est jamais complet.
Les premiers développements n'établissent que les exigences initialement connues et les mieux comprises.
Le Product Backlog évolue comme le produit et l'environnement dans lequel il sera utilisé évolue.
Le Product Backlog est dynamique, il change constamment pour identifier ce que le produit a besoin pour être approprié, compétitif et utile.
Tant qu'un produit existe, un Product Backlog existe également.
Le Product Backlog répertorie toutes les caractéristiques, fonctions, besoins, des améliorations et des corrections qui constituent les changements à apporter au produit dans les versions futures.
Les items de Product Backlog ont les attributs d’une description, d’un ordre, et d’une estimation.
Le Product Backlog est souvent ordonné par valeur, risque, priorité et nécessité.
Les items de Product Backlog de haute priorité entraînement des activités de développement immédiates.
Plus l'ordre est élevé, plus un élément Product Backlog a été considéré, et plus il existe un consensus au sujet et sa valeur.
Les items de Product Backlog supérieurement ordonnés sont plus clairs et plus détaillés que ceux inférieurement ordonnés.
Des estimations plus précises sont faites sur la base de plus de clarté et augmenté de détails; plus bas l'ordre, le moins de détails il a.
Les items de Product Backlog qui vont occuper la Development Team pour le Sprint à venir sont à « grain fin », ayant été décomposés de sorte que tout élément peut être «Done» dans la time-box du Sprint.
Les items de Product Backlog qui peuvent être "Done" par la Development Team au sein d'un Sprint sont réputés « Ready » ou "actionnable" pour la sélection lors du Sprint Planning Meeting
Tant que le produit est utilisé et gagne de la valeur, et le marché fournit un feedback, le Product Backlog devient une liste plus grande et plus exhaustive.
Les exigences ne cessent jamais de changer, donc un Product Backlog est un artefact vivant.
Les changements dans les exigences opérationnelles, les conditions du marché, ou la technologie peut causer des changements dans le Product Backlog.
Plusieurs équipes Scrum travaillent souvent ensemble sur le même produit.
Un Product Backlog est utilisé pour décrire le travail à venir sur le produit.
Un Product Backlog attribue que les items des groupes sont alors employés.
Product Backlog Grooming
Le Product Backlog grooming est l'acte d'ajouter des détails, des estimations, et de l’ordre dans les items du Product Backlog.
Ceci est un processus continu dans lequel le Product Owner et la Development Team collaborent sur les détails des items Product Backlog.
Pendant Product Backlog grooming, les items sont examinés et révisés. Toutefois, ils peuvent être mis à jour à tout moment par le Product Owner ou à la discrétion du Product Owner.
Le Grooming est une activité à temps partiel pendant un Sprint entre le Product Owner et la Development Team.
Souvent, la Development Team a les connaissances du domaine pour effectuer elle-même le grooming.
Comment et quand le grooming est fait est décidé par la Scrum Team.
- Le Grooming consomme habituellement pas plus de 10% de la capacité de la Development Team.
- La Development Team est responsable de toutes les estimations.
- Le Product Owner peut influencer l'équipe en aidant à comprendre et sélectionner les arbitrages, mais les individus qui vont effectuer les travaux font l'estimation finale.
Suivi des progrès vers un objectif
A tout moment, le travail total restant pour atteindre un objectif peut être résumé.
Le Product Owner piste ce reste-à-faire total au moins pour chaque Sprint Review.
Le Product Owner compare ce montant avec le travail restant de la Sprint Review précédente afin de mesurer les progrès vers l'achèvement des travaux projetés par le temps désiré pour atteindre le but.
Cette information est rendue transparente à tous les intervenants.
Scrum ne considère pas le temps passé à travailler sur des éléments de Product Backlog.
Le reste-à-faire et la date sont les seules variables d'intérêt.
Diverses tendances de Burndown, de burnup et d'autres pratiques projectives ont été utilisées pour prévoir les progrès.
Celles-ci ont prouvé leur utilité. Cependant, elles ne remplacent pas l'importance de l'empirisme.
Dans les environnements complexes, ce qui va arriver est inconnu.
Seul ce qui est arrivé peut être utilisé pour une prise de décision prospective.
Sprint Backlog
Le Sprint Backlog est l'ensemble des items de Product Backlog sélectionnés pour le Sprint, plus un plan pour fournir l'incrément du produit et la réalisation de l'Objectif du Sprint.
Le Sprint Backlog est une prévision par la Development Team sur ce qui sera une fonctionnalité dans le prochain incrément et le travail nécessaire pour fournir cette fonctionnalité.
Le Sprint Backlog définit le travail que la Development Team produira pour transformer les items du Product Backlog en un incrément « Done ».
Le Sprint Backlog rend visible tout le travail que la Development Team identifie comme nécessaire pour atteindre l'objectif du Sprint.
Sprint Backlog est un plan avec suffisamment de détails pour que les changements en cours peuvent être compris lors du Daily Scrum.
La Development Team modifie le Sprint Backlog à travers le Sprint et le Sprint Backlog émerge au cours du Sprint.
Cette émergence se produit comme quand la Development Team travaille à travers le plan et en apprend davantage sur le travail nécessaire pour atteindre l'objectif du Sprint.
Quand un nouveau travail est nécessaire, la Development Team l’ajoute au Sprint Backlog.
Comme le travail est effectué ou terminé, le travail restant estimé est mis à jour.
Lorsque les éléments du plan sont jugées inutiles, ils sont retirés.
Seule la Development Team peut changer son Sprint Backlog lors d'un Sprint.
Le Sprint Backlog est une image du travail très visible, en temps réel que l'équipe de développement des plans pour réaliser au cours du sprint, et il appartient exclusivement à la Development Team.
Surveillance du progrès du Sprint
A tout moment, dans un sprint, le total du reste-à-faire dans les items de Sprint Backlog peut être additionné.
La Development Team piste ce total du reste-à-faire au mieux lors tous les Daily Scrums.
La Development Team piste ces sommes quotidiennement et projette la probabilité d'atteindre l'Objectif de Sprint.
En suivant les travaux restants tout au long du Sprint, la Development Team peut gérer ses progrès.
Scrum ne considère pas le temps passé à travailler sur les items de Sprint Backlog.
Le reste-à-faire et la date sont les seules variables d'intérêt.
Incrément
L'incrément est la somme de tous les éléments du Product Backlog complété au cours d'un Sprint et tous les Sprints précédents.
A la fin d'un Sprint, le nouvel incrément doit être « Done », ce qui signifie qu'il doit être en état d’usabilité et répond à la définition of « Done » de la Scrum Team.
Il doit être en état d’usabilité indépendamment du fait que le Product Owner décide de le livrer.
Définition of « Done »
Lorsque le Product Backlog item ou un incrément est désigné comme « Done », chacun doit comprendre ce que «Done» signifie.
Bien que cela varie considérablement par Scrum Team, les membres doivent avoir une compréhension commune de ce que cela signifie pour le travail d’être terminé afin d'assurer la transparence.
Voici la "Définition de Done" pour l'équipe Scrum et qui est utilisée pour évaluer quand le travail est terminé sur l’incrément du produit.
La même définition guide la Development Team pour savoir combien d’items de Product Backlog elle peut sélectionner lors d'un Sprint Planning Meeting.
Le but de chaque Sprint est de livrer des incréments de fonctionnalités potentiellement livrables qui adhèrent à la Définition of “Done” actuelle de la Scrum Team.
Les Development Teams délivrent un incrément de fonctionnalités-produit chaque Sprint.
Cet incrément est utilisable, de telle sorte que le Product Owner peut choisir de le délivrer immédiatement.
Chaque incrément est un additif à tous les incréments antérieurs, testé en profondeur, pour s’assurer que tous les incréments travaillent ensemble.
Comme les équipes Scrum mûrissent, il est prévu que leur définition de « Done » s'élargisse pour inclure des critères plus rigoureux pour une qualité supérieure.
Conclusion
Scrum est gratuit et offert dans ce guide. Les rôles Scrum, les artefacts, les événements, et les règles sont immuables, et mettre en œuvre que des parties de Scrum est possible, le résultat n'est pas Scrum.
Scrum n'existe que dans son intégralité et fonctions ainsi qu’en tant que conteneur pour d'autres techniques, méthodologies et pratiques.
© 2011 Pierre Neis
