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?

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.

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.

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

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é.

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.