Un coach agile dans les pièces automobiles – Sprint 1 release plan et backlog maintenance

Release plan

Durant le sprint 0, une seule epic avait été estimé. Alors une première version d’un release plan a été fait avec une hypothèse farfelue. Elle est farfelue, mais avec l’information que nous avons à ce point du projet, c’est la meilleure que j’ai trouvée.  Mon hypothèse est que toutes les epic ont la même complexité (en considérant que même s’il y en a des plus petites, il y en aurait des plus grosses, donc le tout s’équilibrerait). Dans notre cas, la somme des valeurs des stories qui composent l’epic est 31 points. En faisant des calculs savants de conversion de points en heures selon le découpage en tâches des stories, ça mène à une date de fin potentielle à la mi-juin 2011. Nous allons voir avec le temps si mon hypothèse tient moindrement la route…

Une livraison “pilote” dans un certain nombre de magasins (1 à 3, le nombre reste à déterminer) est prévu pour la fin de l’année 2010. Alors une deuxième itération sur le release plan est nécessaire pour vérifier ce qui peut être réalisé pour le pilote. Une nouvelle estimation des epic est faite en les comparant à la première (celle-ci a été développée durant la première itération). Pour faire la ré estimation, la première epic a été considérée comme un 5, ensuite les autres ont été estimée selon l’échelle de presque Fibonacci habituelle. En refaisant encore des calculs savants, le release plan a été révisé pour mener la fin potentielle du projet vers la mi-mai 2011*, et anticiper que le pilote est réalisable pour le début décembre. Il faudra sûrement jouer sur l’étendue de l’epic, c’est à dire sur les éléments qui composent les epic “essentielles” pourront être livrées pour le pilote.

* l’hypothèse farfelue du départ ne semblait pas être si farfelue puisque la date de fin n’a bougée que d’un mois, ce qui ne me semble pas significatif comme changement.

Pour terminer, nous avons mis sur une échelle du temps la date où certains dépendances externes (interactions avec des systèmes externes) devraient être abordées/mis en place, ceci afin de ne pas risquer les dates anticipées.

Backlog maintenance

Le PO a rédigé quelques stories et bougé des priorités dans le product backlog. L’équipe doit maintenant estimer ces nouvelles stories. Nous avons 4 stories d’estimées (3 qui ont été développées durant la première itération, et 1 non amorcée) qui serviront de base de référence pour les nouvelles estimations.

Je laisse l’équipe estimer 4 stories avant de leur faire part d’une inquiétude. La première itération contenait 6 points. Les nouvelles stories estimées sont de 5, 13 ou 20 points. En principe, ces stories ne pourront donc pas être réalisées durant une itération puisqu’elle dépasse la capacité de l’équipe. On arrête pour une quinzaine de minutes la maintenance pour discuter de la taille des stories et voir si elles peuvent être découpées en plus petites. Le PO dit que les stories ne peuvent pas être découpées plus parce que (par exemple) “une commande ne peut pas être exécutée complètement si on n’a pas les SKU et les items”. D’accord! On discute pour voir si on peut quand même le découper en 2, question de diminuer le risque. Pas certain. Pour ne pas détourner l’objectif du backlog maintenance trop longtemps, la discussion sur le découpage des stories est reportée. On continue à estimer des stories restantes. Même si on n’a pas complètement conclu le sujet, la discussion a portée fruit; on se question si on peut découper les stories suivantes lorsqu’elles semblent un 5 ou plus. Aussi, une nouvelle story est rédigée pour traiter un cas plus spécifique, réduisant ainsi la taille d’une story du PO.

Il y aura de travail à faire avec le PO pour qu’il écrive plus de stories qui sont réalisables dans une itération. Il pense qu’il y a assez de travail pour occuper l’équipe pendant plusieurs itérations, alors ce n’est pas nécessaire d’ajouter des stories. La logique n’est pas fausse, mais la faille est que le travail semble trop gros pour être réalisé dans 1 itération. Si les stories restent de cette taille, elles ne seront que partiellement développée durant une itération. L’équipe s’est d’ailleurs questionnée sur la durée des itérations (présentement 2 semaines). Nous allons probablement (si l’équipe veut aborder le sujet!) en rediscuter durant la rétro d’itération.