Discussion :

[Ito]

Bonjour,
Je suis scrummaster et nous utilisons la suite de Fibonacci pour estimer les tickets (tâches, user stories) qui iront dans le sprint.
J'ai l'impression qu'il y a une surestimation des tickets pour gonfler la vélocité individuelle, par exemple un ticket à 8 points alors qu'il vaudrait peut-être 5 ou même 3 points.
Il y a 16 développeurs et pour éviter un planning poker qui s'éternise, les estimations sont faites individuellement et validées lors du sprint planning.
Merci d'avance pour toute suggestion.

[Marco46]

Bonjour,
Je suis scrummaster et nous utilisons la suite de Fibonacci pour estimer les tickets (tâches, user stories) qui iront dans le sprint.
J'ai l'impression qu'il y a une surestimation des tickets pour gonfler la vélocité individuelle, par exemple un ticket à 8 points alors qu'il vaudrait peut-être 5 ou même 3 points.
Il y a 16 développeurs et pour éviter un planning poker qui s'éternise, les estimations sont faites individuellement et validées lors du sprint planning.
Merci d'avance pour toute suggestion.

Tu donnes les solutions en posant la question.

16 sur une équipe c'est beaucoup trop, vos standups doivent durer des plombes ! Vous avez assez de monde pour faire 2 équipes voire même plutôt 3.

Le principe des estimations collégiales c'est justement de confronter les points de vues pour éviter ce genre d'écueil. La surestimation d'une tâche c'est généralement le fait de développeurs un peu expérimentés qui ont appris à être prudent car la sous-estimation est généralement un défaut de junior qui ne verra pas les pièges d'une story ou aura plus de mal à sous découper en tâches une story de tête et va donc louper des étapes.

Cette remarque : "une surestimation des tickets pour gonfler la vélocité individuelle" me fait me poser une question : Quel intérêt auraient les développeurs à gonfler leur vélocité ?

[4sStylZ]

Bonjour,

J’espère que tu a trouvé la solution à tes problèmes.

Néanmoins voilà mes réponses pour ceux qui se posent aussi les questions.

Je suis scrummaster et nous utilisons la suite de Fibonacci pour estimer les tickets (tâches, user stories) qui iront dans le sprint.

C’est très bien pour les user story et taches donc continue avec ça. En géneral c’est moins adapté pour les features et la vision macro. Pour ça j’utilise les tailles de T-Shirt. Un peu comme ça mais avec une échelle différente : http://www.bouzin-agile.fr/?post/201...z-vos-t-shirts

J'ai l'impression qu'il y a une surestimation des tickets pour gonfler la vélocité individuelle, par exemple un ticket à 8 points alors qu'il vaudrait peut-être 5 ou même 3 points.

Tu parle de quoi quand tu dit « vélocité individuelle ». La vélocité est une mesure pour l’équipe. Jamais elle ne doit être individuelle.
De plus, ce n’est pas une mesure de productivité. Voici un article qui en parle : http://www.aubryconseil.com/post/200...e-productivite

Si l’équipe pense que quelqu’un a un problème de vélocité individuel, pour une personne, elle peut simplement soulever le problème quotidiennement au daily. Ton rôle de SM c’est idéalement de les pousser à être autonome. Être autonome c’est aussi leur montrer qu’ils doivent éssayer de régler les problèmes d’eux même, que c’est ce qu’on attend d’eux, et biensur comment régler les dits problèmes (quand c’est possible…) :*
Ex :*« Je vois que cette petite tache qui vaut X points n’est pas terminée. Quels sont les blocages ?*Comment aider et comment se mettre en ordre de bataille pour la finir ? L’idée étant de donner du feedback souvent et parler souvent des petits risques plutôt que de laisser les choses devenir des géneralités, donner un ressenti sur une liste de taches énorme et que cela se transforme en de grosses reproches qui vont démotiver plutôt que challenger.

Quand par contre cela ne suffit pas avec l’équipe, ou qu’elle est peu réceptive, alors tu peut créer des points individuels, mais dans ce cas je te suggère de le faire avec tous les membres d’équipe. Un point régulier (mensuel ?) est très interessant, même pour des membres d’équipes qui sont très productifs. Tu apprendra d’eux, ils te révéleront des dysfonctionnements, et tu pourra aussi les missionner de coacher les membres qui ont plus de difficultés.

En tout cas c’est normal que certains devs aient une vélocité différentes. Est-ce qu’ils prennent les mêmes taches  ou des taches de taille plus importantes ?*Est-ce qu’ils ont le même profil, la même xp, la même affinité avec les technos ? Si les gens travaillaient à la même vitesses sur toutes les taches alors utiliser le temps comme mesure serait tout à fait rationnel et on ne serait pas intéressé par les points.
http://www.aubryconseil.com/post/200...e-productivite

Il y a 16 développeurs et pour éviter un planning poker qui s'éternise, les estimations sont faites individuellement et validées lors du sprint planning.

Oulà. Ça c’est un problème d’organisation important. En fait, une équipe Scrum est prévue pour 6 membres (dont le SM) avec +3 ou -3 membre maximum. En effet, trois membres est souvent le minimum pour faire une équipe valable :*À trois on peut souvent se départager, à trois on peut idéalement ne pas trop se spécialiser, et gérer le planning de congés etc… À 9 :*Les dailys sont interminables. Pour les raccourcir on use de subterfuges qui enlèvent toute la richesse que la mêlée est censée apporter ! Pareil pour les plannings poker. Impossible d’emmener toute l’équipe, et d’avoir une discussion constructive. Tout le monde se taît pour ne pas ralentir ou tout le monde parle et … ralenti !

Je suis sur que deux équipes de 8 ou même trois équipes de 5~6 pourrait vraiment mieux fonctionner.

Voilà mes suggestions :
- Renseigne toi sur les features-team.
- Renseigne toi sur le framework agile LeSS (Large scale scrum) https://less.works

Bon courage à toi.