Je vais ignorer toute la question de l'agilité devrait de laisser les équipes être libres de modifier leurs processus internes pour trouver quelque chose qui fonctionne efficacement pour elles, puisque d'autres réponses ont couvert cela.
Votre logiciel de tableau de bord permet-il des sous-tâches dans chaque histoire qui ne sont pas affichées sur le tableau principal (visibles uniquement dans ces tickets pour chaque histoire)? Vous pouvez donc essayer de créer des tâches pour chaque étape: codage, écriture de tests unitaires, QA / tests manuels, révision de code, fusionné avec master). Chaque tâche peut être marquée comme terminée une fois terminée, et quiconque consulte le ticket d'histoire peut facilement voir quelles tâches restent à faire avant que toute l'histoire puisse être fermée. Pendant ce temps, le tableau de mêlée réel de l'équipe montre toujours ce qu'il a fait auparavant.
Mais il s'agit simplement d'essayer de trouver une solution de contournement acceptable au fait que a) votre scrum master essaie de dicter la façon dont les développeurs organisent leur travail et b) accorde plus de priorité à rendre les informations visibles à la direction qu'à faire correctement le travail de production. Idéalement, la solution serait de convaincre votre scrum master que les informations de gestion imparfaites d'un travail efficace l'emportent sur les informations de gestion parfaites d'un travail médiocre. Le problème est que la direction ne le voit souvent pas de cette façon, de sorte que les évaluations de performances, les KPI et les bonus de votre Scrum Master peuvent inciter exactement ce que vous voyez. Sur le plan pratique, demander à votre Scrum Manager de se blesser financièrement et professionnellement pour vous faciliter la vie ne fonctionnera évidemment pas.
Dans ce cas, vous devez arrêter de voir le Scrum Master comme le problème et en faire une partie de la solution. Expliquez-leur la difficulté que le système actuel crée en termes de travail important qui est négligé parce que l'équipe ne peut pas en suivre correctement. Demandez-leur leur aide et leurs suggestions pour trouver une solution. Écoutez-les et comprenez les contraintes sous lesquelles ils travaillent et qui pourraient ne pas vous être apparentes (ou pourraient être complètement idiotes et imposées d'en haut, mais vous devez faire face à la réalité telle qu'elle est, pas comme vous le souhaiteriez) . Demandez ce que vous pouvez faire pour faciliter leur travail. Insistez sur le fait que vous souhaitez trouver une solution qui fonctionne aussi bien pour eux que pour vous. Étonnamment souvent, le simple fait de prendre le temps de comprendre leur point de vue et de faire preuve d'empathie avec eux fera disparaître le problème. Ou la discussion indiquera la voie vers une solution mutuellement améliorée. Je vous garantis que votre scrum master fonctionne sous au moins une contrainte importante (qu'elle soit imposée de l'extérieur ou due à des motivations internes) dont vous êtes inconscient.
C'est peut-être un cliché, mais "'Non' n'est pas ' t la fin de la discussion, c'est le début de la négociation ». Venir avec votre propre solution hors de la porte qui leur fait du mal n'est pas une négociation. Les aborder avec "C'est le problème qui existe et nous aimerions avoir votre aide pour trouver une bonne solution" est le début d'une négociation.