Comment faire les plannings de sprint

Publié le par

Le planning de sprint est une réunion critique, probablement l’événement le plus important dans Scrum. Une réunion de planning de sprint mal exécutée peut perturber un sprint complet.

Le but est de donner à l’équipe suffisamment d’informations pour qu’elle soit capable de travailler aisément, sans dérangement durant quelques semaines. à la fin de cette réunion on doit avoir :

  1. Un but pour le sprint
  2. Une liste des membres d’équipe (et de leur niveau d’engagement)
  3. Un backlog de sprint (une listes des exigences incluses dans le sprint)
  4. Une date bien définie pour la démonstration
  5. Une heure et un lieu bien définis pour la mêlée quotidienne

De préférable que le directeur de produit (Product Owner) doit y assister, la raison derrière est que chaque exigence contient trois variables qui dépendent fortement les unes des autres

  • Portée
  • Estimation
  • Importance

La portée et l’importance sont déterminées par le directeur de produit. L’estimation est déterminée par l’équipe. Durant une réunion de planning de sprint, ces trois variables sont affinées grâce au dialogue face-à-face entre l’équipe et le product owner.

Normalement le directeur de produit commence la réunion en résumant son but pour le sprint et les exigences les plus importantes. Ensuite l’équipe parcourt chaque exigence et estime le temps qu’il faudra pour la réaliser, en commençant par la plus importante. Pendant qu’ils font ça, ils auront des questions importantes sur la portée  » est-ce que cette exigence de suppression d’utilisateur comprend le fait de parcourir chaque transaction en attente pour cet utilisateur, et de l’annuler ? ». Dans certains cas les réponses surprendront l’équipe et la conduiront à changer son estimation

Dans d’autres cas d’estimation du temps pour une exigence ne sera pas ce que le directeur de produit attendait. Cela peut le conduire à changer l’importance de l’exigence. Ou à changer la portée de l’exigence, ce qui conduira l’équipe à ré-estimer, etc.

Ce type de collaboration directe est fondamental dans Scrum et en fait dans tout développement logiciel agile.

Je cite quelques points à clarifier durant cette réunion :

  • La qualité de livrable n’est pas négociable :  il se peut arriver que le PO demande de réduire tel charge pour tel fonctionnalité sans payer le prix de réduire la portée. Les mots  » Livrez-nous quelque chose de rapide » devraient déclencher une alarme dans votre tête.
  • Le choix de la durée du sprint
  • La définition du but du sprint
  • Le choix des exigences à inclure dans le sprint
    • backlog
    • Chaque rectangle représente une exigence, triée par importance. L’exigence la plus importante est au sommet de la liste. La taille de chaque rectangle représente la taille de cette exigence (i.e l’estimation de temps en points d’exigence). La hauteur de la parenthèse bleue représente la vélocité estimée de l’équipe. I.E combien de points d’exigences l’équipe croit qu’elle pourra terminer durant le prochain sprint
    • L’équipe décide combien d’exigences vont être prises dans le sprint. Ce n’est le directeur de produit ou qui que ce soit d’autre. La question qui se pose comment les équipes choisissent-elles les exigences à inclure dans le sprint ?. Alors la réponse est d’utiliser la technique  » calculs de vélocité « .
  • Créer des fiches et les mettre sur une table (comme ça tout le monde se sent plus impliqué personnellement)
    • Après la réunion de planification de sprint, notre Scrum Master met à jour le backlog de produit sous Excel., en respectant le moindre changement apporté physiquement sur les fiches.
    • taches_activity
  • Qu’est ce que veut dire « terminée » : Il est important que le Product Owner et l’équipe s’accorde sur une définition claire de « terminée ».
    • On peut dire une exigence est terminée quand le testeur de l’équipe Scrum le dit (prêt
  • L’estimation de temps avec le poker de planning : chaque membre de l’équipe est impliqué dans l’estimation de chaque exigence en utilisant la technique du poker de planning
  • La clarification des exigences
  • La décomposition des exigences en plus petites exigences : Si vous avez un lot d’exigences à 0.5 points vous allez probablement être victime du micro-management. D’un autre côté, une exigence de 40 points implique un risque élevé de finir partiellement terminée. De préférable de couper une grosse histoire (exigence) en plusieurs histoires plus petites. Faites attention que les petites histoires continuent à représenter des livrables avec une valeur pour le client
  • Le choix du lieu et l’heure pour la mêlée quotidienne
  • Les exigences techniques : 
    • Essayer de trouver un moyen de les transformer en exigences fonctionnelles
    • S’il n’est pas possible, voir si le travail peut être fait en tant que tâche dans une exigence
    • Si les deux méthodes échouent, définir l’historie technique et utiliser les paramètres  » facteur de focalisation  » et  » vélocité estimée  » pour négocier avec le PO et obtenir un peu de temps dans le sprint pour implémenter les histoires techniques

La réunion de planning de sprint est la chose la plus importante que vous faites dans Scrum.

Référence : ScrumAndXpFromTheTrenches