Bonjour à tous, je suis une nouvelle SM sur un projet en démarrage et j’ai un soucis pour les imputations du temps de l’équipe passé sur les réunion hors tickets et hors cérémonies agile, exemple (présentations, discussion du projet en général….) comment je peux tracer ça dans Jira?
Merci d’avance.
Bonjour ! 
Je vais répondre en restant le plus diplomatique et aimable possible: je n’ai pas la solution à votre problème mais je pense cependant que vous avez actuellement un problème bien plus important et difficile à gérer. La comptabilisation des temps passé n’est à priori pas la prérogative du Scrum Master, et ce genre de questions est immanquablement un signe d’une organisation qui n’a d’agile que le nom. Je serais bien sûr ravi d’aborder le sujet plus en profondeur si tu le souhaites.
3 « J'aime »
reBonjour, merci de votre réponse . le but est plutôt pour avoir une idée où on passe bcp de temps, si c’est dans les dev pas de débat, mais plutôt si on le passe plus dans les spécifications et les réunions ça veut dire qu’on a un souci dans le backlog et la compréhension des US. le but vraiment c’est pour l’amélioration du processus et non pas le flicage bien sûr. j’espère que ma méthode est bonne sinon je suis ouverte à toute remarque.
Merci bcp
Ok. Je vois l’idée, mais attention à ne pas chercher des solutions à des problèmes qui n’existent pas. Est-ce que votre productivité est en berne ? Est-ce que des personnes se plaignent que vous passez trop de temps en réunion ? Que trop de choses sont répétés ?
2 « J'aime »
pourquoi ce travail là n’est-il pas pointé également sur les tickets du coup ?
Selon le sujet, la maturité de l’équipe, l’expérience du PO, le temps peut être plus ou moins long sur chacune de ces étapes…
Pourquoi y aurait-il un souci dans le backlog si l’équipe a besoin de comprendre les US ? C’est avec l’équipe que le backlog pourra être construit en présentant au fur et à mesure les besoins et en découpant en fonction du besoin… le backlog s’affinera également petit à petit en fonction des retours de l’équipe.
Attention au pointage, le temps passé, c’est surtout une demande des hautes sphères… et tu peux te baser sur le temps du sprint et du nombre de tickets à done pour identifier où il y a des améliorations à apporter. La rétro sera pertinente pour cela également si c’est le ressenti de l’équipe qu’il y a trop de réunions… ce n’est pas forcément un mal…
2 « J'aime »
Hello,
« Si c’est dans les dev pas de débats »
Pourquoi il y a débat sur ce n’est pas dans les dev ?
Pour savoir où il y a potentiellement possibilité d’améliorer le processus global (pas forcément que du côté des dev) c’est peut être du côté du Lead Time que tu peux regarder 
Cela pourrait par exemple mettre en évidence qu’il y a un temps certain, nécessaire pour comprendre les problématiques et que - éventuellement 
- mieux collaborer avec les parties prenantes, permettrait de délivrer plus rapidement de la valeur. Ça permet de voir où sont les contraintes / ralentissements sur le flux de valeur (de bout en bout) et donc de prendre action(s) en conséquence.
2 « J'aime »
Je rejoins Franck, c’est l’équipe d’elle même qui dira quoi optimiser, réduire ou améliorer pour gagner en productivité, afin de faire mieux les choses, à gagner de la valeur.
1 « J'aime »
exactement ça les devs se plaignent qu’ils passent trop de temps dans les réunions pour éclaircir des sujets (PO débutant) qui ne sont pas estimées à l’avance donc on se trouve avec des estimations des US non réelles.
OK. Est-ce que c’est possible d’avoir un peu plus de précision sur ces remarques ? Est-ce que les devs se plaignent que le fonctionnel n’est pas assez clair et donc que la réunion perd en efficacité ? Est-ce que c’est le besoin qui n’est pas assez explicite et donc qui engendre trop de spéculations ?
Je partage l’avis de @Samuel_Abiassi
L’imputation (au sens suivi d’activité) ne doit pas se faire à ce niveau de granularité. Surtout si c’est pour créer une ligne fourre-tout style « réunion diverse ».
A mon sens, l’imputation doit se faire au niveau d’une ligne projet, éventuellement Epic.
En dessous, c’est du flicage et la négation de l’autonomie de l’équipe Agile / Scrum
Au pire, pour voir le temps passé en réunions, il suffit de regarder l’agenda partagé de l’équipe.
Dans l’absolu, que le raffinage se fasse pendant ou avant le sprint ne change pas le temps à y passer, même si la théologie veut que ce soit fait avant.
Maintenant, il faut savoir ce que l’on veut …
Soit on fait du bon vieux cycle en V avec des spécifications détaillées de la taille d’un annuaire qu’un (ou des) fonctionnels vont mettre 3 mois à sortir et on se revoit dans 6 mois
soit on fait travailler ensemble au quotidien des équipes métier et techniques pour que les uns et les autres s’adaptent au mieux et au plus vite, dans un contexte itératif et d’efficacité collective.
Enfin, si vous évoluez dans un contexte fonctionnel complexe ou très complexe, il faut se poser la question d’assister le PO : avec un business analyst, un proxy-PO …
Le truc, c’est de trouver une bonne réponse à une vraie bonne question.
Ceci dit, les Devs qui se plaignent de « passer trop de temps en réunion » ce n’est pas nouveau. Si on les écoute, leur kiff c’est de pisser du code (*) pendant 8h. Il faut leur faire comprendre que contribuer au fonctionnel, c’est aussi les tirer vers le haut. Les rapprocher des rôles de Tech Lead, d’architecte, voire de CTO …
Demain, après demain, ce sera les AI qui produiront du code. Ils seront peut-être contents nos Devs de savoir faire autre chose que produire du code.
(*) Exagération argotique destinée à souligner le propos, n’y voyez aucun mauvais esprit
1 « J'aime »
Haha. 
What a burn…
Bonjour,
Moi ce que je voie est de bien savoir à quel ticket est liée la réunion?
Si elle concerne aucune Us? Dans ce cas tu créés réunion global(foire tout) : où tu mets l’ensemble des réunions spec … et après le développeur ajoutera un commentaire sur le sujet de la réunion, quelle US concernée,… comme ça t’auras une visibilité sur le temps passée .
Sinon tu crée une US avec différentes tâches, et pour chaque tâche, on mettra le temps passé.
1- analyse spec US =>le dev mettra tout le temps passé sur les réunions de compréhensions de la Us
2- codage US,
3- tests unitaires…
1 « J'aime »
« éclaircir des sujets », est-ce que les activités réalisées durant ces réunions ressemblent à du travail ?
Dans ce cas, ce ne sont pas des réunions, mais des événements de travail.
Ici, il y a 2 cas possibles :
- Les sujets ciblés contribuent à l’objectif courant.
Alors, je doute que cela pose un problème au devs, car cela ne les défocus pas. - Les sujets ciblés ne contribuent pas à l’objectif courant.
Alors, je comprends les devs.
Comme l’a suggérée @SophieB. Utiliser la métrique du Lead Time pour expérimenter les 3 cas possibles :- On accepte ces réunions avec des sujets hors focus.
- On refuse ces réunions avec des sujets hors focus.
- Ou plus soft, en limitant la boite de temps accordé à ces réunions, maximum 25 minutes par jour.
Estimer, c’est prédire le futur.
Mon expérience
Je comprends cette volonté des devs de vouloir avoir des estimations réelles.
Cela me rappelle une période où mes coéquipiers et moi voulaient améliorer nos estimations.
Nous avions enchainé les échecs, les un après les autres.
Nous avions fini par abandonner, en passant la patate chaude au PO. Nous lui demandions : « Combien il était prêt à investir sur un sujet donné ? »
Frédéric Leguédois en parle
1 « J'aime »