Sur quoi on met des points?

C’est un débat qui semble être éternel dans la communauté Scrum, car comme beaucoup de choses, il n’y a pas d’indications claires à ce sujet dans les bouquins. Et c’est tant mieux, c’est ce qui fait de Scrum une méthode flexible et adaptable à chaque réalité. Dans chaque projet, il est possible de déterminer ce sur quoi on met des points, et donc ce sur quoi on calcule la vélocité.

Je vous annonce d’ores et déjà que je n’ai pas de réponse à cette question, j’ai surtout des questions et je viens chercher ici votre avis sur la chose.

Dans mon projet actuel, qui est distribué, nous utilisons Jira et GreenHopper et nous avons plusieurs types d’items au backlog.

• Nous avons des Epic, des User Story et des Anti-Story, qui nous permettent d’exprimer les besoins des clients, les fonctionnalités qui apportent de la valeur d’affaires.
• Nous avons des Task et des Bug qui nous permettent de répertorier les tâches qui n’apportent pas une valeur directe au client mais qui sont nécessaires au projet : le développement d’outils pour les développeurs, l’installation de frameworks et d’outils externes, l’accumulation de la dette technique et les défauts (qui viennent de fonctionnalités non terminées ou de régression causée par des nouvelles fonctionnalités).
• Nous avons des Spike: du boulot de recherche timeboxé qui vise à atteindre un ou plusieurs de ces buts :
  1. débroussailler vaguement un sujet
  2. estimer une (ou des) stories, découper une épique
  3. réduire le risque
  4. faire un choix de technologie

Les User Story Points servent à mesurer la complexité relative des tâches attribuées aux développeurs. C’est un excellent moyen pour eux d’informer le Propriétaire de produit (Product Owner ) de la complexité des items sur lesquels ils vont travailler afin de les aider à prioriser leurs demandes. Ça permet ensuite de connaître la capacité d’une équipe (sa vélocité en points par sprint) et de planifier la quantité de boulot qu’on peut abattre à chaque sprint.

Les User Story Points ne sont PAS une mesure de la valeur d’affaires. Et ce n’est PAS un outil utilisable pour contractualiser une relation d’affaires ni un outil de reporting. Cela dit, passons au débat.

En ce moment, nous n’estimons que les Epics, User Story et Anti-Story en points. Le reste est estimé en heures. Mais on se pose la question : (1)pourquoi ne pas mettre des points sur tout? Après tout, le besoin est le même, quelque soit le type de tâche, on veut en estimer la complexité relative et permettre au Propriétaire de produit de faire un choix éclairé. Par contre, nous pensons que ce n’est pas pertinent d’estimer en points des Bugs. Nous sommes d’accord que ce n’est pas très utile dans ce cas, car les Bugs sont toujours notre première priorité, et que peu importe le temps qu’on y passera, il faudra bien se rendre au bout…

Ensuite, quand vient le temps de se poser la question du calcul de la vélocité, on se dit que ce serait dommage de priver le Propriétaire de produit de sa “vélocité fonctionnelle”. Comme le projet est en cours depuis 1 an et demi déjà, nous ne voulons surtout pas embrouiller ses statistiques. Alors nous avons pensé au concept de “vélocité technique”, qui nous permet de bien séparer ce qui apporte de la valeur d’affaires de qui n’en apporte pas directement. (Comme dit David, un de mes collègues sur le projet, la dette technique n’est pas une valeur ajoutée, mais plutôt du service après vente sur un produit à moitié défectueux). (2) Qu’est-ce que vous en dites?

Nous ne savons trop que faire à propos des Spikes et ici, nous avons (3) besoin d’avis externes et d’arguments.

1. Option 1 : on met des points et ça compte comme vélocité fonctionnelle. Après tout, ça permet de réduire le risque, et c’est la première étape d’une épique. Et ça a de la valeur pour le client.
2. Option 2 : on ne met pas de points sur les Spikes. C’est inutile, on a déjà une timebox pour ça.
3. Option 3 : on met des points et ça compte comme vélocité anticipation. Un nouveau type de vélocité… compromis…

Dernière question : (4) Quel est selon vous l’impact de ces choix sur la motivation des développeurs de l’équipe? celle du PO?