Comment gérer une planification de sprint trop longue?
J'ai pris plus de 5 heures en planification de sprint pour une semaine de sprint. 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 les sprints d'un mois et dit que "pour les 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 délai 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 une amélioration efficace du Backlog et de la planification du sprint 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 une 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 essayé plusieurs expériences avec des résultats mitigés:
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 à l'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 en matière de 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!
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.
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 cela. 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 lorsqu'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 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 que vous ne puissiez pas réduire le temps que vous passez future planification de sprint
Je ne suis pas un aficionado de la mêlée et je n'ai qu'une année 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 savoir quelles sont les priorités actuelles et
- pour développer un plan de bataille pour le prochain sprint.
Pour ce faire, chaque partie doit comprendre le Product Backlog items.
Afin de comprendre le Product Backlog items l'arriéré doit être en bon état.
Dans la phase de planification concrète, le Product Backlog items sont 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 place à trop d'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'un autre côté: la planification de Sprint attend un comportement professionnel de chaque participant. Cela implique d'éviter les discussions bikeshedding.
Peut-être que les choses sont claires, mais quelqu'un commence une discussion bikeshedding.
Plus: Évitez les discussions sur détails d'implémentation. Bien que chaque idée se retrouve dans le code à un moment donné, ce n'est pas l'objet de la planification du sprint de discuter, 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 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 Backlog est en bonne forme, 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 tous de nos 2 millions de clients?"
OTOH: Que signifie dans ce contexte refonte signifie? Si un développeur a choisi un algorithme performant lent, alors l'objectif suivant 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 ). Pour y faire face efficacement, utilisez autant de redondance que possible dans votre communication: par ex. expliquer le contexte de l'item en détail, 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 vous planifiez le poker un bon indicateur, si la compréhension est assez bonne, est que les tâches sont noté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 vous aide, utilisez anglais simple ou
ELI5) pour éviter les malentendusAmé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
Renforcer la position du
scrum masterà modérer efficacement.