Comment gérer une planification de sprint trop longue?


14

J'ai pris plus de 5 heures dans la planification du sprint pour un sprint d'une semaine. Cela semble trop.

Nous discutons des choses en détail dans la planification du sprint, car la plupart des membres de l'équipe ne sont pas seniors. Si nous ne le faisons pas, cela entraînera des erreurs lors de la mise en œuvre et une refonte pendant le sprint.

Comment gérons-nous cela?

Combien de détails dois-je discuter lors de la planification pour l'adapter à seulement 2 heures de sprint par semaine?


2
Que faites-vous exactement dans Sprint Planning? Êtes-vous en train de décomposer des histoires, d'affiner les exigences, de concevoir, d'estimer?
Liath

1
Merci j'ai oublié de le dire. Nous passons la plupart de notre temps à faire du design.
b.ben

1
Faites-vous le nettoyage de l'arriéré lors d'une réunion séparée? Nous avons généralement un carnet de commandes temporel à 1 heure par sprint et une planification de sprint à 1 heure par sprint. Cela a bien fonctionné pour nos sprints de 2 semaines.
Berin Loritsch

4
@ b.ben mais le "design" ne fait pas partie de la planification du sprint.
Thomas Junk

2
euh attendez, pourquoi parlez-vous de la mise en œuvre lors de la planification du sprint? La planification du sprint concerne ce qui n'est pas comment .
candied_orange

Réponses:


20

Vous avez raison - 5 heures en Sprint La planification d'un sprint d'une semaine semble longue. Le Scrum Guide fixe les délais Sprint Planning à 8 heures pour des sprints d'un mois et dit que "pour des sprints plus courts, l'événement est généralement plus court". Si vous considérez le ratio, un bon objectif peut être 2 heures de planification de sprint pour un sprint d'une semaine, mais il n'y a pas de plage horaire fixe.

Alors, comment pouvez-vous aborder une longue planification de sprint?

En tant que Scrum Master, je prendrais les mesures suivantes:

Tout d'abord, je travaillerais avec le Product Owner pour m'assurer que le Product Backlog est correctement commandé. Il est essentiel pour un affinement du backlog et une planification de sprint efficaces de s'assurer que le travail le plus important et leurs dépendances sont en haut du backlog du produit afin que l'équipe Scrum puisse concentrer ses énergies sur la définition, le raffinement et la préparation du bon travail.

Deuxièmement, je m'assurerais que l'équipe consacre suffisamment de temps au raffinement du carnet de commandes. Le Scrum Guide indique que les activités de raffinement ne prennent généralement pas plus de 10% de la capacité d'une équipe de développement. Par exemple, une équipe de développement de 4 personnes travaillant une semaine standard de 40 heures devrait prévoir environ 16 heures de perfectionnement du carnet de commandes. Cela peut être fait individuellement, en petits groupes ou en équipe. J'ai constaté que le fait d'avoir une session de perfectionnement de l'arriéré planifiée pour l'équipe, puis de faire des recherches, des enquêtes ou de la planification a tendance à fonctionner le mieux.

Troisièmement, assurez-vous que l'équipe se rend compte qu'elle n'a pas besoin d'obtenir tous les détails dans Sprint Planning. L'objectif de Sprint Planning est de produire un plan pour atteindre les objectifs de Sprint. N'essayez pas de faire un grand design dès le départ lors d'une session de planification de sprint. Comprendre comment les différents travaux s'intègrent, les dépendances et les objectifs et utiliser le temps en dehors des sessions de planification de sprint avec les bonnes personnes pour faire la conception, la mise en œuvre et les tests nécessaires pour livrer le travail.

D'autres étapes pourraient en découler, mais ce serait un bon point de départ.


3
Fondamentalement, l'équipe passera toujours le même nombre d'heures en réunions. Nous les appelons simplement différentes réunions. :) Il faut ce qu'il faut pour décomposer les choses suffisamment pour que l'équipe se sente à l'aise d'estimer le travail et pour être indépendante quand vient le temps de faire le travail.
Greg Burghardt

