Si je supprime les points ou le poids d’une tâche comment rendre visible l’état d’avancement pour le managment. Et aussi comment calculer la vélocité de l’équipe
Souvent, l’équipe ne sait pas vraiment estimer, mettre un poids, et lorsque c’est le cas, le nombre de ticket peut être un premier moyen de calculer la vélocité… c’est une base, le temps que les autres éléments se mettent en place et s’affinent au fur et à mesure des sprints et de la montée en expérience de l’équipe.
Le nombre de tickets traités peut être utilisé pour l’état d’avancement…
1 « J'aime »
J’ai toujours des frissons quand je vois ce mot là…
3 « J'aime »
Dans mon entreprise on consacre du temps aux estimations. Elle sont parfois « à la grosse louche », on réajuste en cours de sprint
Samuel, c’est très important de communiquer avec le managment. Finalement c’est eux qui prennent les décisions
Oh je sais…
C’est particulièrement sub-optimal et très Tayloriste, mais c’est la réalité de l’éco-système français actuel. 
Quand je vois ce genre de sujet je sais pas quoi répondre, j’ai parfois l’impression de ne pas faire le même métier 
Ouais, c’est à peu près ce que ça m’inspire aussi, et ça m’attriste beaucoup. Rien contre toi @PatrickVdv , j’en veux plutôt au système en lui même…
1 « J'aime »
Pourquoi tu veux supprimer les points d’une tache? Tu peux calculer la vélocité que si tu as estimé les tâches. Pour l’état d’avancement, n’importe qui de l’équipe de développement doit pouvoir l’expliquer à n’importe quel moment, car chaque développeur participe aux daily, cérémonie où on partage l’avancement.
1 « J'aime »
Supprimer les points des tâches… déjà, ça signifie que tu en avais… pourquoi vouloir les enlever ?
Si c’est pour les nouvelles tâches, pourquoi avoir les points sur les tâches pose problème aujourd’hui ?
Car le temps passé dessus ne correspond pas à l’estimation initiale ? Si c’est le cas, et alors ?
Ce qui compte, c’est que la prochaine fois, la prochaine tâche sera mieux estimée et c’est pour avoir un cap, une estimation à la louche, pas pour tomber exactement sur l’estimation qui avait été donnée lorsque le ticket est terminé… ce qui compte c’est le sprint goal, pas le temps passé par l’équipe sur les tâches…
Comment savoir combien de tâches l’équipe pourra prendre si les points sont supprimés ?
La vélocité sera associée à quoi ? Il manquera quelque chose…
1 « J'aime »
C’est pas factuellement faux ce que tu avances, mais le problème est beaucoup plus profond que ça. Tu es entrain d’expliquer comment on se sert d’un doigt alors que le bras est manquant.
Qu’est ce qui motive le fait de supprimer les points des tâches alors même que c’est l’usage dans ton entreprise ? Dans mon équipe pas de point, même pas de taille de t-shirt, en sprint planning on juge collectivement de ce que l’on capable de réaliser dans le sprint à venir. A la fin l’on voit si on est à 100% ou moins de l’objectif que l’on c’est fixé. On explique pourquoi l’on a pas tout réalisé les 100%, ex DOR pas ready, problème tech non prévisible, dépendance avec une autre équipe qui est en retard, plus complexe que prévu, …
@David quelle est votre répartition en % de sprint full-clear vs taches pas terminées à la fin ?
Chez nous 0% tout est couvert
Du coup, on est d’accord que vous « sous-performez » ?
Non pas du tout, c’est qu’on a bonne vision de la capacité des équipes
Je te propose de voir les choses différemment.
Votre équipe atteint 100% de taches accomplis, parfait. Si on exagère les choses, une équipe avec une seule tache basique pour un sprint de 2 semaines à de très très très grandes chances de toujours finir à 100% ses taches.
Je ne dis pas que c’est votre cas, loin de moi cette idée, mais tant que vous n’avez pas atteint votre limite (çàd: atteindre un point à partir duquel vous n’arrivez plus à faire 100%), comment savez vous que vous n’êtes pas en sous-performance par rapport aux capacités réels de l’équipe ? Vous n’avez factuellement aucune preuve formel. Par contre, d’après ce que tu me dis, j’ai une preuve formel que vous pouvez tenter de faire plus, aka « sous performer ». C’est pas un mal si ça vous permet d’atteindre ce que vous avez besoin d’atteindre. Mais ça veux dire que vous ne cherchez pas non plus à vous améliorer (aka Kaizen).
Finalement pour le plus important c’est que l’objectif du sprint soit atteint. Sans mettre la pression sur les équipes. Si on a atteint les objectifs avant la fin du sprint libre à moi d’ajouter des tâches pour le sprint en cours.
Mon but est plus la qualité que la quantité
en moyenne 80/90% on est exigeant avec nous même donc il y a toujours un peu de raffinage, mais des fois l’on tombe sur un os et là c’est plus compliqué comme la dernière fois sur une inté tech d’OpenID. Et la question qui suit est qu’est ce que l’on fait de ce qui n’est pas terminé ? Si c’est du raffinage c’est vite traité en début du sprint suivant, si plus complexe ou en dépendance fonctionnelle ou technique en fonction l’on reprend le sujet plus tard pas nécessairement dans le sprint suivant, tout dépend quand l’on sera de nouveau ready. On est pas les meilleurs en agile loin sans faut, il y a même une dose de waterfall dans notre façon de faire mais il y a un vrai esprit d’équipe et de communication très fluide malgré le fait que l’on ne soit pas tous dans le même pays / continent.