Sprint Planning : erreurs courantes à éviter
Faire de bons sprint plannings n'est pas toujours facile.
Voici quelques erreurs à éviter qui pourraient sauver vos sprints !
Être trop ambitieux
Comme on l'a vu précédemment, on a toujours tendance à surestimer sa capacité de travail. C'est humain !
Au-delà de ne pas réussir le sprint, cela peut avoir d'autres répercussions...
Fixer des objectifs trop ambitieux peut amener à un taux d'échec élevé.
Cela peut avoir un impact important sur la bonne conduite du projet.
Au-delà du projet en lui-même, ce sont les développeurs qui sont en risque.
Se sentir en échec perpétuel a un impact très négatif sur la motivation des troupes.
Avoir un Product Backlog désordonné
Avant le Sprint planning, le Product Owner doit ordonner son Product Backlog, pour pouvoir plus facilement faire le point sur les priorités avec l'équipe.
Le Sprint planning doit être axé sur la valeur apportée au client.
Avoir un Product Backlog en ordre y aidera grandement.
Aller trop vite
Un Sprint Planning est un évènement important pour la bonne conduite du sprint à venir.
Il ne peut pas se faire en une heure.
L'idée du Sprint Planning n'est pas juste de piocher des éléments dans le Product Backlog.
L'équipe doit surtout travailler sur un plan d'action. Et cela peut prendre du temps.
L'équipe devra prioriser les User Stories, puis entrer dans les détails pour les premières User Stories.
Elle doit réfléchir concrètement à la manière dont elle va répondre techniquement à la demande.
Ce plan doit être scrupuleusement préparé, et particulièrement sur les User Stories qui seront traitées en premier.
Ne pas faire un plan d'action concret
Pour la bonne conduite du sprint, l'équipe devra définir, pour chaque item, comment il faudra s'y prendre.
Cela nécessite un découpage des items en taches, et même en sous-taches quand c'est possible.
Ne pas avoir d'objectif clair
L'objectif du Sprint doit être une phrase claire et concise qui définit la raison d'être du sprint.
On ne cherche pas juste à construire une liste de fonctionnalités.
Cet objectif est là pour guider l'équipe, afin qu'elle ne le perde pas de vue.
Elle pourra reprendre par exemple le nom de la fonctionnalité principale du sprint.
Implicitement, cela lance le message que toute fonctionnalité du sprint qui ne vise pas directement l'objectif du sprint devra être considéré comme moins prioritaire.
Avoir plusieurs objectifs de sprint
Un sprint doit avoir un objectif précis, mais surtout unique.
L'objectif doit être clair, et en avoir plusieurs, peut diluer les priorités.
Faire le Sprint planning trop tôt
Il faut toujours attendre la Sprint review du sprint précédent avant d'entamer le Sprint planning.
Les évènements SCRUM ont un ordre précis pour une bonne raison.
On apprend toujours des évènements précédents pour conduire les sprints au mieux.
Or, la Sprint Review permet de faire le point avec les parties prenantes pour la suite, et donc sur le sprint suivant.
Les conclusions de la Sprint Review permettent de prioriser correctement les éléments traités dans le sprint suivant.
Ne pas faire participer toute l'équipe
On voit parfois des Sprint plannings dans lesquels un seul développeur est présent.
Toute l'équipe doit être présente lors du Sprint Planning.
Chacun pourra avoir des idées ou des avis pertinents sur les fonctionnalités à réaliser.
Avoir un Product Owner pas suffisamment engagé
Le Sprint Planning peut parfois être une réunion assez technique.
Les développeurs doivent faire un effort pour que le Product Owner puisse lui aussi comprendre comment les développeurs arriveront à l'objectif du sprint.
Les développeurs doivent prouver au Product Owner que l'objectif du sprint est atteignable en lui montrant un plan d'action clair et compréhensible.