Gestion des tâches non terminées à la fin d’un sprint dans Azure DevOps

Bastien BRAILLY-VIGNAL
Catégorie : Azure / DevOps / VSTS
05/09/2019

Contexte

 

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 ?

 

Gestion de la césure de 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.

 

Fin de 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.

 

Procédure

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 :

 

Fin de sprint 2

 

Lors de la duplication des items, bien penser à inclure les liens existants (cf ci-dessous) :

 

Dupliquer un PBI

 

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.

 

Fin de sprint 3

 

3. Identifier les tâches non commencées et les reporter sur le sprint suivant.

 

Fin de sprint 4

 

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.

 

Fin de sprint 5

 

Ici, ce sont les tâches 2 et 4 qui sont concernées.

5. Clôturer les User stories du sprint 1.

 

Fin de sprint 6

Récapitulatif

 

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 :

  • Lisibilité ;
  • Préservation du lien entre les différents items même d’un sprint à l’autre ;
  • Estimation fidèle des User stories (ou Product backlog items) ;
  • Suivi / reporting cohérent ;
  • Etc.

Pour terminer, voici ci-dessous une image du backlog avant / après la « césure de sprint ».

Avant :

 

Fin de sprint 1

 

Après :

 

Fin de sprint 7