Non seulement nos réunions de planification de sprint ne sont pas amusantes, mais elles sont carrément affreuses.

Les réunions sont fastidieuses et ennuyeuses et prennent une éternité (un jour, mais cela semble beaucoup plus long).
Les développeurs s'en plaignent et redoutent les plannings à venir.

Notre routine est assez classique (une histoire utilisateur insérée dans l'arriéré de sprint par priorité >> l'histoire est séparée des tâches >> les tâches sont estimées en heures >> répétées), et je ne peux pas comprendre ce que nous faisons mal.

Comment pouvons-nous rendre les réunions plus agréables?

...

Quelques détails supplémentaires, en réponse à des demandes d'informations supplémentaires:

Pourquoi les éléments en attente ne sont-ils pas insérés et hiérarchisés avant le coup d'envoi du sprint?

Les histoires d'utilisateurs sont en effet priorisées; nous n'avons aucune idée du temps qu'il leur faudra avant de les décomposer en tâches! D'après les (excellentes) réponses ici, je vois que nous ne devrions peut-être pas estimer les tâches du tout, mais uniquement les user stories. La raison pour laquelle nous estimons les tâches (et non les histoires), c'est parce que nous avons eu des estimations d'histoires terriblement erronées - mais je suppose que c'est le sujet d'une question tout à fait différente.

Pourquoi les développeurs se plaignent-ils?

1. Les réunions sont longues.

2. Les réunions sont monotones. Histoire après histoire, tâche après tâche, luttant (oui, peinant) pour estimer le temps que cela prendra et ce que cela implique.

3. L'estimation des tâches rend l'estimation de l'histoire de l'utilisateur inutile.

4. Plus la réunion est longue, moins il y a de concentration dans la salle. Moins les collègues sont concentrés, plus la réunion dure longtemps. Une spirale de haine récursive se développe. Nous avons envisagé de scinder la réunion en deux jours afin de garder les utilisateurs concentrés, mais les développeurs n'en ont pas entendu parler. Une journée de planification suffit déjà; maintenant nous en aurons deux ?!

