Lors de la cérémonie de Sprint Planning, l'équipe Scrum (Scrum Master comme animateur, le Product Owner, et l'équipe de développement) travaille ensemble pour déterminer le scope du Sprint Backlog, et s'engager sur un incrément produit de qualité à livrer en fin de Sprint, et répondant aux attentes du client et à l'objectif du Sprint.
Parmi les pratiques souvent remarquées chez pas mal des équipes, c'est que chaque développeur se focalise sur une User Story pour la réaliser et la finaliser, ce n'est pas toujours recommandé car cela peut parfois déclencher l'effet tunnel surtout pour une US nécessitant plus que 3 ou 4 jours pour la finaliser en totalité et la mettre en statut DONE.
Parmi les objectifs de l'équipe de développement lors de la séance de planification, c'est de bien identifier et savoir quel est le travail attendu de sa part pour mettre toute User Story en statut DONE, autrement dit décomposer chaque US en plusieurs tâches techniques, c'est tout simplement le PATTERN TAF, sachant que ce découpage dépend essentiellement de la ou les technologies utilisées sur le projet (Java, HTML, Cobol, .Net, ...Etc.).
Une remarque très importante, c'est une une tâche seule ne porte pas de valeur, mais c'est l'US en totalité qu'elle la porte.
le PATTERN TAF en question a pour objectif principal de pousser l'équipe à effectuer une petite analyse et concentration afin de bien identifier l'ensemble des tâches d'une User Story.
Exemple :
Prenant le cas par exemple d'une équipe qui travaille avec du JAVA, on peut décomposer une User Story comme suit :
Tâche de conception de la solution technique.
Tâche de création de l'écran ou l'IHM.
Tâche de préparation et construction des requêtes
Tâche de SQL pour la connexion avec la base de données.
Tâche des test unitaires ou d'acceptation.Tâche de relecture du code si appliquée par l'équipe.
Tâche de regroupement de tout le travail fait pour l'User Story en question....Etc.
Parfois c'est vraiment difficile de réaliser ce type de découpage surtout avec les Mainframe et les anciennes technologies en l'occurrence "Cobol", et "Pacbase".
Conclusion :
Parfois c'est pas possible de découper toutes les User Stories d'un Sprint à la fois, dans ce cas commencer par les US les plus prioritaires, et pour le reste c'est au fil de l'eau durant le Sprint.
La "D.o.D" va beaucoup aider l'équipe à identifier une liste des tâches exhaustive, car on ne peut passer une US au statut "DONE" que si toutes les conditions et critères de la "D.o.D" sont vérifiés.
Le découpage d'une User Story en tâches techniques n'engendre pas le faite de parler ou d'identifier qui va faire quoi, car ça c'est à traiter par l'équipe lors du premier Daily Meeting, et pas au niveau du Sprint Planning.
Dans des cas on peut oublier une ou plusieurs tâches lors de découpage, alors ce n'est pas grave, une fois on commence à travailler sur l'US en question, on va tout déduire.....
Merci