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 items
arriéré, il doit être en bon état.
Dans la phase de planification concrète, les 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 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 Backlog
est 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 master
efficacement la position du à modéré.