User stories et planification d'itération

Une user story est une courte description d’un besoin d’utilisateur, rédigée de son point de vue. La planification d’itération est la façon dont une équipe décide des stories sur lesquelles elle travaillera pendant la prochaine période. Beaucoup d’équipes appellent cette période un sprint et la réunion sprint planning ; East Agile Tracker parle d’itérations et de planification d’itération.

Qu’est-ce qu’une user story

Le modèle courant est :

En tant que [type d’utilisateur], je veux [une capacité], afin de [un bénéfice].

Par exemple : En tant que chef de projet, je veux voir quelles stories sont bloquées, afin de les débloquer avant la fin de l’itération.

Le modèle indique qui en bénéficie, ce dont cette personne a besoin et pourquoi. Le « pourquoi » permet à l’équipe de trouver une façon plus simple d’apporter le même bénéfice. Une story tient lieu de conversation, pas de spécification complète : les détails se précisent entre ceux qui demandent et ceux qui construisent.

INVEST : la story est-elle prête ?

INVEST est une liste de contrôle pour une story bien formée :

• Independent (indépendante) — peut être construite et livrée seule.
• Negotiable (négociable) — les détails restent ouverts à la discussion.
• Valuable (utile) — apporte quelque chose qui compte pour un utilisateur ou un client.
• Estimable (estimable) — l’équipe la comprend assez bien pour la dimensionner.
• Small (petite) — tient confortablement dans une itération.
• Testable (testable) — il existe un moyen clair de savoir qu’elle est terminée.

Critères d’acceptation

Les critères d’acceptation énoncent ce qui doit être vrai pour que la story soit considérée comme terminée. Les rédiger sous la forme Given / When / Then fait de chacun un test d’acceptation :

Given une story avec un bloqueur non résolu, when j’ouvre la colonne Blocked, then la story y figure.

Les critères sont convenus avant le début du travail, pour que l’équipe et la personne qui accepte la story partagent la même définition de « terminé ».

Planification d’itération

La planification d’itération répond à une seule question : sur quoi allons-nous travailler pendant cette itération ? Elle demande trois éléments :

1. Un backlog ordonné — des stories classées par priorité, celles du haut étant prêtes (conformes à INVEST, avec des critères d’acceptation).
2. Des estimations — chaque story candidate dimensionnée en story points.
3. La vélocité — le nombre de points que l’équipe termine par itération. Voir Qu’est-ce que la vélocité ?.

L’équipe prend des stories en haut du backlog jusqu’à ce que le total atteigne sa vélocité. En prendre davantage suppose que l’équipe travaille soudain plus vite ; en prendre moins laisse de la capacité inutilisée.

Comment East Agile Tracker procède

• Les stories existent en quatre types : features, bugs, chores et releases. Seules les features prennent des points par défaut. Voir Stories.
• Les critères d’acceptation vont dans la description. Il n’y a pas de champ distinct ; les critères ont leur place dans la description avant que la story ne soit démarrée. Quand une story est livrée, le product owner l’accepte ou la rejette au regard de ces critères. Voir la machine à états et la boucle d’acceptation.
• Le backlog est une liste unique strictement ordonnée, qui projette les itérations à venir à partir de la vélocité, trois ou quatre à l’avance, en signalant tout groupe qui dépasse la vélocité. Voir Itérations.
• La planification d’itération est en grande partie automatique. Avec auto-plan iterations activé (par défaut), l’itération courante se remplit jusqu’à votre vélocité ; y tirer une nouvelle story renvoie la moins prioritaire en haut du Backlog. Les équipes qui s’engagent sur un périmètre fixe, à la Scrum, peuvent désactiver la planification automatique et planifier autant qu’elles le souhaitent, avec un compteur qui passe au rouge au-delà de la vélocité. Voir Planifier une itération.
• Créer une story ouvre un composeur pour le titre, la description, le type, l’estimation et les propriétaires. Voir Créer une story.

Pour aller plus loin

• Que sont les story points ? — dimensionner les stories.
• Qu’est-ce que la vélocité ? — le côté capacité de la planification.
• eXtreme Programming — l’origine des user stories et du Planning Game.