Comment rendre la planification de sprint amusante
Non seulement nos réunions de planification de sprint ne sont pas amusantes, mais elles sont carrément épouvantables.
Les réunions sont fastidieuses et ennuyeuses et prennent une éternité (une journée, mais cela semble beaucoup plus long).
Les développeurs s'en plaignent et redoutent les planifications à venir.
Notre routine est assez standard (user story insérée dans le backlog de sprint par priorité >> story est démontée aux tâches >> les tâches sont estimées en heures >> répéter), et je ne peux pas comprendre ce que nous faisons de mal.
Comment rendre les réunions plus agréables?
...
Quelques détails supplémentaires, en réponse aux demandes d'informations complémentaires:
Pourquoi les éléments du backlog ne sont-ils pas insérés et priorisés avant le lancement 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 constate que nous ne devrions peut-être pas du tout estimer les tâches, uniquement les user stories. La raison pour laquelle nous estimons des tâches (et non des histoires) est parce que nous avons obtenu 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?
Les réunions sont longues.
Les réunions sont monotones. Histoire après histoire, tâche après tâche, du mal (oui, du mal) à estimer combien de temps cela prendra et ce que cela implique.
L'estimation des tâches rend l'estimation de l'histoire de l'utilisateur inutile.
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. Une spirale haineuse récursive se développe. Nous avons envisagé de diviser la réunion en deux jours afin de garder les gens concentrés, mais les développeurs n'en entendraient pas parler. Une journée de planification est déjà assez mauvaise; maintenant nous aurons deux ?!
Une partie de notre problème est que nous entrons dans les moindres détails (afin d'obtenir des estimations plus précises). Mais lorsque nous estimons grosso modo, nous allons loin de la cible!
Pour résumer la question:
Que faisons-nous de mal?
Quelles sont les autres façons de rendre la réunion généralement plus agréable?
Rendre l'estimation plus facile
Décomposez votre planification de sprint.
Avez-vous besoin pour estimer les tâches individuelles? J'ai planifié le sprint de deux manières:
- Les histoires sont estimées en points d'histoire, puis les tâches sont estimées en heures
- Les histoires sont estimées en points d'histoire et les tâches relèvent simplement de cela 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 que une tâche n'est pas applicable ou a déjà été effectuée dans un sprint précédent) vous la jetez simplement sans aucune pénalité, ou vous devrez peut-être changer une tâche en cours en quelque chose de nouveau, éventuellement en la cassant. Vous êtes vraiment redondant si vous estimez les deux, car la somme des tâches devrait représenter les points d'histoire et vice versa. Quelle valeur tirez-vous vraiment de cela autre que de savoir combien de temps les tâches individuelles prendront? Si vous vous retrouvez avec des tailles de tâches qui varient vraiment suffisamment pour faire la différence, je suggérerais de diviser ces tâches en morceaux plus petits et plus homogènes.
En faisant cela, vous pouvez réduire le temps que vous passez dans la planification du sprint . Les histoires sont estimées lors de la planification du sprint, et lorsque vous démarrez le sprint, vous pouvez noter toutes les tâches auxquelles vous pouvez penser qui composent cette histoire. De toute évidence, s'il y a des points que vous rencontrez dans l'estimation de l'histoire que vous savez devrez traiter dans une tâche, vous pouvez l'ajouter aux informations de l'histoire et la mettre comme tâche.
Estimation en unités idéales
Les points d'histoire sont censés être en idéal unités telles que les heures de travail idéales ou les jours de travail idéaux. Cela signifie que, étant donné la journée parfaite chaque jour, où vous n'avez eu aucune interruption, aucune réunion, et tout s'est déroulé comme prévu, vous pouvez 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écessairement le cas.
Ce que je veux dire par là, c'est qu'après un certain temps pour les estimer dans des jours idéaux, vous vous rendez compte qu'il faut peut-être 25% de temps supplémentaire en moyenne pour terminer une histoire. Disons que vous aviez estimé 4 jours de travail idéaux, et au lieu de cela il vous en a fallu 5. Au fil du temps, vous gardez une trace de cela, 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. L'essentiel 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 encore ne pouvez pas obtenir une estimation décente, peut-être que cela signifie que vous ne connaissez pas assez l'histoire pour pouvoir l'estimer correctement.
Parlez des histoires
Lorsque vous estimez, tout le monde devrait avoir une idée approximative de ce qui devra être fait, du début à la fin, de ce qu'il faudra pour cette histoire être complet. Vous n'avez pas besoin de connaître tous les détails, mais suffisamment pour que vous pensiez que vous-même pourriez 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 grande pour que nous connaissions la plupart des détails", cela indique que l'histoire est trop grande et doit être décomposée. Les histoires, au moins d'après mon expérience, ont été suffisamment petites pour qu'une personne, si besoin est, puisse y travailler seule et l'accomplir en une semaine ou deux.
Cela vous 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 histoire, vous estimez simplement l'histoire dans son ensemble, ce qui devrait aider à supprimer une grande partie de l'estimation. Quant à rendre les réunions moins monotones, je suggère de planifier le poker, dont vous pouvez voir plus d'informations ci-dessus.
Rendez la planification plus engageante
Estimer avec Planning Poker
En ce qui concerne l'estimation plus amusante, avez-vous essayé planifier le poker ? C'est la façon dont j'ai toujours planifié tous mes sprints sur plusieurs équipes, et c'est un bon moyen de maintenir 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 inscrit un 20 et doit s'expliquer, ou lorsque tout le monde dans l'équipe inscrit un 5 mais que le manager inscrit un 8 (qui va discuter avec le patron quand il veut vous donner plus de temps!).
Pour ce faire, il vous suffit de planifier des cartes de poker , que nous fabriquons souvent au verso des fiches, ou d'utiliser des cartes à jouer normales avec des valeurs attaché aux cartes de visage. Rien d'extraordinaire et tout le monde reste concentré. N'oubliez pas qu'essayer de faire n'importe quelle tâche pendant une journée entière (y compris la planification du poker) a un impact négatif sur la productivité. De nombreux jeux de cartes sont livrés avec une carte de café pour une raison; si quelqu'un se sent épuisé, donnez à l'équipe une pause pour se ressourcer et ramasser quand tout le monde est frais!
Comme alternative aux cartes physiques , vous pouvez également consulter cartes électroniques . Les vrais avantages ici sont le suivi automatisé des résultats, le suivi des histoires d'utilisateurs à estimer et permettre à chacun de montrer ses cartes à la fois pour éviter la "tricherie" (où une personne estime être influencée par une autre en raison de la possibilité de voir sa carte). Évidemment, cela nécessite que tout le monde ait un ordinateur et la capacité de se concentrer sur la tâche à accomplir, alors utilisez-le à votre discrétion.
Pourquoi les éléments du backlog ne sont-ils pas insérés et priorisés avant le lancement du sprint? Perdre du temps aux développeurs n'est pas amusant. Laissez vos chefs d'équipe travailler avec le propriétaire du produit et le chef de projet quelques jours à l'avance pour prioriser les choses. Cela vaut également pour la planification des membres de chaque équipe de sprint.
Pourquoi faut-il une journée pour décomposer les choses en tâches? Si vous avez une équipe de taille raisonnable (2-4 développeurs, 0,5-5 personnes QA par développeur, 1-2 misc), alors vous devriez avoir 2-4 histoires d'utilisateurs ce sprint. Passez environ 30 minutes avec le propriétaire du produit à clarifier les exigences, puis environ 30 minutes pour les répartir en tâches de ~ 8 heures. N'entrez pas les tâches pendant la réunion. Convenez simplement en équipe quelles sont les tâches suffisantes pour que les personnes sensées les comprennent, qui en est responsable et combien de temps cela devrait prendre. Convenez que "combien de temps ils devraient prendre (y compris les tests)" s'intègre confortablement dans le sprint.
Si ce n'est pas seulement de diviser les choses en tâches, que faites-vous d'autre? Bien sûr, les rétrospectives peuvent prendre 30 à 60 minutes, mais elles seront plus courtes à mesure que les équipes s'engouffreront.
Donc en résumé - arrêtez de perdre du temps et ils redouteront un peu moins les réunions. Au-delà de cela, le plaisir et la camaraderie dans l'équipe ne sont pas quelque chose que vous pouvez aborder lors des réunions. Allez déjeuner ensemble, plaisantez, mélangez les gens pour avoir une meilleure personnalité, organisez des concours de moustache ... une fois que le moral est en place, 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 dont j'ai entendu parler par d'autres équipes:
- Créez et hiérarchisez des user stories sans toute l'équipe. Le propriétaire du produit et/ou le maître de mêlée peuvent gérer une grande partie du travail chargé et laisser simplement l'équipe l'ajuster.
- Rendez votre carnet de commandes beaucoup plus long qu'un seul sprint. La construction peut prendre un certain temps, mais si votre carnet de commandes est suffisamment long, les réunions de planification sont réduites à de petits ajustements ou à la gestion des développements commerciaux récents.
- Organisez des réunions d'estimation distinctes 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'ordre du jour. Ceci est utile si vous perdez souvent du temps à attendre le retour d'un ou deux membres de l'équipe.
- Arrêtez-vous au milieu de la réunion et affectez tout le monde à une ou deux histoires d'utilisateurs, puis revenez ensemble pour faire rapport et obtenir un consensus.
- Assurez-vous que votre réunion de planification concerne quoi à faire, pas comment à faire. Les ingénieurs tombent très facilement dans ce dernier. Si vous en avez besoin, organisez des réunions de conception distinctes où vous discutez du comment.
- Séparez vos histoires en enquête et en 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 pendant 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 sur quelque chose dont vous ne savez rien, faites une histoire d'enquête pour apprendre l'API, faites une simple application "bonjour le monde" et enseignez-la à l'équipe. Ensuite vous serez équipé pour planifier le travail réel. - Gardez une trace lors de vos réunions de problèmes spécifiques. Pas seulement "la planification est ennuyeuse", mais un niveau de détail comme "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 dans vos rétrospectives et réfléchissez à des solutions spécifiques. Décomposez votre problème jusqu'à ce que les pièces soient faciles à résoudre.
Nous organisons notre sprint de planification et de rétrospective en même temps, et nous nous faisons presque toujours en 90 minutes, mais nous sommes l'une des équipes les plus rapides. Nous faisons une grande planification à long terme à l'échelle de l'entreprise tous les 5 sprints qui prend 4-6 heures. Chaque équipe est différente, bien sûr, mais si vous passez une journée entière à chaque sprint, il y a beaucoup de place à l'amélioration.
Vos séances de planification sont bien 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 en cours de planification (par exemple, un sprint de 2 semaines devrait prendre au maximum 1/2 journée), mais les réunions réussies devraient être plus courtes que cela (la moitié).
Dans votre cas particulier: pourquoi estimez-vous les tâches? Vous ne devez estimer que les histoires lors de la planification. Les tâches peuvent être estimées ultérieurement par le propriétaires de tâches spécifiques.
Une façon qui a fonctionné pour moi:
- Introduction rapide au sprint par le PO
- Estimation de la capacité de sprint
- Les histoires se déroulent et planifient le poker (timeboxed à 5/10 minutes par histoire) jusqu'à ce qu'il y ait suffisamment de choses estimées pour couvrir le sprint
- Engagement officiel/prévision de l'équipe
Ensuite, en parallèle/paires/auto organisé à nos bureaux, tâche et estimation des tâches.
Lors de mon travail précédent, le premier jour entier de chaque sprint (nous les appelions itérations ici) était occupé 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 à retourner au travail en attachant les dernières extrémités libres du travail de ce sprint, donc nous pensait qu'il valait mieux s'assurer que le travail était derrière nous avant de le repenser. Il a également semblé logique de consolider tous les frais généraux de la réunion du processus Scrum afin que les autres jours puissent être planifiés et passés en termes plus idéaux. Cela prenait généralement 2 heures.
- Planification du sprint. L'arriéré a été estimé lors d'une réunion de planification d'étape (qui pourrait être une journée entière en soi pour les développeurs et les OP), et avait été priorisé par les OP avant le début de chaque sprint. . Nous avons déterminé le nombre de jours de développement dont nous disposions (en tenant compte des vacances, des vacances, etc.), avons saisi le travail que nous pensions pouvoir faire du haut de la pile et avons rapidement examiné les exigences des utilisateurs (précédemment approuvées par nos BA) pour avoir une idée plus complète de ce que le travail a impliqué que nous avons obtenu avec la simple vue d'ensemble pendant le MPM. Cela prenait généralement 2 heures supplémentaires.
- Planification des tâches. Connaissant les histoires et les critères d'acceptation, nous avons divisé chaque histoire en tâches de la taille d'une bouchée estimées en heures idéales (une heure consacrée uniquement à la réalisation de cette tâche sans distractions ni barrages routiers) . La façon dont notre échelle de points a fini par être calibrée, un 5 était un sprint de développeur, donc un 1 pourrait être n'importe quoi jusqu'à et y compris deux jours de développeur. Pour cette raison, pratiquement tout devait être décomposé afin que les membres de l'équipe puissent montrer les progrès sur le tableau de mêlée. Ce fut un autre bloc de 2 heures, avec un peu de compromis entre cela et l'élément suivant.
- AAT Outlining. Nos PO et BA n'étaient pas des programmeurs et ne codaient pas. Les OP se sont cachées derrière un contrat stipulant qu'elles fourniraient les exigences sous la forme d'un modèle Word et travailleraient avec les BA 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 que le système existe, afin qu'ils puissent enregistrer leurs macros dans Selenium). Donc, pour vérifier que notre code répondrait aux critères d'acceptation en ce qui concerne cela, nous avons dû rédiger nos propres AAT modélisant les actions du test d'acceptation "papier". Nous avons généralement fait cela dans le même framework NUnit que nous avons utilisé pour les tests unitaires et d'intégration (nous avons essayé FitNesse et n'avons pas pu l'abandonner assez rapidement). Ce fut le reste de notre première journée de chaque sprint et a continué dans la seconde.
Dans mon travail actuel, nous adoptons toujours le processus Scrum, nous n'avions pas de planification d'étape à l'échelle de l'équipe et une grande partie de ce sur quoi nous travaillons n'a pas de critères d'acceptation stricts. Ainsi, notre planification de sprint est autant une explication de ce que chaque histoire implique et de ce que nous appellerons fait que c'est un engagement à saisir les X meilleures heures de travail idéales. Nous nous en sortons - du moins pour l'instant - parce que nous sommes une équipe interne et chacun de nous travaille personnellement avec les utilisateurs finaux de notre logiciel pour rassembler les exigences et concevoir des solutions. Même alors, la planification du sprint est une chose toute la matinée tous les deux lundis, et l'après-midi est consacré à franchir tous les obstacles personnels pour pouvoir commencer le développement sérieusement mardi.
Pour répondre réellement à la question du PO plutôt que de contraster d'autres commentaires/réponses disant que cela ne devrait pas prendre autant de temps, il existe des façons d'aborder l'estimation Agile, la planification de sprint et les rétrospectives qui sont un peu plus intéressantes que celles que vous pourriez utiliser.
Répondre spécifiquement à vos préoccupations:
Les réunions sont longues - Time-box them. Chaque réunion, qu'il s'agisse d'une rétrospective, d'une planification de sprint, d'une répartition des tâches, etc., devrait avoir un objectif et un sujet de discussion précis, et devrait être limitée autant que possible à une durée déterminée. C'est le travail du Scrum Master de garder ces réunions sur le sujet et de rouler pour atteindre les objectifs de temps.
Les réunions sont monotones - Il y en aura en partie; vous travaillez en petits morceaux, un par un, vous ferez donc la même chose encore et encore. Garder l'équipe concentrée et conduire vers l'accomplissement du but de la réunion aidera.
Quelque chose d'autre que j'entends, c'est que peut-être vos réunions de planification de sprint essaient d'accomplir trop. Dans ma dernière entreprise, l'estimation de l'histoire a été faite lors de "réunions de planification d'étapes", qui ont eu lieu environ une fois par trimestre et ont pris toute la journée. Lors de ces réunions, tout ce qui s'était accumulé sur l'arriéré que nous n'avions pas estimé était estimé en points. Si vous faites une estimation de l'histoire en points, puis une estimation de la tâche en heures, vous ne voulez pas faire les deux en même temps (peut-être le même jour).
Estimer les histoires en points, puis les tâches en heures semblent redondantes - Elles ont deux objectifs différents. Le but de l'estimation de l'histoire est de fournir une estimation approximative de la complexité, que vous pouvez utiliser pour remplir votre backlog de sprint en fonction de la vitesse passée et de la bande passante attendue. Le but de l'estimation des tâches est de décomposer les histoires en éléments qui prennent un jour de développeur ou moins (et peuvent donc être attribués à un seul gars qui devrait tout faire à temps), et vous assurer que vous ne l'avez pas fait mal évalué la complexité d'une histoire ni mordu plus que vous ne pouvez mâcher dans le sprint.
Si toutes vos histoires prennent un jour ou moins, alors c'est redondant, mais toutes les échelles de points ne sont pas calibrées de la même manière; lors de mon dernier travail, un 5 était deux semaines de développeur (car au début, nous avions beaucoup d'épopées à estimer), ce qui, sur une échelle linéaire, faisait la différence entre 2 jours de développeur. Compte tenu de ce type d'échelle, pratiquement tout devrait être divisé en tâches. Dans ma nouvelle entreprise, un point est plus proche d'une demi-journée de développeur, donc un 1 ou même un 2 est certainement sa propre tâche, et 3-8 est nébuleux en ce qui concerne le fait de forcer l'équipe à le diviser en tâches.
Il y a un cercle vicieux qui prend plus de temps, ce qui rend les gens moins concentrés, donc cela prend plus de temps - Time-box votre time-box. Faites des pauses, comme vous devriez le faire lors du codage. Toutes les 30 minutes, prenez 5 minutes pour vous dégourdir les jambes, vous regrouper, etc. Vous pouvez le faire dix minutes toutes les heures, mais ne poussez pas trop loin un bloc solide de temps de réunion. Vos gars peuvent avoir faim, ou avoir besoin de plus de café, ou d'une pause dans la salle de bain, etc. Ne les niez pas; si vous les faites aspirer, vous verrez leur esprit vagabonder. Au-delà de cela, garder les discussions courtes, douces et pertinentes aidera également, comme mentionné précédemment.
La réunion de planification Sprint comprend 2 parties:
- Décidez de ce que l'équipe fera
- Décidez comment l'équipe le fera.
La première partie est relativement simple - en fonction du nombre de points d'histoire que l'équipe estime pouvoir assumer, l'engagement à terminer autant d'histoires d'utilisateurs dans leur ordre de priorité. Terminé.
La deuxième partie est ce que les développeurs devraient réellement apprécier - l'élaboration de l'histoire et la conception de la solution. Les tâches en découlent. Donc, demandez au propriétaire du produit, ou quoi que ce soit SME qu'il a fourni, d'expliquer l'histoire choisie. Ensuite, demandez au développeur de le faire, dirigez la discussion de conception. Utilisez un tableau blanc. . S'amuser.
Voilà, vraiment. Si les réunions de conception ne sont pas amusantes, il y a tout simplement quelque chose de mal.
Oui, je sais que c'est une vieille question, mais j'ai une nouvelle réponse. : P
Divisez la réunion.
Nous avons divisé notre réunion de planification Sprint en 3 mini-réunions distinctes
- Toilettage de l'arriéré
- Sélection d'histoires
- 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 fait chuter notre planification: -O
J'entrerai dans plus de détails sur ce qui est impliqué dans chaque session dans une seconde, mais permettez-moi d'expliquer comment nous en sommes arrivés là.
Nous avons, comme vous, eu un problème avec des réunions de planification Sprint vraiment épouvantables. Nous avions tous les bons éléments, mais tout a pris une éternité et était vraiment épuisant mentalement et émotionnellement pour passer.
Puis j'ai eu cette idée après avoir lu cet article de Business Insider sur les 5 minutes quotidiennes de Pivotal sur la façon de diviser nos réunions en sessions plus courtes et de les faire au début de chaque journée.
Je l'ai évoqué avec l'équipe lors d'une rétrospective. Certains membres de l'équipe l'ont aimé tout de suite, d'autres étaient un peu inquiets, mais notre stagiaire a ensuite mentionné une étude qu'il a lue sur la technique pomodoro et a commencé à en parler, et cela a vraiment aidé l'idée à gagner du terrain.
Nous avons donc décidé de l'essayer.
Nous avons divisé notre réunion de 2 heures en trois sessions de 25 minutes. (oui, ce sont des mathématiques floues, mais tout le monde pensait que nos réunions étaient trop longues et ne voulaient le faire que si nous gagnions du temps).
Et ça a marché! Nous le faisons depuis environ 6 semaines maintenant sur deux projets distincts (6 sprints de deux semaines au total) 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 boîte de temps de 25 minutes est assez lâche - certaines sessions vont très vite, comme 5-10 minutes sur certaines de nos sessions de toilettage, et certaines durent longtemps, comme lorsque nous finissons par identifier de nouvelles histoires ou devoir casser des histoires et réestimer pendant la négociation. Dans l'ensemble cependant, cela ne dure généralement pas plus de 1,5 heure pour l'ensemble du Shebang, et je pense que c'est pourquoi cela fonctionne si bien.
Sur les détails .....
Toilettage de l'arriéré
Assez simple - nous passons en revue les histoires les plus prioritaires, parlons de ce qu'elles impliquent et vérifions que nos estimations sont bonnes.
Nous réévaluerons les histoires si nécessaire - comme disons que nous avons estimé quelque chose il y a des mois et après avoir réalisé ce qu'une histoire similaire a réellement pris, nous pourrions accepter de réestimer. (nous utilisons points d'histoire sans unité soit dit en passant, et nous ne pas estimer les tâches ).
De plus, si l'OP a ajouté de nouvelles histoires qu'il juge prioritaires, c'est le moment de les estimer.
Parce que nous ne faisons pas de sélection d'histoires avant le lendemain, ce processus donne au PO un peu plus de temps pour faire un jugement final sur ce qui est le plus important à faire dans la prochaine itération - et cela s'est avéré très utile.
Cette réunion a tendance à être courte avec certains PO et longue avec d'autres. (personnellement, je pense que c'est un excellent indicateur de l'odeur de votre PO)
Sélection d'histoires
Obtenez votre Chris Voss sur, il est temps de négocier.
Lors de cette réunion, nous prenons les histoires prioritaires et définissons un DoD pour chacune. Nous négocions ce que chacun impliquera - diviser et combiner les histoires selon les besoins - jusqu'à ce que nous puissions tous nous mettre d'accord sur nos objectifs de Sprint.
Nous avons beaucoup d’avantages à avoir un esprit neuf et cette bonne énergie du matin pour cette réunion - et le fait de savoir que nous accomplirons des tâches un autre jour nous permet de passer le temps dont nous avons vraiment besoin pour bien négocier et comprendre nos engagements.
Tâches
D'accord, je serai donc le premier à dire que les tâches ont été mon [~ # ~] moins [~ # ~] partie préférée de la planification de nos anciennes réunions d'une journée.
Nous n'avons tout simplement jamais atteint notre rythme avec cela. Nous avons essayé de sauvegarder les tâches jusqu'à la fin de la réunion - mais nous étions tous épuisés et c'était vraiment improductif. Nous avons essayé de définir des tâches en même temps que notre DoD pendant notre négociation, mais nous l'avons trouvé trop distrayant et trop lourd - nous nous épuisions avant de sélectionner toutes les histoires. De plus, il était très difficile de continuer à changer de focus/réflexion entre l'estimation, la négociation, la sélection de l'histoire et la génération de tâches. Nous avons lutté, 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 nous épuisons pas, nous sommes toujours dans le bon état d'esprit, et cela nous donne une journée entière pour nous plonger dans l'histoire et vraiment réfléchir et comprendre 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 cérémonie de sprint:
- Lundi - mêlée quotidienne -> Revue de Sprint
- Mardi - mêlée quotidienne -> Toilettage de l'arriéré
- Mercredi - mêlée quotidienne -> Sélection d'histoires
- Jeudi - mêlée quotidienne -> Tâches
- Vendredi - mêlée quotidienne -> Rétrospective
Cela a très bien fonctionné pour nous. Si vous lui donnez un coup de feu, j'aimerais entendre ce que vous en pensez.
Nous avons un sprint hebdomadaire avec une réunion d'une heure au cours de laquelle nous discutons du sprint précédent, de ce qui reste à faire, puis passons à la planification de la semaine à venir. Le tout en une heure.
C'est bien sûr parce que nous avons découvert que dans notre cas, suivre scrum trop strictement ne ferait que perdre trop de temps. En effet, la plupart des histoires sont déjà discutées avec les membres de notre équipe lorsque le demandeur crée l'histoire utilisateur.
Je dis simplement que si votre équipe redoute de planifier des réunions, vous devriez probablement abandonner certaines des "règles" de la mêlée.
Cette question a reçu une réponse complète, mais une seule chose est nécessaire pour le faire fonctionner et être amusant.
Donner du pouvoir à l'équipe. - c'est-à-dire les faire travailler sur des choses qui ils pensent être les plus importantes.