Afin de mener un sprint à sa réussite, il est important de savoir constituer correctement des user stories ainsi que des tâches. Nous vous proposons aujourd’hui un retour d’expérience sur l’organisation de nos user stories et les éléments clés que nous avons détectés pendant nos sprints
Avoir une bonne valeur étalon
Il faut tout d’abord concevoir que d’une équipe à l’autre, la valeur étalon pour une user story est différente, et que chaque équipe a défini de manière empirique cette dernière. Ainsi, il faut garder à l’esprit que les story points sont des unités arbitraires dépendant des équipes, et non une mesure universelle.
En premier lieu, il faut que l’équipe réussisse à définir ce qui est pour elle, un story point. L’exemple qui a nous a été donné fut « Pour vous, un simple changement de libellé équivaut à combien de story points ? »
L’équipe a alors débattu et s’est accordé sur la valeur de 1. Depuis, cette valeur nous permet de réfléchir à l’importance des user story qui nous sont proposés, et de chiffrer l’effort de manière relative.
Un story point est alors la représentation étalon d’un effort.
Découper les user stories : diviser pour mieux régner
Dans la méthodologie agile, une user story ne peut être montrée en fin de sprint uniquement si elle est terminée (codée, révisée, testée). Une user story trop longue a donc plusieurs inconvénients : impossibilité de la montrer en démo même si des parties mineures seulement sont incomplètes, goulot d’étranglement sur le test qui ne pourra tester que cette user story et qui devra attendre des devs suffisants pour pouvoir la tester etc…
C’est exactement ce qui nous est arrivé, nous avions mal découpé une user story, nous retrouvant donc avec 2 user stories pendant notre sprint. La première fut terminée assez rapidement, mais la deuxième, qui était mal découpée, n’a pas pu être terminée en temps et en heure, imputant largement notre démo.
On peut donc conclure que 3 user stories de 10 points, sont moins contraignantes pour un sprint, qu’une seule user story de 30 points, malgré un chiffrage similaire.
Découper les tâches : pas plus gros qu’un grain de sable
Lorsque nous avions commencé la méthodologie agile, une erreur que nous avions commise était de négliger le découpage des tâches. Cela a résulté par des blocages au niveau du dev, certaines tâches restantes en cours, pendant plusieurs jours. Il est de bon ton de rappeler qu’une tâche est un élément qui n’est pas sensé prendre plus d’une journée.
Nous avons alors décidé de partir dans l’extrême opposé en faisant un découpage à granularité très fine, cependant ce découpage nous a apporté d’autres problématiques. Ce sur-découpage a créé un goulot d’étranglement sur les revues de code puisque les tâches étaient très nombreuses, mais surtout très courtes. De part leur taille, il est notamment arrivé régulièrement que plusieurs tâches soient faites d’un seul coup, rendant ainsi le découpage caduque.
Nous avons alors conclus que le découpage des tâches ne pouvait se faire qu’à force d’essai et que ce dernier est très dépendant des projets sur lesquels l’équipe travaille. Il est cependant important de ne pas partir dans les extrêmes.
Communiquer
Les user stories ainsi que les tâches ne peuvent pas se définir correctement si l’équipe n’arrive pas à communiquer sur les besoins et les objectifs de ces dernières. La communication est le point d’orgue de la création des user stories, que ce soit par la communication interne de l’équipe mais également la communication avec les autres services concernés par le projet