5
@GregBurghardt: OP écrit qu'ils passent la plupart de leur temps à concevoir. Ainsi, toute l'équipe travaille sur la conception de chaque histoire. Si vous divisez cela de manière à ce qu'une partie seulement de l'équipe travaille sur chaque histoire respective, vous réduisez le temps total consacré aux réunions.
Michael Borgwardt

Re: "assurez-vous que l'équipe se rend compte qu'elle n'a pas besoin d'obtenir tous les détails dans Sprint Planning": Et, plus important encore, assurez-vous qu'il est vrai qu'ils n'ont pas besoin d'obtenir tous les détails dans le panoramique de sprint .
ruakh

@GregBurghardt Peut-être. Mais il y a une différence entre toute l'équipe qui est dans une pièce pendant 5 heures et différentes combinaisons de personnes qui ne font pas de travail de conception pendant 3 heures après une session de planification de 2 heures.
Thomas Owens

5

Je t'entends. C'est trop long à dépenser! Espérons que votre équipe en discute dans vos rétrospectives. Nous avons tenté plusieurs expériences avec des résultats mitigés:

  1. Tout le monde fait une conception de haut niveau sur un seul ticket et le passe à gauche ou à droite autour de la table pour révision, suivi d'un examen de groupe du plan pour chaque ticket. Tout le monde n'a pas aimé cela, mais cela a obligé nos juniors à essayer. Certaines personnes dans les équipes sont très heureuses de laisser les autres réfléchir et de suivre les instructions. Donc, du côté positif, notre expérience a forcé tout le monde à faire face à leurs lacunes dans les connaissances, elle a constitué un défi de croissance pour les juniors. Du côté négatif, tout le monde n'aime pas être mis sur la sellette et cela ne réduit pas nécessairement le temps de la réunion. Prochain!

  2. Des conceptions par paires ont été tentées. Des groupes de deux ou trois diviseraient un ticket en tâches. Toute l'équipe examinerait les plans obtenus. Cela est allé beaucoup plus vite, mais certains mini-pods ont eu le même problème qu'une personne chevauchant tandis que l'autre faisait le travail sur la conception.

  3. Ignorez la répartition des tâches. Nous avons décidé que nos points d'histoire étaient en moyenne, donc nous perdions juste du temps à essayer d'impliquer toute l'équipe dans tout. En conséquence, nous avons eu des réunions de planification beaucoup plus courtes, mais le travail de conception était quelque chose que nos paires devaient faire pour elles-mêmes quand elles ont commencé un ticket. Si les juniors travaillent sur un ticket, attendez-vous à ce qu'ils aient besoin d'aide pour franchir cette étape. Si vous essayez cela, vous avez accepté moins d'histoires dans le sprint jusqu'à ce que vous soyez à l'aise avec. Assurez-vous également qu'il est «sûr» pour vos coéquipiers de demander de l'aide lorsqu'ils ne savent pas quelque chose.

En fin de compte, cela revient à la maturité de l'équipe. Les gens doivent comprendre les capacités et les préférences des autres et avoir confiance que leurs coéquipiers demanderont leur avis quand ils en auront besoin. Corrigez-les d'abord, si vous ne les avez pas. Il devient alors plus facile de résoudre le problème des réunions inefficaces.


4
L'option n ° 3 engendre des équipes qui dépendent d'une seule personne ou d'un petit groupe de personnes. Si cette personne ou ces personnes ne sont pas là, la vitesse de l'équipe descend directement dans les toilettes. Je le faisais avec notre équipe, et chaque fois que cette personne partait en vacances, le chaos s'ensuivait. Rien n'a été fait. Ensuite, le chef d'équipe a passé 3 semaines à essayer de calmer la gestion de projet. Si vous travaillez dans une équipe avec des juniors ou des non experts, je ne recommanderais certainement pas # 3. Si vous avez tous les experts (et ils sont en fait des experts), le n ° 3 peut vous faire gagner du temps.
Greg Burghardt

Si cette personne fait juste la tâche de concevoir pour tout le monde, bien sûr, je suis d'accord. Mais que se passe-t-il si cette personne aide les gens à s'améliorer à le faire eux-mêmes?
Jason Zinschlag

