Prêt-prêt : la Définition du Prêt pour les User Stories qui vont dans la Planification de Sprint
Auteur : Richard Kronfält
Source : Ready-ready: the Definition of Ready for User Stories going into sprint planning
Date : 01/10/2008
Traducteur : Fabrice Aimetti
Date : 01/09/2019
Traduction :
Vous savez tous ce que signifie "Définition du Fini". Pour l'amour du ciel, je vais quand même la résumer. Il s'agit de l'état d'une portion de travail. L'état est également appelé "Fini-Fini". Le but du mécanisme du Fini-Fini dans Scrum est de s'assurer que les choses terminées dans les sprints sont réellement terminées dans un sens communément acceptable, contrôlé, intentionnel et convenu à l'avance. Par exemple, rien ne doit être considéré comme "terminé" tant qu'il n'a pas été testé, revu, intégré (commit) et fusionné (merge) - par exemple "Publiable" (Releasable). Sans la définition du fini, nous risquons d'accumuler une montagne de choses que nous poussons devant nous, ce qui finira par nous tuer (par exemple, le jour de la livraison - release-day) - ou du moins par provoquer un sacré combat. Pire encore, sans la définition du fini, non seulement nous accumulons une telle montagne de choses, mais nous n'avons aucun moyen de savoir quelle est la taille de cette montagne jusqu'à ce que nous commencions à nous salir les mains et à nous creuser la tête. Et ce qui est encore pire, c'est que beaucoup de choses à l'intérieur de cette montagne prendront beaucoup plus de temps à faire plus tard que si elles étaient faites immédiatement le jour 0, parce que plus on attend, plus il devient difficile de réparer, de comprendre, de trouver, de se souvenir, etc.
Donc, je pense que nous sommes tous d'accord sur le fait que nous avons besoin d'une définition de ce qui doit être fait pour le travail qui nous livrons à l'issue d'un sprint. Maintenant, je pense que nous avons besoin d'un mécanisme similaire pour le travail pris dans le sprint. Un mécanisme qui permet de s'assurer que les stories prises en compte sont vraiment prêtes à être prises en compte. Appelons cet état Fini-Fini (Ready-Ready).
Tout d'abord, qu'entend-on par "prendre" ? Eh bien, cela signifie "disponible et prêt à discuter lors de la réunion de planification du sprint". La définition du prêt doit donc décrire l'état des stories dans lesquelles elles doivent se trouver pour qu'elles puissent être éligibles à la discussion lors de la planification du sprint. Avant d'avoir atteint l'état Prêt-Prêt, les stories n'existent pas et ne seront pas prises en compte lors de la planification du sprint. En d'autres termes, la partie haute du backlog produit ne doit contenir que des stories prêtes-prêtes.
Pourquoi ? Pour gagner du temps bien sûr : éviter à l'équipe des discussions fastidieuses sur des sujets qui ne sont pas suffisamment réfléchis-réfléchis. Laisser l'équipe consacrer son temps et son énergie à des activités aussi "fiables" que possible.
La définition du Fini pourrait ainsi être :
- Il existe une user story qui désigne l'acteur, décrit la fonctionnalité ciblée et son but. La story devrait être formulée comme suit : En tant que... Je veux... Parce que... Les deux premiers sont souvent faciles à identifier, mais le but est souvent négligé, car il semble évident. Mais est-ce le cas ? L'idée en écrivant le but est de donner au lecteur une bonne idée du contexte de la fonctionnalité - quel problème il résout. Non seulement ce que c'est, mais aussi pourquoi. De cette façon, le lecteur peut se faire sa propre opinion sur la façon de la mettre en oeuvre. Il donne au lecteur une compréhension plus profonde de la story.
- La formulation de la user story est suffisamment générale pour que l'équipe ait la souplesse de la livrer par incréments. Ne décrivez pas tous les détails. Décrivez en gros ce que vous voulez, mais gardez le reste pour la discussion.
- La story est assez petite pour tenir dans un sprint. Les stories plus grandes que nécessaire doivent être découpées. Le découpage et la reformulation des stories doivent être réalisées avant la planification du sprint. Évidemment, une story ne peut être terminée en un sprint si elle est plus grande qu'un sprint. Il faut donc veiller à ce qu'elles soient suffisamment petites.
- Chaque story a sa propre priorité par rapport à toutes les autres stories du backlog produit. Cela permet de s'assurer que l'équipe peut d'abord travailler sur les choses les plus importantes et forcer le product owner à prendre des décisions intelligentes sur l'ordre des stories.
- La story a une description de la façon dont elle peut être testée (démontrée). La description doit donner au lecteur une bonne idée de ce qui détermine que la story est terminée ou non. Il doit s'agir par exemple du test d'acceptation qui est décrit ici. Il peut également être utilisé comme une description de la façon de démontrer la story.
- La story a été estimée (en points de story). Cela devrait être fait de préférence par l'ensemble de l'équipe, et au minimum par des personnes ayant la même compréhension du système et du domaine puisque l'équipe finira par travailler dessus.
Dans notre cas, nous devrions donc tenir des réunions avant la réunion de planification du sprint, où le product owner rencontre les équipes et s'assoit pour discuter du backlog produit. N'oubliez pas de timeboxer la réunion. L'objectif de la réunion est de juger si les stories sont prêtes à l'emploi. Il faudra que certaines stories soient découpées, reformulées, etc. et que les estimations soient faites à l'aide du poker planning. Un testeur ou un responsable de test doit également être présent afin que la formulation du "comment faire la démonstration" (how to demo) soit vraiment testable et significative.
