scrum events time boxing
Introduction aux événements Scrum:
Dans nos tutoriels précédents, nous avons discuté de Scrum et de sa structure.
Et notre précédent tutoriel expliquait tout sur Artefacts Scrum en détail.
Nous savons qui forme l'équipe Scrum et quels différents artefacts sont développés tout au long du processus. Nous avons établi une solide expérience maintenant. Par conséquent, prenons une longueur d'avance sur Scrum et discutons des événements / cérémonies clés qui constituent le processus Scrum.
Dans ce tutoriel, nous essaierons de comprendre ce que signifie chacun des événements Scrum, quelles sont les fonctionnalités essentielles et comment les organiser en détail.
Ce que vous apprendrez:
- Aperçu
- Types d'événements Scrum
- Qu'est-ce que le Time Boxing?
- La planification du sprint
- Le Daily Standup
- La revue de sprint
- La rétrospective Sprint
- Raffinement du carnet de commandes
- Conclusion
- lecture recommandée
Aperçu
Tout en travaillant sur un projet basé sur Scrum, l'équipe Scrum passe par une série de cérémonies Scrum.
Certains peuvent les appeler cérémonies ou événements Scrum et d'autres peuvent les appeler pour des rituels ou des réunions. Indépendamment des différentes terminologies utilisées ici, le but de chaque événement Scrum reste le même. Chacun des événements Scrum, en substance, aide à accomplir et à surveiller le travail de Sprint.
Types d'événements Scrum
Chaque cérémonie Scrum est une affaire / un rassemblement en personne organisé par le Scrum Master pour les groupes dédiés. Outre l'équipe de base, certaines des réunions peuvent impliquer des parties prenantes, des responsables de livraison ou même le client lui-même. Ces réunions sont limitées dans le temps et doivent donc être achevées dans les délais impartis.
L'objectif de chacune des réunions est de rassembler les participants et de les laisser discuter du travail à accomplir. L'attente de chaque participant est de rester concentré, engagé et participatif.
Il est considéré comme une opportunité de converser, d'examiner et de récupérer le retour d'expérience du travail effectué. Contrairement aux réunions ordinaires, les événements Scrum sont axés sur les résultats, cadrés dans le temps, basés sur le public cible et ont un objectif spécifique aligné sur chacun d'eux.
Qu'est-ce que le Time Boxing?
Le timeboxing est l'une des fonctionnalités clés attachées à chaque événement Scrum. Les participants doivent être conscients et respectueux du temps alloué à chacun des événements. Les événements ne peuvent pas être prolongés mais peuvent être raccourcis si les objectifs de la réunion ont déjà été atteints.
Scrum Master qui est également un facilitateur pour tous les événements Scrum s'assure que tout le monde comprend l'importance de la boxe temporelle et continue également de leur rappeler de se concentrer sur l'objectif de la réunion pour obtenir les meilleurs résultats et des résultats dans le temps avec des écarts.
La Timebox d'un événement ne devrait idéalement pas être prolongée mais comme nous savons que le Scrum ne concerne pas les règles, le temps peut être prolongé à une durée particulière si chaque participant est d'accord.
Comment décidons-nous de la boîte de temps pour chacun des événements Scrum?
La boîte de temps pour les événements Scrum est directement proportionnelle à la durée du Sprint. Cependant, la seule exception à cette règle est Daily Standup qui a une durée fixe de 15 minutes quelle que soit la durée du sprint.
Il existe des délais standard pour chaque événement en fonction de la durée du Sprint. Pourtant, l'équipe a la liberté de décider des délais pour ces événements en fonction de leurs besoins.
Comprenons plus en détail ces concepts en discutant de chaque événement Scrum en détail.
La planification du sprint
Comme condition préalable à cette cérémonie, le Product Owner doit disposer d'un Product Backlog stable et priorisé de user stories préparé avant de se rendre à la réunion. Les user stories doivent être bien formées et suffisamment claires pour que l'équipe les comprenne.
Le Product Owner peut demander l'aide des Parties Prenantes, du Client, du Designer et du Scrum Master pour développer le Product Backlog.
Il est obligatoire d'avoir un critère d'acceptation dans une user story. L'équipe est autorisée à refuser une user story sans les critères d'acceptation.
But
La planification de sprint est la cérémonie initiale lors du démarrage d'un sprint. Le but de la réunion de planification de sprint est de créer un objectif de sprint, de sélectionner des user stories du Product Backlog au Sprint Backlog et d'en discuter en détail.
L'équipe se réunit dans une salle de réunion avec le Product Owner et le Scrum Master où le Product Owner présente les user stories à sélectionner pour le prochain sprint.
L'équipe peut poser autant de questions qu'elle le souhaite pour en savoir plus sur l'histoire et il est de la responsabilité du Product Owner de répondre aux requêtes. L'équipe pourrait également contester l'histoire pour son exhaustivité et sa pertinence.
Si des informations supplémentaires sont nécessaires dans l'histoire ou ont une dépendance inachevée ou sont jugées incomplètes, l'équipe a le pouvoir de rejeter cette histoire.
Après tout, les doutes ont été dissipés et l'équipe connaît la quantité exacte de travail à effectuer pour terminer une histoire, l'équipe estime ensuite et donne les points d'histoire à chacune des histoires utilisateur.
De la même manière, les autres histoires sont discutées et estimées. L'équipe sélectionne désormais les Stories du haut du Backlog Produit Prioritaire dans le Backlog Sprint qu'elle pense pouvoir engager et terminer dans le Sprint compte tenu de sa vélocité passée.
La vitesse est déterminée par le nombre total de points d'histoire terminés dans un sprint moyen. La vitesse est calculée sur la base des Sprints historiques et en les faisant la moyenne. Plus nous effectuons de sprints, plus la vitesse d'une équipe est stable.
De nombreuses équipes utilisent les cartes Planning Poker pour l'estimation de l'histoire. La technique d'estimation la plus courante est le pointage d'histoires à l'aide de la série de Fibonacci. La série de Fibonacci est une série de nombres où chaque numéro suivant de la série est constitué en additionnant les deux nombres précédents.
Série Fibonacci - 1, 1, 2, 3, 5, 8, 13 et ainsi de suite.
Les user stories estimées au-delà de 13 story points sont considérées comme très volumineuses à réaliser en un seul sprint et sont donc décomposées en user stories logiques plus petites qui peuvent être estimées individuellement.
Lors d'une réunion de planification de sprint, l'équipe créera également des tâches sous les user stories qui ont été sélectionnées pour le sprint. On ne s'attend pas à ce que l'équipe tâche toutes les user stories pendant la planification du sprint, mais c'est juste assez pour les démarrer. Le reste des tâches peut être effectué pendant le sprint.
Le résultat clé d'une réunion de planification de sprint est l'objectif de sprint et le backlog de sprint qui se compose des user stories auxquelles l'équipe s'est engagée à compléter.
En dehors des User Stories, il peut y avoir d'autres types d'éléments qui peuvent faire partie du Sprint Backlog.
- Pointes
- Dettes techniques
- Insectes
Pointes sont les tâches de recherche pour trouver une solution, c'est-à-dire dont le besoin est déclenché par la User Story elle-même. Certaines des histoires peuvent ne pas être simples ou ne sont pas dans la capacité technique et nécessiteraient donc plus d'analyses et de recherches autour d'elles. Par conséquent, un pic est créé. Il peut également inclure un POC si le besoin s'en fait sentir.
Dettes techniques sont la refactorisation du code existant. Il arrive souvent que l'équipe doive retravailler le code qui a été développé précédemment pour s'adapter aux nouvelles exigences.
Insectes dans Scrum sont généralement les exigences manquées ou nouvelles qui proviennent des user stories acceptées mais qui sont pertinentes pour les éléments de travail actuels. Si ce n'est pas une exigence, il peut en fait s'agir d'un bogue dans le système qui a été découvert lors des sprints précédents mais qui n'a pas été corrigé et qui a été priorisé dans ce sprint.
Participants
Tout le monde dans l'équipe Scrum participe à la réunion de planification de sprint. Personne d'autre que l'équipe principale n'est invité à assister à la réunion.
La réunion de planification de sprint est organisée et animée par le Scrum Master mais le Product Owner vole la vedette.
Boîte à temps
La réunion de planification de sprint peut durer jusqu'à une demi-journée pour un sprint de deux semaines. La durée d'une réunion de planification de sprint dépend directement de la durée du sprint. Plus court pour un sprint court et plus long pour un sprint long.
La réunion de planification de sprint joue un rôle très crucial dans l'architecture globale de Scrum et affecte directement le produit en cours de développement. Par conséquent, l'équipe doit investir autant de temps qu'elle le juge nécessaire pour discuter de toutes les user stories en détail et peut proposer une boîte de temps alternative qui leur convient.
Une fois que le calendrier est décidé et accepté, il est de la responsabilité du Scrum Master de garder l’équipe concentrée sur l’objectif et en même temps de garder une trace du temps.
Le Daily Standup
But
Daily Standup est une rencontre qui donne l’occasion d’illustrer une vision globale de la santé du Sprint. C'est aussi une plate-forme pour discuter sur quoi les autres membres de l'équipe travaillent et s'il y a quelque chose qui s'arrête dans la réalisation de l'objectif du Sprint.
Lors d'une réunion quotidienne, chaque membre de l'équipe partage l'état de ses progrès sur les éléments de travail sur lesquels il travaille. Ils partageraient également et demanderaient de l'aide aux autres membres de l'équipe s'il y a des obstacles qui bloquent leur progression.
Lors d'une réunion quotidienne, chaque membre de l'équipe autour de la table répond une par une aux trois questions clés suivantes:
«Qu'avez-vous fait depuis le dernier Daily Standup Meeting?»
«Que comptez-vous faire aujourd'hui?»
interface utilisateur de base de données et logiciel de requête
'Y a-t-il un obstacle qui bloque votre travail?'
On s'attend à ce que les autres membres de l'équipe prêtent attention lorsque quelqu'un partage le statut et proposent de l'aide si le besoin s'en fait sentir. Dès que le dernier membre de l'équipe a répondu aux trois questions, la réunion se termine là.
La réunion Daily Standup donne une vue d'ensemble de l'état d'achèvement actuel et global de l'itération sur laquelle ils travaillent actuellement. Scrum Master joue un rôle très important en gardant la réunion du Daily Standup concentrée et limitée dans le temps. Il est également responsable de la résolution des obstacles empêchant l'équipe de progresser avec ses User Stories.
Scrum Master doit également s'assurer que personne d'autre que l'équipe principale ne pose de questions et ne présente le statut. Il peut autoriser des discussions rapides autour des user stories si nécessaire, mais doit rester conscient du temps tout au long et peut à tout moment intervenir et demander aux membres de l'équipe d'avoir une discussion hors ligne.
Participants
Tout le monde peut assister à une réunion quotidienne. Cependant, il est obligatoire pour l'équipe principale d'assister à la réunion et de présenter l'état d'avancement de ses travaux.
Toute autre personne, même extérieure à l'équipe, qui souhaite connaître la progression du Sprint peut assister au Daily Standup Meeting, mais n'est pas autorisée à présenter l'état de son travail ou à interroger les membres de l'équipe de développement sur leur travail.
Seuls les membres de l'équipe principale sont autorisés à partager les progrès de leur travail et tout le monde est censé écouter en silence.
La réunion Daily Standup doit avoir lieu même si un seul membre de l'équipe est présent.
L'équipe peut diriger la réunion quotidienne debout seule ou peut demander au Scrum Master de l'animer pour eux.
Boîte à temps
Comme son nom l'indique, une réunion quotidienne se déroule quotidiennement et les participants doivent se lever car il s'agit d'une courte réunion de 15 minutes seulement. L'idée est de s'en tenir à l'ordre du jour et de ne pas dévier de l'objectif, donc la réunion est courte. Tenir la réunion aide également les gens à s'y engager facilement car cela ne demande que 15 minutes.
La réunion quotidienne debout est également tenue à la même heure et au même endroit tous les jours pour réduire la confusion parmi les participants et les frais généraux pour réserver les salles de réunion quotidiennement. L'utilisation d'ordinateurs portables, d'ordinateurs de bureau ou de téléphones portables est fortement déconseillée pendant la réunion.
Les équipes peuvent décider du moment de la réunion du Daily Standup et s'y tenir. Cependant, la tendance normale est de garder les réunions la première chose le matin. Pour les équipes travaillant dans des fuseaux horaires différents, l'appel du matin peut ne pas fonctionner et ainsi ils peuvent avoir l'appel dans l'après-midi ou ce qui leur convient le mieux.
Le Scrum Master peut également partager les nouvelles importantes ou les mises à jour à la fin de la réunion avec l'équipe si le temps le permet, mais n'est pas autorisé à prolonger la réunion à tout prix.
La revue de sprint
But
La réunion de révision de sprint consiste à démontrer le travail effectué et à recueillir les commentaires et l'adhésion. À certains endroits, la réunion Sprint Review est également connue sous le nom de Sprint Demo. La réunion de révision de sprint se fait généralement à la fin du sprint mais avant la réunion de rétrospective de sprint.
Le (s) représentant (s) choisi (s) de l'équipe démontre les éléments de travail du sprint en cours. Habituellement, le développeur travaillant sur la user story démontre le travail et répond aux requêtes soulevées par n'importe qui dans l'audience.
Les user stories qui sont faites sur la base de la définition de Done sont les seuls candidats pour la démonstration lors de la réunion de révision de sprint.
Le Product Owner joue un rôle très important lors de la réunion de révision du sprint. Il est chargé d'évaluer chacune des user story démontrées par rapport à ses critères d'acceptation et accepte ou rejette l'histoire.
Les histoires acceptées sont ensuite intégrées à l'incrément terminé qui est un livrable potentiellement livrable. Où irait une histoire rejetée ou inachevée est l'appel du Product Owner. Les histoires rejetées peuvent faire partie du prochain sprint ou passer au Backlog produit à partir duquel elles seront à nouveau priorisées.
Le résultat clé de la réunion d'examen du sprint est une vue d'ensemble de la date d'achèvement du projet. Le Product Owner accepte / rejette l'histoire et les histoires acceptées sont ensuite intégrées à l'incrément (créé lors des sprints précédents) dans son ensemble pour donner une meilleure image de la situation dans laquelle nous en sommes à compléter le produit entier.
Un autre résultat clé de la réunion Sprint Review est que les membres de l'équipe apprennent quelque chose sur l'estimation. Le nombre de user stories acceptées détermine le nombre de story points obtenus dans un sprint.
comment extraire un dvd gratuitement
Ainsi progressivement sprint par sprint, l'équipe peut développer la capacité d'estimer correctement et de prendre une décision éclairée concernant les points d'histoire qu'il est possible de réaliser.
On observe souvent que de telles réunions mettent en lumière les critères d'acceptation incomplets ou les «nouvelles exigences qui apparaissent. La meilleure façon de sortir de cette situation est de fermer les histoires et de les marquer comme terminées si elles satisfont à tous les critères d'acceptation initialement convenus lors de la réunion de planification du sprint.
Tout ce qui dépasse et doit être considéré comme une nouvelle exigence et le Product Owner est responsable de ces exigences pour le futur sprint.
Participants
Les membres de l'équipe, y compris le Scrum Master et le Product Owner, participent à la réunion de révision du sprint. Les autres participants à la réunion de revue de sprint sont les parties prenantes, les responsables de la livraison, les clients / utilisateurs finaux ou toute personne intéressée à faire partie de la revue de sprint.
Boîte à temps
Dans un scénario idéal pour un sprint de deux semaines, nous passons environ 2 heures dans la réunion Sprint Review. Cela peut varier en fonction de la durée du Sprint. Pour un sprint plus court Sprint Review et pour un sprint plus long Sprint Review.
Comme les autres réunions, le Scrum Master est responsable de maintenir l'élan de la réunion et de s'assurer que les activités (démonstration des histoires, réponse aux questions, acceptation des histoires, commentaires notés, etc.) s'inscrivent dans le délai imparti.
La rétrospective Sprint
But
La rétrospective Sprint consiste à incarner ce que dit Agile - « Réflexions régulières sur comment devenir plus efficace ». Sprint Retrospective donne l'occasion à toute l'équipe de réfléchir et de réfléchir à la manière dont le sprint s'est déroulé et que faut-il faire pour improviser les processus? La rétrospective de sprint est effectuée à la fin de chaque sprint.
Lors d'une réunion de rétrospective de Sprint, toute l'équipe se réunit et discute du Sprint qui vient de s'achever. On s'attend à ce que l'équipe soit transparente et donne des opinions honnêtes, mais il n'y a pas de jeux de blâme.
Rappelez-vous l'objectif de la réunion de prendre une longueur d'avance dans le domaine de l'improvisation et de ne pas tenir l'équipe en augmentant la tension entre les membres.
Tout le monde dans on attend de l'équipe qu'elle réponde aux quatre questions fondamentales:
Le Scrum Master demande aux membres de l'équipe d'écrire leurs points pour chacun des quadrants comme indiqué ci-dessus dans des notes autocollantes. Dans certains endroits, les outils sont utilisés dans le même but.
Qu'est-ce qui s'est bien passé?
Les membres de l'équipe donnent un ou plusieurs points sur ce qui s'est bien passé lors du dernier Sprint. Cette section peut également être considérée comme une occasion d'apprécier et de remercier les autres membres de l'équipe pour leur bon travail.
Qu'as-tu appris?
Scrum est considéré comme une opportunité d'apprendre quelque chose de nouveau à chaque sprint. Cette zone d'un quadrant est de discuter des principaux points à retenir et des enseignements du dernier Sprint.
Qu'est-ce qui ne s'est pas bien passé?
Dans cette section, l'équipe discute des problèmes et des obstacles auxquels elle a été confrontée lors du dernier sprint. Cette partie de la réunion a tendance à être la plus fragile, car les gens pourraient soulever des questions qui peuvent mettre les autres mal à l'aise.
Il est de la responsabilité du Scrum Master de calmer l’atmosphère si nécessaire et d’apprendre aux gens à soulever leurs problèmes de manière constructive au lieu de passer par les séries d’attaques personnelles.
Si l'un des membres n'est pas à l'aise pour affronter les problèmes devant les autres coéquipiers, il peut se rendre plus tard au Scrum Master et discuter des problèmes.
Que pourrait-on faire de mieux?
Cette partie de la réunion donne l'occasion à tous les membres de l'équipe de discuter de toutes les questions soulevées précédemment et de trouver les moyens de les résoudre. Tout le monde dans l'équipe est le bienvenu pour proposer des solutions au problème en cours. L'équipe décide alors dans l'unité des solutions les mieux adaptées.
L'équipe devrait également envisager de s'en tenir aux choses qui ont été discutées dans la section Ce qui s'est bien passé pour les futurs sprints et à l'avenir, ces choses peuvent être ajoutées comme partie intégrante du processus.
Le résultat de la réunion de rétrospective de sprint est une liste d'éléments d'action convenus par les participants pour améliorer le processus pour le sprint à venir.
Participants
Toute l'équipe Scrum, y compris le Scrum Master et le Product Owner. Mais contrairement à une réunion debout quotidienne, le Scrum Master et le Produit participent également à fournir leurs contributions et points rétrospectifs.
Tout comme la réunion Daily Standup, la réunion Sprint Retrospective est également animée par le Scrum Master. Scrum Master s'assure que tout le monde dans l'équipe, y compris lui-même, a la possibilité de s'ouvrir et de parler à la fois du positif et du négatif.
Prenez note que les participants extérieurs à l'équipe ne sont pas invités à la réunion rétrospective de sprint. Sprint Retrospective est considéré comme un petit environnement personnel et émotionnel qui permet aux membres de l'équipe de s'ouvrir sans hésitation et de discuter des problèmes auxquels ils ont été confrontés lors du dernier sprint.
Boîte à temps
Il est dit à juste titre que toutes les cérémonies Scrum sont chronométrées et leur durée dépend de la durée du Sprint. Cela dit, pour un sprint de deux semaines, il est idéal d'avoir une réunion de rétrospective Sprint pendant 2 heures.
Cependant, si nous considérons la rétrospective Sprint comme une opportunité de communiquer, de rétrospecter et de s'engager vers les améliorations, il est tout à fait justifié de donner suffisamment de temps à la réunion pour éviter de perdre sur les points de vue et les idées importants.
Il est donc bon de cadrer la réunion mais ne doit pas se faire au détriment de la communication et de la progression. Un autre événement très important dans Scrum est le raffinement du backlog. Prenons un petit moment pour faire la lumière là-dessus.
Raffinement du carnet de commandes
Backlog Refinement, également connu sous le nom de Backlog grooming, est une réunion pour discuter des user stories du Product Backlog qui pourraient faire partie du prochain Sprint. Lors d'une réunion de raffinement du backlog, toute l'équipe s'assoit et discute des user stories, fournissant ainsi leurs contributions.
L'idée générale est de préparer le Backlog Produit pour le prochain Sprint et de s'assurer que les user stories sont prêtes à être sélectionnées. La réunion de raffinement du backlog est organisée pendant le sprint «n-1» pour préparer les éléments à sélectionner dans le sprint «n».
Conclusion
Avec cela, nous sommes arrivés à la fin de ce tutoriel sur «Scrum Events» qui est un must pour en lire un. Les événements Scrum sont de loin le sujet le plus important et le plus significatif de la série Scrum.
Dans ce tutoriel, nous avons discuté des cinq événements Scrum, c'est-à-dire Sprint, planification de sprint, standup quotidien, revue de sprint et rétrospective de sprint . Chaque événement autre que le stand-up quotidien a un cycle régulier par sprint, c'est-à-dire effectué une fois dans chaque sprint.
Les événements donnent un aperçu de la manière dont les tâches sont accomplies dans un environnement Scrum. Tous les événements Scrum sont des opportunités d'amélioration, d'adaptation et d'inspection.
Le prochain tutoriel sur le «Tri des défauts» est une réunion formelle où tous les défauts du Sprint actuel sont discutés et triés, c'est-à-dire classés par ordre de priorité.
Tutoriel PREV | Tutoriel SUIVANT
lecture recommandée
- Artefacts Scrum: Backlog produit, Backlog Sprint et incréments de produit
- Tutoriel JIRA Scrum Board: Manipulation de Scrum avec Jira pour gérer le sprint
- Quiz Agile Scrum en ligne: Testez vos connaissances sur Agile Scrum
- Comment fournir des fonctionnalités logicielles de grande valeur dans un court laps de temps à l'aide du processus Agile Scrum
- Tri des défauts dans Scrum: comment est-il organisé dans une configuration Scrum
- Opportunité d'emploi indépendant à temps partiel pour les experts Selenium
- Rôles et responsabilités de l'équipe Scrum: Scrum Master et Product Owner
- 10 meilleurs logiciels d'horloge gratuits pour le suivi du temps des employés