2
D'après mon expérience, ils ne s'améliorent pas avec quelqu'un qui les guide à travers les choses. Cela se transforme en personnes expérimentées qui le font pour les moins expérimentés, car les moins expérimentés ont pris des ordres de grandeur plus longtemps. Nous avons eu plus de chance d'assoir tout le monde dans la pièce et de faire des tâches de développement. Même en passant par le code - mais pas pendant la planification du sprint. Nous l'appelons «écrire des tâches de développement» parce que c'est ce dont notre équipe avait besoin. Puis ils ont commencé à devenir indépendants, et ils ont commencé à devenir meilleurs et plus rapides à écrire des tâches de développement.
Greg Burghardt

Heureux que votre équipe ait trouvé un moyen. Pensez-vous que vos coéquipiers expérimentés prenaient la solution de facilité? Enseigner aux gens est un casse-tête, je sais. Mais cela rapporte de gros dividendes. La plupart des gens n'ont pas la patience pour cela, et je vois exactement ce que vous décrivez - les personnes expérimentées peuvent facilement perdre patience avec le processus et "le faire elles-mêmes". De plus, les juniors doivent être de bons apprenants.
Jason Zinschlag

@GregBurghardt J'ai du mal à faire quelque chose comme "écrire des tâches de développement" pendant la planification du sprint. Et je ne sais pas si ça va?
b.ben

3

J'aime la réponse que vous avez reçue de @ Thomas-Owens mais j'ajouterai également un autre élément. Avez-vous envisagé de faire de la programmation par paires dans le cadre de votre implémentation Agile?

La programmation par paires aiderait à (1) enseigner à certains de vos programmeurs juniors comment écrire un meilleur code et (2) à la programmation par paires, vous n'avez pas toujours besoin de disposer de toutes les fonctionnalités de conception pour la planification du sprint. Avec la paire travaillant ensemble, certaines de ces décisions de conception peuvent être prises «spontanément» avec les avantages supplémentaires de la programmation de la paire.

Si vous pouvez aider vos programmeurs juniors à apprendre plus rapidement et que vous savez que les éléments de conception que vous n'avez pas abordés dans Sprint Planning seront décidés par deux personnes, il n'y a aucune raison pour laquelle vous ne pourriez pas réduire le temps que vous passez future planification de sprint


Oui, c'est ce que je voulais. Mais notre équipe n'a pas assez de seniors pour le faire. Je viens avec une idée qui permettra à tous les membres des équipes d'écrire les abstractions et les interfaces qui leur sont propres, avant de commencer la mise en œuvre, faisons une réunion pour convenir entre tous les développeurs. Qu'est-ce que tu penses?
b.ben

1
@ b.ben Mais votre équipe n'aura jamais assez d'aînés tant que vous ne l'aurez pas fait. Cela fait partie de la puissance de la programmation par paires. Vous devez vous y engager.
Unknown Coder

1

Je ne suis pas un aficionado de la mêlée et j'ai seulement environ un an d'expérience pratique. Donc, ce qui suit doit être lu avec un grain de sel.

Je vois plusieurs drapeaux rouges dans ce que vous écrivez:

5 heures de planification de sprint

C'est beaucoup trop long pour un sprint d'une semaine.

L'objectif de la planification du sprint est AFAIR

  • permettre à l'équipe de connaître les priorités actuelles et
  • pour développer un plan de bataille pour le sprint à venir.

Pour le faire efficacement, chaque partie doit comprendre le Product Backlog items.

Afin de comprendre l' Product Backlog itemsarriéré, il doit être en bon état.

Dans la phase de planification concrète, les Product Backlog itemssont transformés en Sprint Backlog items.

Une cause possible est que ces éléments ne sont pas suffisamment clarifiés / raffinés.

Une autre cause possible est que les éléments sont beaucoup trop complexes et laissent trop de place à l'interprétation.

Discutez très en détail de la planification du sprint

Comme indiqué ci-dessus, la phase de discussion sera plus courte, lorsque les éléments seront plus concrets.