Une partie de notre problème est que nous entrons dans de très petits détails (afin d'obtenir des estimations plus précises). Mais lorsque nous estimons approximativement, nous nous éloignons de la cible!

Pour résumer la question:

• Que faisons-nous de mal?

• Quels autres moyens existe-t-il pour rendre la réunion plus agréable en général?

Faciliter l'estimation

Casser votre planification de sprint.

Avez-vous besoin d'estimer les tâches individuelles? J'ai planifié le sprint de deux manières:

1. Les histoires sont estimées en points d'histoire, puis les tâches sont estimées en heures.
2. Les histoires sont estimées en points de scénario et les tâches tombent simplement dans cette catégorie sans estimation.

Des deux, je préfère la deuxième option. Je trouve que ne pas estimer les tâches donne plus de liberté aux développeurs pour faire face aux changements. Si une tâche n’a plus de sens (combien de fois avez-vous découvert qu’une tâche n’était pas applicable ou avait déjà été effectuée lors d’un sprint précédent), vous la jetez simplement sans pénalité, ou vous devez éventuellement modifier une tâche en cours en quelque chose de nouveau, peut-être le casser Vous êtes vraiment redondant si vous estimez les deux, car la somme des tâches doit représenter les points de l'histoire et vice versa. Quelle valeur gagnez-vous réellement par cet élément si ce n’est de savoir combien de temps chaque tâche prendra? Si vous vous retrouvez avec des tailles de tâches qui varient suffisamment pour faire une différence, je suggérerais de les décomposer en morceaux plus petits et plus homogènes.

Ainsi, vous réduirez le temps que vous consacrez à la planification des sprints . Les histoires sont estimées lors de la planification du sprint et lorsque vous commencez le sprint, vous pouvez noter toutes les tâches imaginables qui composent cette histoire. De toute évidence, si vous rencontrez des difficultés lors de l'estimation de l'histoire que vous savez devoir être traitée dans une tâche, vous pouvez l'ajouter à l'information de l'histoire et la définir en tant que tâche.

Estimation en unités idéales

Les points de scénario sont censés être dans des unités idéales telles que des heures de main-d'œuvre idéales ou des journées de travail idéales. Celles-ci signifient que, compte tenu du jour parfait tous les jours, sans interruption, sans réunion et où tout se déroulait comme prévu, vous pouviez accomplir la tâche en X jours. Maintenant, tout le monde sait que ce n'est tout simplement pas vrai, mais ce qui est merveilleux avec les statistiques, c'est que ce n'est pas nécessaire.

Ce que je veux dire par là, c'est qu'après un certain temps d'estimation de ces jours idéaux, vous réalisez qu'il faut peut-être 25% de plus du temps que vous estimez en moyenne pour terminer une histoire. Disons que vous aviez estimé 4 jours de travail idéaux et qu'il vous en fallait 5. Au fil du temps, vous en tenez compte, puis vous avez une idée approximative de la conversion des jours idéaux en jours réels. Votre premier instinct serait d'essayer de compenser cela en surestimant, et vous auriez probablement tort. La chose principale ici est de rester cohérent. De cette façon, votre moyenne à long terme reste la même. Bien sûr, parfois, ce sera sous et parfois ce sera fini, mais plus vous estimez, mieux vous vous portez. Si vous trouvez que vous avez encore vous ne pouvez pas obtenir une estimation décente, cela signifie peut-être que vous n'en savez pas assez sur l'histoire pour bien la chiffrer.

Parlez des histoires

Lorsque vous faites une estimation, tout le monde devrait avoir une idée approximative de ce qui doit être fait, du début à la fin, de ce qui va être nécessaire pour que cette histoire soit complète. Vous n'avez pas besoin de connaître tous les détails, mais suffisamment pour penser que vous pourriez vous-même entreprendre l'histoire. Si vous n’avez pas ce niveau de confiance, vous ne devriez probablement pas l’estimer. Si vous dites "Eh bien, cette histoire est trop volumineuse pour que nous connaissions la plupart des détails", cela signifie que cette histoire est trop volumineuse et doit être décomposée. Les récits, du moins de mon expérience, ont été assez petits pour qu'une personne, si besoin est, puisse y travailler seule et l'accomplir en une semaine ou deux.

Cela aidera également à résoudre votre deuxième point dans l'édition, qui est trop d'estimation . Au lieu d'estimer chaque tâche pour chaque récit, vous estimez simplement le récit dans son ensemble, ce qui devrait permettre de supprimer une grande partie de l'estimation. Pour rendre les réunions moins monotones, je vous suggérerais de planifier le poker, sur lequel vous pouvez voir plus d'informations ci-dessus.

Rendre la planification plus attrayante

Estimer en utilisant Planning Poker

En ce qui concerne l'estimation plus amusante, avez-vous essayé de planifier le poker ? C'est la façon dont j'ai toujours planifié tous mes sprints dans plusieurs équipes et c'est un bon moyen de garder tout le monde impliqué, car chaque personne doit au moins choisir quelque chose. Il y a aussi beaucoup de plaisir lorsque tout le monde dans l’équipe choisit 3, et que quelqu'un dépose un 20 et doit s’expliquer, ou quand tout le monde dans l’équipe pose un 5 mais le manager dépose un 8 (qui va se disputer avec le patron quand il veut vous donner plus de temps!).

Pour ce faire, vous avez besoin de quelques cartes de poker de planification , que nous fabriquons souvent au verso des cartes d’index, ou de l’utilisation de cartes à jouer normales avec des valeurs attachées aux cartes de visage. Rien d'extraordinaire, et tout le monde est concentré. N'oubliez pas que le fait d'essayer de faire n'importe quelle tâche pendant une journée entière (y compris la planification du poker) pèse lourdement sur la productivité. Beaucoup de jeux de cartes viennent avec une carte de café pour une raison; si quelqu'un se sent épuisé, donnez à l'équipe une pause pour se ressourcer et récupérez-la quand tout le monde sera frais!

En guise d'alternative aux cartes physiques , vous pouvez également consulter les cartes électroniques . Les avantages réels ici sont le suivi automatisé des résultats, le suivi des récits d'utilisateurs à évaluer et le fait de permettre à tout le monde de montrer ses cartes en même temps pour éviter de "tricher" (l'estimation selon laquelle une personne est influencée par une autre parce qu'elle peut voir sa carte). Cela nécessite évidemment que tout le monde ait un ordinateur et la capacité de se concentrer sur la tâche à accomplir, alors utilisez-le à votre propre discrétion.

1. Pourquoi les éléments en attente ne sont-ils pas insérés et hiérarchisés avant le coup d'envoi du sprint? Perdre du temps aux développeurs n'est pas amusant. Laissez vos responsables d’équipe travailler quelques jours à l’avance avec le responsable du produit et le responsable du projet pour hiérarchiser les éléments. Cela vaut également pour la planification qui fait partie de chaque équipe de sprint.

2. Pourquoi faut-il une journée pour décomposer les tâches en tâches? Si vous avez une équipe de taille raisonnable (2 à 4 développeurs, 1 à 5 personnes pour le contrôle qualité par développeur, 1 à 2 personnes), vous devriez avoir 2 à 4 user stories pour ce sprint. Passez environ 30 minutes avec le responsable du produit pour clarifier les exigences, puis environ 30 minutes, pour une tâche d'environ 8 heures. N'entrez pas les tâches pendant la réunion. Convenez simplement en équipe que les tâches sont suffisantes pour que les personnes sensées les comprennent, qui en est responsable et combien de temps elles devraient prendre. Convenez que «combien de temps ils devraient prendre (y compris les tests)» s’intègre parfaitement dans le sprint.

3. Si vous ne faites pas que décomposer des choses en tâches, que faites-vous d'autre? Bien sûr, les rétrospectives peuvent prendre entre 30 et 60 minutes, mais elles seront plus courtes à mesure que les équipes s’engouffrent.

En résumé, arrêtez de gaspiller le temps des gens et ils redouteront un peu moins les réunions. Au-delà de cela, l’amusement et la camaraderie dans l’équipe ne peuvent pas être abordés lors de réunions. Allez déjeuner ensemble, blaguez, mélangez les gens pour obtenir de meilleurs ajustements de personnalité, ayez des compétitions pour faire pousser la moustache ... une fois le moral rétabli, les gens vont naturellement rendre les réunions de planification de sprint plus légères.

La planification est un domaine de mêlée où les équipes ont beaucoup de flexibilité. Essayez quelque chose de nouveau à chaque sprint jusqu'à ce que vous trouviez quelque chose qui fonctionne pour votre équipe.

Quelques idées réussies que j'ai essayées personnellement ou que d'autres équipes ont évoquées:

• Créez des histoires d’utilisateur et définissez des priorités sans l’ensemble de l’équipe. Le propriétaire du produit et / ou Scrum Master peut gérer une grande partie du travail chargé et laisser l’équipe le peaufiner.
• Faites en sorte que votre arriéré soit plus long qu'un sprint. Cela peut prendre un certain temps, mais si votre arriéré est suffisamment long, les réunions de planification sont réduites à de petites modifications ou à des développements récents.
• Organisez des réunions d'estimation séparément de la planification du sprint Si les gens pensent que les réunions sont trop longues, il n'y a aucune raison de ne pas les séparer.
• Planifiez spécifiquement les pauses dans l'agenda. Ceci est utile si vous perdez souvent votre temps à attendre le retour d'un ou deux membres de l'équipe.
• Faites une pause au milieu de la réunion et demandez à chacun de charger une ou deux histoires d'utilisateurs, puis se réunissent pour faire rapport et obtenir un consensus.
• Assurez-vous que votre réunion de planification porte sur ce qu'il faut faire et non sur la façon de le faire. Les ingénieurs tombent très facilement dans ce dernier. Si vous en avez besoin, organisez des réunions de conception distinctes pour discuter du comment.
• Séparez vos récits en enquête et mise en œuvre. Les réunions de planification durent souvent trop longtemps lorsque les membres de l’équipe savent trop peu sur quoi ils vont travailler et essaient de le comprendre au cours de la réunion.
  Par exemple, supposons que vous deviez intégrer une API avec laquelle votre équipe n’a aucune expérience. Plutôt que d'essayer de créer des estimations et des tâches au cours de la réunion de planification à propos de quelque chose qui vous échappe, faites une histoire d'enquête pour apprendre l'API, créez une application simple "hello world" et enseignez-la à l'équipe. Ensuite, vous serez équipé pour planifier le travail réel.
• Gardez une trace lors de vos réunions de questions spécifiques. Non seulement "la planification est ennuyeuse", mais un niveau de détail du type "nous passons beaucoup de temps à parler d'exigences peu claires, et personne ne semble connaître la bonne réponse". Ensuite, discutez de ces problèmes spécifiques lors de vos rétrospectives et réfléchissez à des solutions spécifiques. Décomposez votre problème jusqu'à ce que les problèmes soient faciles à résoudre.

Nous organisons simultanément la planification et la rétrospective de notre sprint, et notre travail est presque toujours terminé en 90 minutes, mais nous sommes l’une des équipes les plus rapides. Nous faisons une grande planification à long terme à l'échelle de la société tous les 5 sprints, ce qui prend 4 à 6 heures. Bien sûr, chaque équipe est différente, mais si vous passez une journée entière à chaque sprint, il reste encore beaucoup à faire.

Vos séances de planification sont beaucoup trop longues!

D'après mon expérience, une réunion de planification de sprint ne devrait pas prendre plus de 2 heures par semaine (par exemple, un sprint de 2 semaines devrait durer au plus une demi-journée), mais les réunions réussies devraient être plus courtes que celle-là (la moitié).

Dans votre cas particulier: pourquoi estimez-vous les tâches? Vous devez estimer uniquement les récits lors de la planification. Les tâches peuvent être estimées ultérieurement par les propriétaires de tâches spécifiques .

Une manière qui a fonctionné pour moi:

• Introduction rapide au sprint par le PO
• Estimation de la capacité de sprint
• Les histoires s'épuisent et planifient le poker (boîte chronométrée à 5/10 minutes par article) jusqu'à ce qu'il y ait suffisamment de matériel estimé pour couvrir le sprint
• Engagement officiel / prévisions de l'équipe

Ensuite, en parallèle / paires / auto organisé à nos bureaux, tâches et estimation des tâches.

Lors de mon travail précédent, toute la première journée de chaque sprint (nous les appelions itérations) a été occupée par:

• Rétrospective. Nous avons commencé à le faire dans l'après-midi du dernier jour, mais nous nous sommes souvent retrouvés à rétrospecter le sprint, puis à reprendre le travail en rattachant les derniers points de son travail au sprint. Nous avons donc pensé qu'il valait mieux s'assurer que le le travail était tout derrière nous avant d'y revenir. Il semblait également logique de regrouper tous les frais généraux liés au processus Scrum afin que les autres jours puissent être planifiés et dépensés de manière plus idéale. Cela prenait généralement 2 heures.
• Planification du sprint. L'arriéré a été estimé lors d'une réunion de planification d'un jalon (qui peut durer une journée entière à la fois pour les développeurs et les OP) et a été classé par ordre de priorité par les OP avant le début de chaque sprint. Nous avons calculé le nombre de jours de développeur dont nous disposions (comptabilisation des vacances, vaca, etc.), saisi le travail que nous pensions pouvoir faire de haut en bas et passé en revue rapidement les besoins des utilisateurs (précédemment vérifiés par nos BA) afin de: Obtenez une idée plus complète de ce que le travail impliquait que ce que nous avons obtenu avec la vue d'ensemble durant le MPM. Cela a généralement pris 2 heures.
• Planification des tâches. Connaissant les récits et les critères d'acceptation, nous avons décomposé chaque récit en tâches élémentaires estimées en heures idéales (une heure est consacrée à la réalisation de cette tâche, sans distraction ni obstacle). À la manière dont notre échelle de points a été calibrée, un 5 était un développeur-sprint, de sorte qu'un 1 pouvait représenter n'importe quoi allant jusqu'à deux jours-développeur inclus. Pour cette raison, il fallait pratiquement tout décomposer pour que les membres de l'équipe puissent afficher les progrès réalisés sur le tableau de mêlée. Ce fut un autre bloc de 2 heures, avec quelques concessions entre cet article et le suivant.
• AAT décrivant. Nos PO et BA n'étaient pas des programmeurs et ne codaient pas. Les organisations de producteurs se sont cachées derrière un contrat stipulant qu'elles répondraient aux exigences sous la forme d'un modèle Word et qu'elles travailleraient avec les autorités de certification pour les affiner sous cette forme. Les BA comprenaient le code, mais leur temps était purement d’analyse et de test final (ce qui nécessitait l’existence du système pour pouvoir enregistrer leurs macros dans Selenium). Ainsi, pour vérifier que notre code satisferait aux critères d’acceptation, nous avons dû rédiger nos propres AAT modélisant les actions du test d’acceptation "papier". Nous l’avons généralement fait dans le même cadre NUnit que celui utilisé pour les tests unitaires et d’intégration (nous avons essayé FitNesse et nous ne pouvions pas l’abandonner assez vite). C'était le reste de notre premier jour de chaque sprint et nous avons continué dans le second.

Dans mon travail actuel, nous adoptons toujours le processus Scrum, nous n'avions pas de planification d'étapes à l'échelle de l'équipe et beaucoup de nos sujets de travail n'ont pas de critères d'acceptation stricts. Ainsi, notre planification de sprint est autant une explication de ce que chaque histoire implique et ce que nous appellerons «fait» que son engagement à capturer les X meilleures heures de travail idéales. Nous nous en sortons, du moins pour le moment, parce que nous sommes une équipe interne et que chacun de nous travaille personnellement avec les utilisateurs finaux de notre logiciel pour rassembler les exigences et concevoir des solutions. Même dans ce cas, la planification du sprint dure tous les matins un lundi sur deux, et l’après-midi est consacrée à la suppression des obstacles personnels à la mise en place d’un développement sérieux mardi.

Pour répondre à la question du PO plutôt que pour contraster les commentaires et les réponses disant qu'il ne faut pas prendre trop de temps, il existe des moyens d'approcher l'estimation Agile, la planification du sprint et les rétrospectives un peu plus intéressants que vous ne l'utiliseriez peut-être.

Répondre spécifiquement à vos préoccupations:

• Les réunions sont longues - placez-les dans le temps. Chaque réunion, qu’il s’agisse d’une rétrospective, d’une planification de sprint, d’une répartition des tâches, etc., doit avoir un objectif défini et un sujet de discussion, et doit être limitée autant que possible à un laps de temps déterminé. C’est le travail de Scrum Master de garder ces réunions sur le sujet et de progresser pour atteindre les objectifs de temps.

• Les réunions sont monotones - il y en aura une partie; vous travaillez par petits morceaux, un à la fois, de sorte que vous fassiez la même chose encore et encore. Il est utile de garder l’équipe concentrée et de conduire à l’objectif de la réunion.

  Une autre chose que j’entends, c’est que peut-être vos réunions de planification de sprint tentent trop d’accomplir. Lors de ma dernière entreprise, l’histoire a été estimée lors de «réunions de planification jalons», qui ont lieu environ une fois par trimestre et durent toute la journée. Lors de ces réunions, tout ce qui avait constitué l’arriéré que nous n’avions pas estimé était estimé en points. Si vous effectuez une estimation du récit en points, puis une estimation de la tâche en heures, vous ne souhaitez pas les exécuter simultanément (peut-être le même jour).

• L'estimation d'histoires en points, puis de tâches en heures semble redondante - elles ont deux objectifs différents. L’estimation d’histoire a pour but de fournir une estimation approximative de la complexité que vous pouvez utiliser pour combler votre retard de sprint en fonction de la vitesse passée et de la bande passante attendue. L’estimation des tâches a pour but de décomposer les histoires en plusieurs choses qui prennent un jour ou moins par jour de développeur (et qui peuvent donc être assignées à un seul type qui devrait s’attendre à ce que tout soit terminé à temps), et à ce que vous ne l’ayez pas fait. a mal estimé la complexité de toute histoire, ni mordu plus que ce que vous pouvez mâcher dans le sprint.

  Si vos histoires durent toutes un jour ou moins, elles sont redondantes, mais les échelles de points ne sont pas toutes calibrées de la même manière; lors de mon dernier emploi, un 5 correspondait à deux semaines de développement (car au début, nous avions beaucoup d'estimations à évaluer), ce qui, sur une échelle linéaire, permettait de gagner jusqu'à 2 jours de développement. Compte tenu de ce type d’échelle, pratiquement tout devrait être divisé en tâches. Dans ma nouvelle société, un demi-jour de développement est proche, un 1 ou même un 2 est donc sa propre tâche et 3-8 est nébuleux en ce qu’il contraint l’équipe à la scinder en tâches.

• Il y a un cercle vicieux dans lequel il faut plus de temps pour que les gens soient moins concentrés, donc ça prend plus longtemps - Time-box votre time-box. Prenez des pauses, comme vous devriez le faire lors du codage. Toutes les 30 minutes, prenez 5 minutes pour vous dégourdir les jambes, vous ressourcer, etc. Vous pouvez vous en tenir à dix minutes toutes les heures, mais ne poussez pas trop le temps dont vous disposiez pour une réunion. Vos gars ont peut-être faim, ou ont besoin de plus de café, d'une pause dans la salle de bain, etc. Ne les refusez pas. si vous les faites sucer, vous verrez leur esprit vagabonder. Au-delà de cela, garder les discussions courtes, agréables et pertinentes aidera également, comme mentionné précédemment.

La réunion de planification du sprint comprend deux parties:

1. Décidez ce que l'équipe fera
2. Décidez comment l'équipe va le faire.

La première partie est relativement simple: basée sur le nombre de points d’histoire que l’équipe estime pouvoir accepter, l’engagement de mener à bien autant de récits d’utilisateurs dans leur ordre de priorité. Terminé.

La deuxième partie est ce que les développeurs devraient réellement apprécier: élaborer l’histoire et concevoir la solution. Les tâches en découlent. Alors, demandez au propriétaire du produit, ou à la PME qu’il a fournie, d’expliquer une histoire choisie. Puis, quel que soit le développeur qui le souhaite, dirigez la discussion sur la conception. Utilisez un tableau blanc. Bounce des idées autour. S'amuser.

C'est ça, vraiment. Si les réunions de conception ne sont pas amusantes, il y a simplement quelque chose qui cloche.

Oui, je sais que c'est une vieille question, mais j'ai une nouvelle réponse. : P

Diviser la réunion.

Nous avons divisé notre réunion de planification de Sprint en 3 mini-réunions distinctes.

• Arriéré de toilettage
• Sélection de l'histoire
• Répartition des tâches

Nous faisons chacun un jour différent, juste après notre Scrum quotidien - dès que le quotidien est terminé, nous passons directement à l'activité de planification, puis nous sommes libres des réunions (planifiées régulièrement) le reste de la journée.

Alors oui, nous avons planifié notre planification: -O

J'entrerai dans les détails dans une seconde, mais laissez-moi vous expliquer comment nous en sommes arrivés là.

Comme vous, nous avons eu un problème avec les réunions de planification de Sprint vraiment affreuses. Nous avions tous les éléments nécessaires, mais tout a duré une éternité et nous devions vraiment nous épuiser mentalement et émotionnellement.

Ensuite, j'ai eu cette idée après avoir lu cet article de Business Insider sur le quotidien de 5 minutes de Pivotal sur la division de nos réunions en sessions plus courtes et leur mise en place au début de chaque journée.

Je l'ai évoqué avec l'équipe lors d'une rétrospective. Certains membres de l'équipe ont tout de suite aimé l'idée , d'autres ont eu un peu peur, mais notre stagiaire a ensuite mentionné une étude qu'il avait lue sur la technique du pomodoro et a commencé à en parler, ce qui a vraiment aidé l'idée à gagner du terrain.

Nous avons donc décidé de l'essayer.
Nous avons divisé notre réunion de deux heures en trois séances de 25 minutes. (oui, ce sont des calculs flous, mais tout le monde a trouvé nos réunions trop longues et ne voulait le faire que si nous gagnions du temps).

Et ça a marché! Nous le faisons depuis environ 6 semaines sur deux projets distincts (6 sprints au total sur deux semaines) et cela a fait toute la différence.
Nous sommes plus productifs. Nous économisons une tonne de temps.
Nous obtenons de meilleurs résultats. Et nous ne redoutons plus nos réunions de planification.

Et honnêtement, notre chronométrage de 25 minutes est assez lâche - certaines sessions vont très vite, comme 5 à 10 minutes sur certaines de nos séances de toilettage, et certaines sont longues, comme lorsque nous finissons par identifier de nouvelles histoires ou devoir briser des histoires et ré-estimer pendant la négociation. Globalement, cela ne prend en moyenne qu’une heure et demie pour tout le shebang, et je pense que c’est la raison pour laquelle cela fonctionne si bien.

Sur les détails .....

Arriéré de toilettage

C'est assez simple: nous passons en revue les articles prioritaires, en discutons et nous nous assurons que nos estimations sont bonnes.

Nous ré-estimons les récits si nécessaire - par exemple, nous avons estimé quelque chose il y a plusieurs mois et, une fois que nous nous sommes rendu compte de ce qu'un récit similaire a réellement pris, nous pourrions accepter de procéder à une nouvelle estimation. (Nous utilisons des points d’histoire sans unité , et nous n’estimons pas les tâches ).

En outre, si le responsable de projet a ajouté de nouvelles histoires qu'il considère comme hautement prioritaires, le moment est venu de les estimer.

Étant donné que nous ne sélectionnons pas d'histoires avant le lendemain, ce processus donne un peu plus de temps à l'OP pour lui permettre de se prononcer de manière définitive sur ce qu'il est le plus important de faire lors de la prochaine itération - ce qui s'est avéré très utile.

Cette réunion a tendance à être courte avec certains OP et longue avec d'autres. (personnellement, je pense que c'est un excellent indicateur d'odeur de la façon dont votre bon de commande se porte)

Sélection de l'histoire

Obtenez votre Chris Voss , il est temps de négocier.

Lors de cette réunion, nous prenons les articles prioritaires et définissons un DoD pour chacun. Nous négocions ce que chacun impliquera - diviser et combiner les histoires au besoin - jusqu'à ce que nous puissions tous nous mettre d'accord sur nos objectifs de Sprint.

Nous avons beaucoup à gagner de la fraîcheur des idées et de l'énergie du matin pour cette réunion - et savoir que nous aurons à faire les tâches un autre jour nous permet de passer le temps nécessaire pour bien négocier et comprendre nos engagements.

les tâches

Ok, donc je serai le premier à dire, les tâches était mon MOINS partie préférée de la planification dans nos vieilles réunions d'un jour.

Nous n'avons tout simplement jamais atteint notre objectif avec cela. Nous avons essayé d'économiser des tâches jusqu'à la fin de la réunion - mais nous étions tous épuisés à ce moment-là et c'était vraiment improductif. Nous avons essayé de définir les tâches en même temps que notre DoD lors de nos négociations, mais nous avons trouvé cela trop gênant et trop encombrant - nous nous épuisions avant de sélectionner toutes les histoires. En outre, il était vraiment difficile de continuer à faire la navette entre l'estimation, la négociation, la sélection des histoires et la génération de tâches. Nous nous sommes battus et ça a été nul, et cela a rendu nos réunions affreuses.

Mais maintenant, en définissant le DoD un jour et en ne faisant pas de tâches avant le lendemain, nous ne sommes pas épuisés, nous sommes toujours dans le bon état d'esprit et cela nous laisse toute une journée pour mariner sur l'histoire et vraiment. réfléchissez et comprenez toutes les tâches avant de commencer.

Cela seul, à mon humble avis, est un changeur de jeu total.

Mettre tous ensemble.

Voici donc à quoi ressemble notre calendrier de la cérémonie de sprint:

• Monday - Daily scrum -> Revue de sprint
• Mardi - Mêlée quotidienne -> Entretien du carnet de commandes
• Mercredi - Scrum quotidien -> Sélection de l'histoire
• Jeudi - Scrum quotidien -> Tâches
• Vendredi - Scrum quotidien -> Rétrospective

Cela a très bien fonctionné pour nous. Si vous tentez votre chance, j'aimerais entendre ce que vous pensez.

Nous organisons un sprint hebdomadaire avec une réunion d'une heure au cours de laquelle nous discutons du sprint précédent, de ce qu'il reste à faire, puis passons à la planification de la semaine à venir. Tous dans une heure.

C'est bien sûr parce que nous avons découvert que dans notre cas, suivre scrum de manière trop stricte ne ferait que perdre trop de temps. En effet, la plupart des histoires font déjà l'objet de discussions avec les membres de notre équipe lorsque le demandeur crée la user story.

Je dis simplement que si votre équipe craint les réunions de planification, vous devriez probablement laisser aller certaines des «règles» de la mêlée.

La réponse à cette question a été complète, mais une seule chose est nécessaire pour que cela fonctionne et soit amusant.

Donner du pouvoir à l'équipe. - C'est-à-dire, faites-les travailler sur des choses qui leur semblent les plus importantes.