Que ce soit en mode projet ou dans le cadre d’une équipe d’intégration type « Centre de service », il arrive très souvent de se retrouver à la fin d’un sprint avec des tâches non terminées.
Selon la méthodologie Agile et ses différents frameworks (Scrum pour le plus populaire), il s’agit bien sûr d’éviter le plus possible de se retrouver dans cette situation.
Or, nous savons tous que c’est le propre de notre métier de devoir nous adapter aux différents changements et ce, même durant le sprint en cours.
En effet, nouvelles demandes prioritaires, abandon d’un flux, dépriorisation d’un flux, etc. sont monnaie courante dans le domaine de l’intégration.
Cela fait maintenant plusieurs années que nous utilisons Azure DevOps (nouveau nom de VSTS) et plus globalement que nous organisons nos équipes et nos projets avec la méthodologie Agile, c’est pourquoi nous avons aujourd’hui assez de recul pour constater ce fait :
« C’est la méthodologie Agile (et l’outil Azure DevOps par extension) qui doit s’adapter à notre organisation et pas l’inverse ».
En partant de ce constat, comment donc gérer au mieux les tâches non terminées dans Azure DevOps à la fin d’un sprint ?
Ce que nous pouvons appeler la « césure de sprint » peut être réalisé manuellement mais nous vous conseillons fortement de mettre en place une procédure.
Un grand nombre de choses peut être automatisé ou très facilité par le plugin TFS Excel (et Access par conséquent). Ces éléments-là feront l’objet d’un autre article.
Entrons donc dans le vif du sujet. La capture d’écran ci-dessous représente l’image du backlog à la fin du sprint 1.
Comme pouvez le constater, les tâches 2, 3 et 4 ne sont pas terminées.
Ce qu’il ne faut définitivement pas faire : déplacer les product backlog items du sprint 1 au sprint 2.
En faisant cela, l’effort appliqué à la vélocité du sprint 1 sera déplacé à celui du sprint 2. Prenons par exemple l’US1 dont l’effort a été estimé à 13. Ici, 31 heures ont déjà été réalisées alors qu’il n’en reste que 7. Si vous déplacez cette User story au sprint suivant, la vélocité pour le Sprint 1 ne représentera plus précisément l’effort qui a été accompli pour le sprint courant. De plus, l’effort de 13 qui sera appliqué au Sprint 2 n’aura pas vraiment de sens puisqu’il ne restera que très peu d’heures à réaliser.
Voici donc comment gérer la césure de sprint :
1. Pour les Product backlog items (ou User stories) non terminés, les dupliquer et les affecter au sprint suivant comme ceci :
Lors de la duplication des items, bien penser à inclure les liens existants (cf ci-dessous) :
Comme vous pouvez le remarquer, nous avons renommé les User stories pour plus de clarté.
2. Mettre à jour l’effort sur le product backlog item original (avec l’aide de l’équipe de développement). Il est possible de mettre tout de suite l’effort sur la nouvelle User story. Pour notre part, nous préférons le laisser vide pour le moment et l’évaluer plus tard lors du sprint planning.
3. Identifier les tâches non commencées et les reporter sur le sprint suivant.
Ici, seule la tâche 3 est concernée.
4. Identifier les tâches en cours, les clore et les dupliquer en reportant le travail restant (Remaining Work) sur le sprint suivant.
Ici, ce sont les tâches 2 et 4 qui sont concernées.
5. Clôturer les User stories du sprint 1.
Comme vous pouvez le constater, cela peut vite devenir fastidieux si vous avez un grand nombre de tâches non terminées. C’est pourquoi je vous encourage à automatiser un maximum ces différents process.
Malgré ce côté quelque peu « fastidieux », vous remarquerez qu’il y a beaucoup d’avantages à utiliser cette approche :
Pour terminer, voici ci-dessous une image du backlog avant / après la « césure de sprint ».
Avant :
Après :