Validation externe pendant un sprint

Il est préférable que toutes les compétences nécessaires pour finir une story soient dans l'équipe. Pas à l'extérieur.

L'équipe dont j'ai parlé dans le billet Définition de prêt et sprint fait des sprints de 4 semaines. Lors du dernier sprint, le burnup en stories est monté tardivement, en gros de nombreuses stories ont été déclarées finies vers la fin du sprint. Une ou deux autres n'ont pas pu être déclarées finies. Voyons pourquoi.

La vie d'une story pendant le sprint est la suivante :

  • La story est décomposée en tâches, cela se fait -c'est classique- pendant la planification du sprint.
  • Pendant le sprint, les tâches sont effectuées, en général par un ou 2 développeurs.
  • Une fois que toute ses tâches sont finies, la story passe dans ce qui est appelé la validation équipe. Un autre développeur passe les contrôles définis dans la signification de fini.
  • Si cette validation équipe passe avec succès, la story passe en validation PO. Le Product Owner est suffisamment disponible pour valider les stories rapidement. Cependant il arrive que le PO s'appuie sur des référents externes pour effectuer sa validation sur des stories. Cela a été le cas pendant ce sprint et c'est l'explication du problème constaté.

En effet ces référents ne font pas partie de l'équipe ; ils sont beaucoup moins disponibles que le PO. Cela provoque un goulet d'étranglement : les stories s'entassent en attendant d'être validées. Leur intervention en fin de sprint est trop tardive.

Les ressources externes sont une source de blocage quand elles ne sont pas assez disponibles. Pour éviter cela, il est préférable d’avoir au sein de l’équipe toutes les compétences nécessaires pour finir la story. Dans notre cas, cela voudrait dire :

  • soit le PO est autonome pour valider,
  • soit les référents métier font partie de l'équipe.

En attendant d'y arriver, on peut essayer d'impliquer un peu plus ces référents. Une solution simple est de les inviter au scrum quotidien.

Dans un tableau Scrum, on fera apparaître les tâches de validation[1] et parmi elles celles qui sont réalisées par des personnes externes à l'équipe seront identifiées par une couleur (par exemple). Le blocage de ces tâches est considéré comme un obstacle (impediment), souvent visualisé grâce à une pastille rouge.

Sur un tableau de type kanban, on ajoutera une zone spéciale[2] dans la colonne A valider pour mettre en évidence les dépendances externes. Les travaux inclus dans cette zone sont exclus de la limite de TAF.

Notes

[1] plutôt que la 5ème colonne que certains utilisent.

[2] cela peut être un cadre rouge, comme je viens de le lire dans Kanban, le livre de Laurent Morisseau à paraître cette année.

Commentaires

1. Le lundi 16 janvier 2012, 20:36 par Rémy

J'aime l'idée que les conditions de validation fonctionnelle sont dans la définition de Prêt en entrée du sprint. Du coup, la validation finale est beaucoup plus factuelle et on n'attend rien qui vient de l'extérieur.
J'aime l'idée que c'est le PO qui donne le travail à faire, et ces conditions de validation, donc il est le seul à valider SUR LA BASE DE CE QU'IL AVAIT DEMANDE AU DEBUT (et pas des idées que lui ou d'autres ont eu entretemps!).
Charge à lui de bien "capturer" le besoin en amont.
Ceci permet que chacun soit bien dans son rôle.

2. Le mardi 17 janvier 2012, 11:39 par Yannick

Merci pour le billet, il résume bien l'enjeu de notre développement : être à temps pour la mise à dispo des entrées du sprint (notion de prêt) et avoir les ressources pour vérifier/valider en continu...
Le travail de coordination prend beaucoup de temps, mais petit à petit, le process s'améliore, notamment en organisant les rencontres entre l'équipe et les référents métiers. Affaire à suivre...

3. Le lundi 23 janvier 2012, 17:36 par Marco66

Merci pour ce billet tout à fait édifiant sur la phase de validation.
Une question me vient à l'esprit, ne serait-il pas possible de rajouter au ScrumMaster une fonction supplémentaire de "pré"validation de la story. Cela permettrait d'alléger la charge du PO et de s'assurer que les fonctionnalités de base sont correctement implémentées ou qu'il n'y a pas d'anomalie par rapport au backlog de produit ?

4. Le vendredi 03 février 2012, 14:11 par Yannick

C'est ce que nous faisons : il y a une étape "validation équipe" au cours de laquelle un membre de l'équipe valide les stories avant de me les soumettre (validation PO).
Un membre de l'équipe ne prend pas de nouvelle story s'il y a dans l'espace "validation équipe" une story à laquelle il n'a pas participé (principe de validation croisée).