Le backlog de sprint
Alias le plan d'itération
Quelques commentaires sur le contenu du backlog de sprint :
- les tâches, estimées en heures, ne devraient pas dépasser une vingtaine d’heures, soit environ 2 jours de travail pour une personne. Par exemple, une tâche qui s’appelle “Page JSP (interface)” et qui fait 40 heures est probablement le signe d’un travail à faire qui est mal identifié ou mal maîtrisé.
- il convient d’inclure toutes les tâches qui contribuent à la réalisation des éléments du backlog de produit (en général des histoires d’utilisateur). En particulier les tâches de test. Pour les tests d’acceptation, ce peut être le directeur de produit [1]qui spécifie les tests voire les passe et qui aura donc des tâches pour le faire, qui figurent explicitement dans le backlog.
- il n’est pas utile d’y faire figurer les tâches de gestion de projet ni les réunions Scrum.
- il est préférable d’éviter une tâche sans fin clairement exprimée comme par exemple “Etude du système de modèle de rendu pour les tableaux avec le framework IceFaces”.
- une tâche est spécifique de l’histoire d’utilisateur à laquelle elle est associée. Elle n’a pas à inclure du travail relatif à une autre histoire.
- le backlog de sprint est relatif à un seul sprint, les tâches qui y figurent aussi.
- il n’est pas nécessaire que toutes les tâches soient affectées à une personne dès le début du sprint, elles peuvent êtres prises plus tard en fonction de l’avancement.
Notes
[1] cela a aussi l’avantage de montrer qu’il fait partie de l’équipe