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 :
- débroussailler vaguement un sujet
- estimer une (ou des) stories, découper une épique
- réduire le risque
- 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.
- 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.
- Option 2 : on ne met pas de points sur les Spikes. C’est inutile, on a déjà une timebox pour ça.
- 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?
C’est la première fois que j’entends le terme “Anti-Story”, et je n’ai pu trouver de définition satisfaisante. Pouvez-vous m’indiquer ce que vous entendez par ce terme?
Merci d’avance !
@Julien
Une anti-story est une technique de modélisation, une façon simple d’exprimer un besoin sous la forme inverse… Par exemple, plutôt que de dire “En tant qu’admin, je veux restreindre l’accès au module X aux utilisateurs de type Y”, on va dire “En tant que Y, je veux accéder au module X” et bien étiqueter cela comme une anti-story. Nous avons utilisé cette technique à quelques reprises, ça permet d’exprimer surtout des requis reliés à la sécurité.
http://www.c2.com/cgi/wiki?UserAntiStory
Il y a des risques reliés à leur utilisation, il ne faut pas commencer à utiliser ça pour devenir paresseux et tout exprimer à l’envers non plus. Il faut retenir que les User Stories doivent être testables, et les Anti-Stories également!
Merci pour l’explication !
Pour moi, l’estimation en point d’effort, c’est une question de contexte. Je m’explique.
Pour quel contexte est-ce que j’ai besoin d’estimer en points d’effort? Celui de la planification. Et la planification ça concerne les stories et les épics qui sont la responsabilité du PO. Moi, ça me suffit. Je n’ai pas besoin d’estimer d’autres items avec les points d’efforts parce qu’il ne concernent pas le même contexte. Voici ma stratégie pour les autres types d’items:
Pourquoi ne pas estimer les bugs en points d’effort? Comme l’indique Isabelle, les bugs n’ont pas besoin d’être estimés. Rien n’est plus important que de résoudre un bug et si il nous a échappé une première fois, il est fort possible qu’on ne sache pas estimer son temps de résolution.
Pourquoi ne pas estimer les spikes en points d’effort? Parce que les spikes servent à réduire un risque ou la valeur d’un estimé. Comme l’indique Isabelle, le choix technologique, un risque ou une grande courbe d’apprentissage peut causer un estimé élevé de la part de l’équipe de développement. Si cet estimé d’un item est trop gros pour permettre sa planification, alors on pense à faire un spike qui a pour but de réduire cet estimé. Le spike est limité dans le temps pour éviter le piège de la sur-spécification et du faux confort de l’analyse détaillée.
Pourquoi ne pas estimer les tâches? Parce qu’elles appartiennent à l’équipe de développement et qu’elles ne sont pas planifiées par le PO. Parce que l’équipe est responsable de l’excellence technique du projet, une équipe ne devrait pas compromettre les tâches qu’elles jugent nécessaires pour produire plus de stories. Autrement, elle risque d’accumuler une dette technique et d’afficher une fausse vélocité à son PO. Avec pour conséquence que le PO ne pourra plus se servir de la vélocité pour planifier son projet et pour mesurer la progression du produit.
Comment planifier ces items?
- Pour les bugs, c’est facile: le plus tôt possible.
- Les spikes, eux, doivent être planifiés au moins un sprint avant l’item concerné: on ne peut pas réduire le risque d’un estimé et s’engager sur la réalisation de l’item concerné dans un même sprint. Sinon, on introduit un risque dans l’engagement du sprint. Il est préférable de garder l’estimé élévé qui représente sûrement mieux le risque d’introduire un item flou dans le prochain sprint.
- Pour les tâches, elles sont planifiées à la 2 phase de la séance de planification: dans la 1ère phase, l’équipe négocie avec le PO sur un engagement réaliste à entreprendre. Dans la 2e phase, l’équipe confirme son engagement après avoir découpé en tâches de toutes les stories négociées et après avoir identifié toutes les tâches nécessaires pour livrer cet engagement sans faire de compromis à la qualité du produit.
C’est ma stratégie, et je peux comprendre que certains lecteurs me trouveront arrêté avec mes règles et qu’ils voudraient me présenter leurs cas d’exception. Et je serais probablement d’accord avec eux. Cependant, je pense quand basant ma réflexion autour des contextes, je parviens à garder mon processus de gestion Agile simple et sans ambiguïté. Ensuite, les règles d’équipe autour de ces contextes peuvent évidemment être ajustés dans le cadre des rétrospectives.