Dans cette station de ski, les pistes rouges sont trop faciles !

Qu’est ce qu’une User Story

Dans nos projets agiles, nous découpons nos besoins en petites fonctionnalités. Cette liste de fonctionnalités est appelée le Product Backlog (ou “carnet de produit” comme disent les Quebecois).

Chaque fonctionnalité est appelée “User Story”. En francais, on entend parfois “Histoire Utilisateur”, mais comme tout le monde dit User Story, je vais rester là dessus. Une User Story est courte, elle peut être écrite sur une carte en utilisant le formalisme suivant. En tant que… J’ai besoin de… dans le but de…

Par exemple : En tant que client, j’ai besoin d’un reçu dans le but de tenir mes comptes.

Et la complexité alors ?

Dans le but de permettre la planification de notre projet, nous avons besoin d’estimer la taille du travail à faire. En agile, on introduit une distinction importante. Nous faisons la différence entre la complexité et l’effort. C’est souvent là que la compréhension coince un peu. Quelle est cette nuance et pourquoi en a-t-on besoin ?

Pourquoi est-ce si important que ces points soient “abstraits”, personne n’est à l’aise avec les abstractions… Pourtant, je peux vous donner plusieurs exemples dans la vie de tous les jours où nous utilisons une échelle de mesure abstraite. C’est le cas de la pointure de vos chaussures qui s’exprime en point. Mais rentrons dans le détail avec une autre analogie :

Quand vous allez aux sports d’hiver, la difficulté des pistes est exprimée avec des couleurs. Vous avez les pistes vertes qui sont faciles, les pistes bleues, un peu plus difficiles, puis les pistes rouges encore au dessus et enfin les pistes noires qui sont les plus difficiles.

Comme je viens de le dire, la couleur d’une piste est liée à la difficulté, inclinaison des pentes, longueur, présence de champs de bosses…

Au début de votre semaine de vacance au ski, descendre une piste rouge vous demandera sans doute beaucoup d’effort. Vous aurez mal aux jambes et aux bras à la fin de la journée, alors que vous n’aurez descendu que très peu de pistes. Par contre, en fin de séjour, votre performance aura beaucoup augmenté et vous descendrez 10 fois la piste rouge en question, en ayant l’impression de “voler” (en tout cas, ça se passait comme ça quand j’étais jeune).

Bien que vous soyez plus performant, la piste n’a pas changé de couleur. En d’autres termes, l’effort necessaire pour descendre une piste rouge a diminué.

C’est exactement la même chose avec la complexité des users story. Nous estimons la complexité des User Story en points. Si deux User Stories sont de difficulté identique, on leur donne le même nombre de point. Pour placer votre échelle, vous partez d’une référence, une ou deux User Stories “standards” auxquelles vous donnerez arbitrairement un nombre de points. Par exemple, US 1: 3 pts et US 2: 8 pts.

Au cours du déroulement de votre projet, les User Story que vous aviez estimées à 5 points vont vous paraitre de plus en plus faciles. Il est très important de continuer à les estimer toujours avec le même nombre de points (la piste rouge est toujours rouge, même à la fin des vacances).

L’estimation de complexité est une estimation relative, car c’est ce qu’il y a de plus facile à faire. Notre cerveau est une machine à comparer les choses deux à deux.

Comment je passe à la planification ?

Pour pouvoir procéder à la planification, sur la base de vos estimations de points de complexité, il vous manque un moyen de rapprocher cette complexité de l’effort (c’est à dire le nombre de jour.homme qu’il faut pour faire un point).

On appelle ce rapport la “productivité”.

Productivité = nombre de point de complexité / nombre de jour.homme

Attention, dans un projet agile, on calcule une productivité moyenne d’une équipe. Si vous utilisez la méthode Scrum, vous pouvez par exemple diviser la vélocité, (c’est à dire, le nombre de points de complexité réalisé dans une itération) par le nombre de jour.homme de l’itération

Il est important de ne pas mesurer de productivité individuelle pour ne pas voir votre planning pollué par un exercice d’optimisation de l’utilisation des “ressources humaines”. Cette optimisation se fera par le jeu de l’auto-organisation de l’équipe. Inutile pour un manager d’aller mettre son nez là-dedans. C’est une perte de temps et c’est extrêmement démotivant pour l’équipe.

A noter que cette productivité est un facteur d’ajustement de votre planning. Au départ du projet, vous faites une estimation de votre productivité à venir et vous planifiez votre projet sur cette base. Au fur et à mesure du déroulement du projet vous allez avoir un ajustement de cette première estimation. Vous ajusterez votre planification en fonction de la productivité constatée. Il y a de fortes chances que cette productivité augmente avec le temps. Le planning devra à nouveau être mis à jour.

Dans un projet avec des itérations, il est assez simple de mettre à jour ce planning à chaque fin d’itération.