Drupal et Scrum depuis les tranchées - Gérer le backlog du sprint

Votre backlog de sprint est prêt, l'équipe s'est engagée à livrer le périmètre convenu et n'attend plus qu'une chose, poser les mains sur son clavier pour coder ! Lâchez les fauves, l'heure est venue de les laisser s'exprimer.

La prochaine grande étape du projet va résider dans le pilotage des deux ou trois semaines qui composent le sprint. L'équipe va passer beaucoup de temps avec le backlog du sprint, il doit respirer au rythme des commits et des échanges entre les équipiers. Une des valeurs importantes des méthodes agiles est l'auto-gestion, chaque personne doit être pro-active pour s'attribuer du travail et lever les obstacles qu'elle rencontre lors de la réalisation des stories techniques ou fonctionnelles. Il est capital qu'à chaque fois qu'une story est démarrée, change d'état pour être envoyée en testing ou se termine, le backlog du sprint soit mis à jour en conséquence. Le backlog permet d'un simple coup d'oeil de savoir qui travaille sur quoi et de suivre l'état d'avancement du sprint sans avoir à solliciter une personne.

Pour les gens pressés : TL;DR.

Identifier les goulots d'étranglement

Parfois l'équipe a beau se montrer concernée, elle a le sentiment de faire du sur place. Il y a 6 ou 7 stories qui n'arrivent pas à démarrer. Comment comprendre ce qui bloque ? Les stories pourront-elles vraiment être traitées dans ce sprint ? Pour répondre à ces questions, gardez le numéro de votre marabout préféré dans votre poche, on va plutôt chercher à répondre à cela de façon analytique.
Deux outils (au moins) sont à notre disposition pour mesurer notre activité, le burndown chart et le cumulative flow chart.

Le premier est une courbe illustrée ci-dessous sur laquelle on rapporte le nombre de jours écoulés en abscisse et le nombre de points de complexité en ordonnée. Chaque jour nous allons rapporter le nombre de points de complexité restant à faire. On démarre au premier jour à 120 si c'est la valeur de l'engagement de l'équipe et on soustrait tous les jours le nombre de points de complexité que l'équipe a réussi à fermer. Le but du jeu étant d'arriver à 0 avant le dernier jour du sprint. Cette courbe s'appelle un burdown si vous partez de 120 pour aller à 0, elle s'appelle un burnup si vous partez de 0 pour aller à 120 avant le dernier jour. On représente souvent le rythme idéal sur la courbe pour comparer la vitesse de progression réelle.

 

Crédits images : I8abug CC BY-SA 3.0 / Clarios Technologie

Oui mais voilà, le burndown ne montre pas tout, comment se rendre compte si de nombreuses stories sont coincées en attente de tests ou en attente de réponse ? Dans ce cas là nous devons nous appuyer sur un autre outil, le cumulative flow chart. Qu'est ce que c'est ? Ne faites pas cette tête, c'est très simple. Il s'agit un graphique qui représente le cumul des points de complexité pour toutes les stories du sprint. De cette façon vous savez si vous avez un grand écart entre le nombre de stories en cours de développement, de test ou en attente de réponse. Cela permet de repérer les goulots d'étranglement. Une image valant mille mots, en voici un exemple.

Crédit image : Clarios Technologie

Dans l'exemple présenté, on ne voit à aucun moment une masse prendre le dessus sur l'autre, s'il y avait une prédominance du testing on demanderait à l'équipe de donner un coup de main en testing afin de fermer des stories avant d'en commencer d'autres. Le but étant je vous le rappelle de livrer le plus de valeur ajoutée possible. Avoir des stories commencées mais non terminées ne nous avancerait pas.

Quel flux de travail pour mes stories ?

Un point important pour que l'équipe avance sans à-coups est qu'elle connaisse le flux de travail que les stories doivent suivre. Il n'y a pas UN flux de travail à suivre, c'est à vous de l'adapter au projet et à l'équipe mais je vais vous présenter les états qui composent celui que l'on suit chez Happyculture.

  • A faire : Etat par défaut d'une story.
  • En cours : Utilisé dès qu'un développeur choisi de travailler sur une story.
  • Résolu : Sert à indiquer que les développements sont terminés mais pas encore disponibles pour être testés, la story reste assignée au développeur tant qu'elle n'est pas prête à être testée. Cela nous sert principalement à cause de la revue de code, une fonctionnalité n'est pas disponible sur les environnements de test tant qu'elle n'a pas été intégrée au dépôt principal.
  • Besoin d'informations : Un développeur a une question sur un point précis ou le product owner pendant ses tests veut vérifier quelque chose. La personne qui se voit assignée la tache est celle qui doit répondre à la question.
  • A tester : La story est prête à être testée, le lien vers la page précise et les instructions pour clore la tache sont précisées en même temps que la story est assignée au product owner.
  • Fermé : Tout le monde a bien fait son travail, la story fonctionne comme prévu.

Comment gérer les demandes à côté ?

Il peut arriver au cours des tests de stories que le / la product owner tombe sur un bug d'intégration ou sur une phrase à reformuler. Pour gérer ces demandes particulières nous ne ré-ouvrons pas des stories qui auraient pu être candidates à recevoir ces demandes, on s'appuie plutôt sur une story particulière qui se promène de sprint en sprint et qui est un agrégat de toutes les petits demandes du genre. L'équipe y consacre quelques points de complexité à chaque sprint selon les priorités. Si certaines taches sont plus grosses, on ouvre une story dédiée qui sera intégrée au sprint suivant si nécessaire.

Au final, le backlog du sprint est au cœur de l'activité, il permet de s'assurer que tout le monde avance sur ses stories et permet de constater qu'aucun goulot d'étranglement ne se forme, si tel est le cas il est de la responsabilité de l'équipe de trouver les solutions, le scrum quotidien est là pour ça.

TL;DR

  • Le backlog du sprint doit à tout moment résumer l'état réel du projet
  • C'est l'équipe qui met à jour le backlog
  • Le burndown ou burnup combiné au cumulative flow chart permet de contrôler finement le rythme d'avancée de l'équipe
  • Si des goulots d'étranglement apparaissent, l'équipe réagit
  • L'équipe connaît et suit un flux de travail clair
  • Si des demandes non prévues se présentent on les regroupe au sein d'une story spéciale

Votre commentaire

Le contenu de ce champ sera maintenu privé et ne sera pas affiché publiquement.
Votre adresse servira à afficher un Gravatar et à vous notifier des réponses. Votre commentaire sera anonymisé si ce billet est dépublié pendant plus de 3 mois.

À propos de Julien

Co-fondateur - Scrum master & Expert technique

Utilisateur de Drupal depuis 2008, j’ai fait mes armes comme développeur chez Commerce Guys puis me suis mis à encadrer les nouveaux arrivants avant de donner des formations, participer aux avant ventes et accompagner les équipes au passage à Scrum.

Je suis impliqué dans la communauté française de Drupal depuis 2009, j’ai été tour à tour président puis vice-président de l’association Drupal France et francophonie entre 2011 et 2013.