D'autre part: la planification de Sprint attend un comportement professionnel de chaque participant. Cela implique d'éviter les discussions de bikeshedding .

Peut-être que les choses sont claires, mais quelqu'un entame une discussion sur le vélo .

Plus: Évitez les discussions sur les détails de mise en œuvre . Bien que chaque idée se retrouve dans le code à un moment donné, ce n'est pas le but de la planification du sprint, de savoir si un simple tableau fera l'affaire, ou il sera préférable d'utiliser une liste chaînée.

Comme la plupart des membres de l'équipe ne sont pas des cadres supérieurs

En mêlée, il n'y a pas de distinction entre senior et junior . Les deux ne sont que des développeurs. Et c'est un bon point de départ, qui vous aide à garder votre discussion concentrée sur une solution viable soutenue par les meilleurs arguments et non par le chèque de paie.

Erreurs de mise en œuvre et de refonte pendant le sprint

Il semble y avoir un problème fondamental dans la collecte des exigences, suivi d'un arriéré de produits très vague.

Comme je l'ai dit ci-dessus: Tant que le Product Backlogest en bon état, il devrait être difficile de rater le point.

Je ne peux pas imaginer une situation comme:

»En tant qu'utilisateur, je veux voir une poignée de clients!«

"Oh, tu ne voulais pas dire chacun de nos 2 millions de clients?"

OTOH: Que signifie dans ce contexte une refonte ? Si un développeur choisit un algorithme à performances lentes , le prochain objectif est clair: choisissez-en un plus performant. Mais ce n'est pas une "refonte", c'est une optimisation.


À vos principales questions:

Comment y faire face?

C'est insignifiant à mentionner, mais je le fais quand même: N'oubliez pas que vous avez affaire à des humains .

Il est très difficile d'avoir un groupe d'esprits différents, capables de partager des concepts communs (comme dans Rashomon ). Afin de traiter efficacement cela, utilisez autant de redondance que possible dans votre communication: par exemple, expliquez le contexte de l'élément extensif, même si tout le monde "devrait savoir" quoi faire. Posez des questions, si tout le monde comprend le sujet d'un élément donné.

Si vous jouez à la planification du poker, un bon indicateur, si la compréhension est assez bonne, est que les tâches sont classées bas. Faible signifie faible complexité signifie facile à comprendre et difficile à manquer.

Un effet secondaire de l'itération est que les nombres pour certaines tâches augmenteront (parce que l'équipe a une compréhension de ses capacités et des complexités cachées). Ensuite, il est possible de décomposer l'élément en plusieurs éléments moins complexes avec une complexité moindre.

Combien de détails dois-je discuter lors de la planification pour tenir 2 heures de sprint par semaine?

Réponse salomonique: le moins possible et autant que nécessaire, mais pas plus.

tl; dr

  • Choisissez une langue facile (si cela aide, utilisez un anglais simple ou ELI5) pour éviter les malentendus

  • Améliorez la collecte des exigences

  • Améliorez l'arriéré

  • Augmenter la confiance des membres de l'équipe dans leurs capacités individuelles ainsi que leurs capacités en tant qu'équipe

  • Évitez le bikeshedding

  • Améliorer la discipline personnelle

  • Utilisez peut-être des délais fixes pour chaque élément à discuter

  • Renforcez scrum masterefficacement la position du à modéré.


-2

Nous avons réussi à réduire considérablement la planification du temps de réunion en effectuant un toilettage de trois heures au total en 2 semaines de sprints. Nous divisons le toilettage en quatre séances. nous faisons 30 minutes de toilettage le lundi et 1 heure de toilettage le mercredi chaque semaine. Nos sprints commencent le lundi et se terminent le vendredi. En conséquence, nous avons de bonnes informations provenant des réunions de toilettage qui contribuent à la planification, ce qui la raccourcit. Notre meilleur record a été une réunion de planification d'une durée de 30 minutes dans l'un de nos sprints. La plupart du temps, cela ne prend pas plus d'une heure à une heure et 30 minutes. Il est encore temps de toute façon, mais la planification a été faite très tôt.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.