Continuons d’évoluer, révisons notre utilisation des points de récits utilisateurs !

Relisez le guide Scrum. Il n’y a pas de notion de vélocité ou de points de récits utilisateurs. Ce fait, qui m’a été rappelé récemment par un collègue, m’a permis de réaliser les multiples biais injectés dans les fondamentaux Scrum et Agile pour répondre à des besoins de métriques.

Amusez-vous à lire cet article.

L’un des biais les plus flagrants est, pour ce billet, la notion de point pour un récit.

“Working software is the primary measure of progress.” – Manifeste Agile

Quand le manifeste Agile mentionne que la seule mesure de progrès est un logiciel fonctionnel, pourquoi parle-t-on de points ?

Le mouvement #NoEstimate s’engage déjà dans cette voie en voulant ramener la notion à 1 point = 1 récit. Cependant, nous gardons ici le biais d’avoir des métriques, qui ne donnent de l’information qu’aux membres de l’équipe de développement, et non au client, à qui on doit livrer un logiciel fonctionnel.

Dans mes récentes discussions et lors de rencontres de planification de sprint, j’ai de plus en plus de mal à entendre parler de la notion de points d’efforts. En effet, dans de nombreuses organisations – notamment celles en transformation et bien souvent en mode “hybride” – les points des récits ne reflètent pas des points de valeurs d’affaires. La corrélation entre la valeur pour le client – bien souvent le retour sur investissement visé dans une période de temps définie – et l’ampleur de l’effort auquel fait face l’équipe de développement (complexité, nouveauté, temps, etc.) n’existe que peu, ou pas du tout. Ce sont des anciens chargé de projets, qui se transforment en SM, et des anciens directeurs qui s’essayent à leurs nouveaux rôles qui ont souhaité garder ce lien pour continuer à comprendre ce qu’il se passe, plutôt qu’à réapprendre à suivre l’évolution d’un projet, que dis-je, d’un produit.

Les équipes aujourd’hui focalisent donc sur une notion de points d’efforts, dont eux seuls en connaissent les règles et pour laquelle, bien souvent, elles n’ont que peu d’intérêt. De plus, dites à votre client lors de la revue de sprint que vous avez livré 20 points sur 25, et mis à part le fait de souligner que vous n’avez pas réussi à livrer l’ensemble de votre engagement de sprint, le client n’a aucune notion de ce que cela représente pour lui. Il revient donc, de lui-même, à l’aspect « j’ai reçu de mon équipe de développement 8 récits sur les 10 prévus » : #NoEstimate, CQFD*.

Lors des phases en amont de la réalisation et des planifications des sprints, l’évaluation des points en valeur d’affaires a bien souvent été escamotée. Cela a dénaturé la métrique des points, primordiale pour s’assurer de l’alignement de l’équipe avec les besoins du client. Ainsi, lors des phases d’idéation et de préparation, qui sont en amont de la réalisation, il est important de s’assurer de la compréhension des équipes affaires de la notion de points de valeur. On utilise alors la valeur d’affaires directement – telle que le client la conçoit. La priorisation se fait assez facilement et le découpage en temps s’effectue à la planification de sprint.

Cela revient aussi à dire que les organisations, autant que les accompagnateurs Agile ou les Scrum Masters, doivent s’attarder à la compréhension de ce qu’est la valeur d’un récit, donc affaires plutôt que TI. Cela aidera également l’organisation à obtenir des métriques adéquates permettant réellement de jauger l’utilisation des investissements en fonction des besoins, plutôt que d’essayer de corréler jours/personnes, points d’efforts et planifications dans MS Project.

Dans mes anciennes équipes, j’ai même progressivement abandonné toute mesure en point, et arrêté de parler de vélocité, comme ce blogueur (Michael James). Ce que cela m’a permis d’atteindre avec l’équipe est une concentration (une des valeurs de Scrum) sur la réalisation d’incrément fonctionnels et livrables, plutôt que sur des planifications et du découpage à n’en plus finir. C’est à ce moment que les membres de l’équipe ont compris l’apport de l’Agilité et de Lean, que ce soit par Scrum, Kanban ou une combinaison des deux.

*CQFD : Ce Qu’il Fallait Démontrer.

Laissez un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

w

Connexion à %s