Gestion des reports d'US non terminées d'un sprint à l'autre

Communauté Scrum Life
1

Bonjour à tous,

Une petite question pratique sur laquelle je n’ai pas trouvé de réponse satisfaisante pour l’instant : comment faîtes-vous pour gérer les reports des US commencées mais non terminées.
On est d’accord, je pense sur le fait de :

  • Ne pas compter l’US dans la vélocité
  • Ne pas « fermer » lUS et en créer une nouvelle avec uniquement le RAF

Par contre je me demande comment gérer les Story points associés :

  • Solution 1 : on laisse les Story Points originaux. Celà permet de bien les comptabiliser dans la vélocité quand l’US sort enfin. Par contre cela fait faire le yoyo à la vélocité et gène l’équipe pour se projeter sur un engagement de sprint basé sur l’historique de vélocité (surtout dans ses premiers sprints, justement quand le risque d’avoir plusieurs US non finies est maximal)
  • Solution 2 : on modifie les story points pour n’évaluer que la complexité du RAF. Celà permet de mieux calibrer les engagements de sprints, mais il y a du coup une partie de la complexité qui n’est jamais valorisée dans la vélocité.

Je sais bien que dans l’absolu l’équipe de dev devrait pouvoir s’engager sur le contenu d’un sprint sans notion de vélocité historique/somme de story points mais avec la maturité des équipes et la rigidité de l’organisation dans mon contexte celà me semble une marche un peu haute d’aller vers du no-estimates par exemple.

Et vous quelles sont vos bonnes pratiques ?

2

Je m’auto-répond pour donner un exemple pour être sur d’être clair.

L’équipe a une vélocité habituelle de 40 Story points (SP)
Une US de 13 SP n’est pas terminée au cours du sprint n (40 SP engagés) et est basculé en sprint n+1 avec un RAF estimé de 2 SP.
Dans ma vélocité réelle du sprint n, je dois donc ne constater que 27 SP. Jusque là tout va bien.

Par contre

  • Avec ma solution 1, je réestime l’US à 2 SP (complexité du Reste à faire) => JIRA en fin de sprint me comptera uniquement 2 SP pour cette US. Il y aura donc eu 11 SP jamais comptabilisés.

  • Avec ma solution 2, je laisse l’US à 13 SP (complexité initiale) ce qui permettra de bien tous les comptabiliser en fin de sprint, mais je dois rajouter 38 SP d’autres US pour avoir un engagement cohérent avec ma vélocité habituelle (40SP de vélocité habituelle - 2 SP de RAF sur cette US non terminée) alors que JIRA m’affichera un engagement à 51 SP, m’obligeant à avoir une « double comptabilité » pour avoir une vision « SP réels » de mon engagement et m’assurer que mon « sur-engagement » est bien lié à des RAF inférieurs aux complexités faciales des US et non à une trop grosse ambition de l’équipe

J’espère que mon dilemne est plus clair

3

J’ai envie de simplifier le problème.
(même si d’autres auront la simplification ultime en scandant no-estimate )

L’important ce n’est pas le nombre de US, c’est l’objectif de sprint.
Les stories non réalisées retournent dans le backlog produit, et attendront qu’un nouvel objectif de sprint soit en adéquation avec ces stories pour les remettre sur le tapis.

De l’eau aura coulé sous les ponts et les estimations de l’époque correspondront à un contexte de l’époque, donc il faudra les revoir.

Note le « RAF » me pose problème.

Les US ne représentent pas « des choses à faire » mais « un hypothétique nouveau comportement utilisateur que l’on veut constater après livraison, et dont on veut connaitre l’interêt que le système porte à ce nouveau comportement ».

Il n’y a jamais de RAF. Il y a du RAA (reste à apprendre)

En outre le RAF, ou la question initiale, introduit un biais que l’on retrouve dans certaines équipes : la prédisposition au report au « sprint suivant ».

Chaque sprint devrait être vu comme un mini-projet qui a pour but son objectif de sprint.

Le sprint suivant doit pouvoir s’axer sur n’importe quel autre objectif ajoutant de la valeur au produit ou au service.

On remarque dans ces équipes se développer un système de waterfall à débordement.
On remplit le bac(klog) de sprint et on repousse ce qui déborde dans le suivant.
On ne comprend plus l’intérêt des estimations puisque de toute façon, on sait qu’on mettra le reste dans le sprint suivant et on dira « boh on est juste en retard de 15 jours ».

2 « J'aime »
4

Je crois que la vélocité d’une équipe est une information qui ne devrait servir qu’à l’équipe, si elle la comprend bien comme un « indicateur » de sa capacité d’effort sur la durée d’un sprint, afin des choix dans l’ensemble des pistes (US) disponibles à prendre dans le backlog de sprint dans l’optique d’attendre l’objectif du sprint choisi.

6

Bonjour,
Je ne parle que de mon expérience personnelle.
Pour une équipe avec une vélocité de 50 pts. Nous avons acté en rétro de

ne jamais embarquer des us de 13points. Trop gros donc peu de chance de finir. Si 13 alors il faut découper

Une us qui fait presque 25% de la capacité de l’équipe me semble gigantesque.

1 « J'aime »
7

Oh ! Ca c’est un sujet intéressant ! On va y répondre en vidéo :grin:

5 « J'aime »
8

Merci Christophe pour ton retour.
Je reconnais bien ce phénomène que tu décrit de voir l’engagement de sprint comme un vœux pieux, une sorte de direction à suivre plus qu’un engagement (dans mes expérience cela venait aussi d’un manque de communication entre le PO et l’équipe sur l’objectif/la vision produit, et de mise de focus sur l’objectif dans les daily, et pour ça la dernière édition du scrum guide est plus pertinente).

Après je pratique surtout SCRUM actuellement dans un contexte qui est moins propice spontanément à la prospection et la recherche systématique de « disruption » (environnement réglementé / applis batchs/back-Office existantes, etc…) donc avec des objectifs qui sont plus précis/détaillés que l’expérimentation à partir d’une feuille blanche. Dans mon contexte également les choses évoluent plus lentement et donc un objectif de sprint valable en début de mois à quand même relativement peu de chance de n’être plus du tout valable en milieu de mois (et d’ailleurs je me demande franchement si c’est bénéfique pour la société en général de vouloir des évolutions tout le temps, je vais lancer le #slowcode :-))

Pour autant la notion de RAF dont je parlais n’est pas antinomique avec ta notion de RAA. En début de sprint, on se donne l’objectif de tester telle feature en décidant de l’implémenter de telle façon. Suite à des aléas (maladies, complexité sous-estimée, découverte pendant le sprint), l’implémentation choisie ne peut être développée complètement : on a bien modifié la BDD, le back-end, créé une API mais on a pas eu le temps de faire le front => On ne peut ou du moins pas suffisamment « apprendre » sur ce sprint qui n’a déjà été appris par les maquettes statiques, mais on peut quantifier un RAF (le dev front) qui permettra d’apprendre ce qu’on souhaitait.

9

Oui, je rajouterai juste que la vélocité sert aussi au PO pour donner de la visibilité au parties-prenantes (métier et management) sur les releases, donc une mauvaise mesure de la vélocité peut avoir des effets de bords en dehors de l’équipe

10

C’était un exemple un peu au hasard mais ça fait toujours plaisir de revenir sur le sujet de comment découper les US :grinning:, et la « magie » du INVEST qui permet en théorie de faire à la fois du small, du indépendant, et qui apporte de la valeur.

Dans la vie réelle, je pense qu’il vaut parfois mieux une US un peu grosse mais qui fasse du sens d’un point de vue utilisateur plutôt qu’une US découpée "de force " dans le seul objectif de passer sous un seuil de points. Après c’est sûr qu’une grosse US ça se surveille différemment et plus attentivement pendant le sprint mais si l’équipe fait l’effort de découper en tâches technique précises (<1j) et un focus particulier en daily, ça doit pouvoir se faire avec une équipe moyennement mature.

En plus d’un point de vue organisationnel, ça force à travailler à plusieurs et donc à casser les silos, ce qui est bénéfique à long terme.

11

En fait les objectifs de sprints c’est quelque chose d’assez nouveau pour moi. mais ils rendent plus facile a expliquer un concept que je pratiquai déjà avant.

1 dod fini c’est fini.
à moitié ou a 98% fini
… C’est poubelle
→ xp

2 à la fin de n’importe quel Sprint, on doit pouvoir décider de tout arrêter
Tout entrave à cette règle est une prise d’otage, un mensonge sur la promesse de développement itératif.

12

@Moosh ta réponse ne me laisse perplexe. Que veux-tu dire par « poubelle ». Jusqu’à maintenant, je fais passer les fonctionnalités non terminé au sprint suivant. Des fois il manque pas grand-chose mais je demande à l’équipe de terminer un truc propre avant de le passer en done, donc en quelques heures , ces anciennes tâches sont terminées.
Je suis intéressé à connaître vos pratiques pour le calcul de vélocité:

  • vous gardez plus souvent la même valeur d’effort quand vous transférer la tâche qui restait pas grand-chose à terminer au prochain sprint ou vous évaluez à nouveau ?
  • comment estimer de manière la plus pertinente possible la date échéance ? Sachant que mon backlog évolue au fur et à mesure que j’ajoute des fonctionnalités, et à chaque sprint planning, mon équipe n’évolue que une partie des tâches que je juge les plus prioritaires. Nous n’avons jamais une valeur totale de tout le backlog.

Je vous remercie par avance de vos réponses

13

La pratique du calcul de la vélocité, elle est simple : #NoCalculation.
Je regarde la vélocité du dernier sprint, c’est ce qu’on va sûrement faire le sprint d’après. Faire des calculs de vélocité, c’est une perte de temps (colossale) car on ne sait jamais ce qui va arriver dans un sprint.
La vélocité ne sert pas à calculer une date précise : elle sert à connaitre notre variation, et à la diminuer !

Pour la ré-estimation, ma réponse est simple : l’équipe décide. Il n’y a jamais de bonne réponse, et il n’y en n’aura jamais. Chaque façon de faire a ses forces et faiblesses, ça ne sert à rien d’essayer de réfléchir à « la meilleure solution » : elle n’existe pas ! J’ai eu des équipes qui réévaluaients, d’autres non.

Pour estimer de manière la plus pertinente possible la date d’échéance, c’est… pas possible avec une seule valeur. Le mieux qui est possible, c’est stabiliser au maximum la variation (vélocité, si tu préfères) et faire une macro-estimation, qui sera un écart : « au mieux ça prendra 3 sprints, au pire 5 sprints ». C’est accepter l’incertitude que de voir les dates comme des écarts, le but étant de réduire au maximum l’écart.

2 « J'aime »
14

En fait en XP, on préfère recommencer à zéro ce qui n’a pas été fini afin de tenir compte des derniers apprentissages, et surtout ne pas continuer à bâtir sur quelque chose qui a mené à un truc inachevé.

Et pour moi, il en est de même pour les stories. Reporter c’est accepter de répartir sur plusieurs sprints.
Et c’est une mauvaise pratique qui se fait de bonne foi, « oh, c’est dommage, il ne manque pas grand-chose » et qui devient rapidement une mauvaise habitude. ← et franchement, c’est de tout ce que je raconte l’argument qui me pousse le plus à cette façon de penser.

Si les stories sont bien I-nvest, Ce n’est pas dommage pour les autres stories, livrée et pour l’objectif du sprint.
Par contre, c’est dommageable d’imposer à l’objectif suivant ces résidus.

Dailleurs un autre indice d’une bonne amélioration à viser se trouve dans cette partie de la phrase :

Pluriel ? ===> Finish to start, start to finish. Au pire, à la fin du sprint, on ne devrait avoir qu’une story inachevée.

15

Si JIRA est utilisé, alors passer le projet en mode kanban. Cela supprimera le problème du passage de User Story d’un sprint à l’autre.

Et si Scrum n’était pas adapté dans votre contexte ?

Et s’il n’y avait pas de Sprint, le problème disparaîtrait-il ?

Et si le Lean serait-il plus adapté ?

Je pose ces questions, car d’après moi, ici ce n’est pas Scrum qui est appliqué. En voici un exemple :

En Scrum l’équipe s’engage seulement sur l’objectif de Sprint, jamais sur le contenu du Sprint. Un Sprint est un pari, ou plusieurs Et il n’y a pas de notion de Story Point.

Et comme l’a très bien dit @const : source

Dans un sprint, on itère plein de fois afin de valider une ou des hypothèses sur l’apport de valeur, dans une boite de temps qui correspond au temps et à largent qu’on souhaite investir pour valider ou invalider l’hypothèse.

Mon conseil, dans ce type de contexte, est de simplifier un maximum le fonctionnement.

L’aviateur et écrivain français Antoine de Saint-Exupéry définit l’élégance d’un ouvrage d’ingénierie de la façon suivante :

La perfection est atteinte non pas lorsqu’il n’y a plus rien à ajouter mais lorsqu’il n’y a plus rien à retirer.

Durant les itérations d’amélioration continue. Avoir l’idée de supprimer des éléments du process, car il n’est pas préférable de tout chamboulé, le risque est de casser les relations avec l’extérieur de l’équipe.

  • Si l’équipe s’engage sur le contenu du Sprint alors essayer de supprimer l’objectif de Sprint.

  • Si le Sprint est une itération, alors essayer de supprimer la notion de Sprint. Passer en flux continue, Kanban.

Au final, on pourrait se retrouver avec une liste limitée d’éléments ordonnés qui seront réalisés les un après les autres en collaboration.
Si un élément est une hypothèse, alors une boite de temps pourrait être investi.

1 « J'aime »
16

Après plusieurs sprints, mon équipe de développeurs a réussi à estimer assez précisément la charge de travail nécessaire pour chaque sprint, ce qui leur permet de (presque) tout terminer à la fin du sprint. Cependant, nous rencontrons un autre problème : de nombreux bugs sont détectés après la fin du sprint. Les USs font de nombreux allers-retours entre les testeurs externes à l’équipe et les développeurs, ce qui signifie qu’au moment de la revue, seule une petite partie du travail est considérée comme « terminée », et le reste est reporté au sprint suivant avec des bugs à corriger.

Pour minimiser ce problème, j’ai détaillé le périmètre des travaux, les critères d’acceptation et les scénarios de test autant que possible, et j’ai demandé aux développeurs de bien vérifier avant de soumettre une fonctionnalité aux testeurs. Lors du dernier sprint, il y avait moins de bugs, mais il y avait encore un décalage de temps entre la fin du développement, le début des tests, et surtout la fin des corrections de bugs. J’aimerais savoir comment vous gérez les tests et les bugs pour optimiser la quantité de travail présentable lors de la revue.

17

Scrum ne prévoit pas de phase de « recette ». Une user story est censée être validé via les conditions d’acceptation. Un bug, c’est une fonctionnalité qui a été décrite mais qui n’est pas au rendez-vous.
Si la fonctionnalité n’a pas été décrite, ou insuffisamment, c’est une évolution, à entrer dans la backlog.
Mais si tu en arrives là,

  • Soit les conditions d’acceptation ne sont pas complètes au moment de la rédaction de l’US
  • Soit l’équipe de Dev fait de la m…e et délivre une fonctionnalité en sachant pertinemment qu’elle n’est pas terminée
  • Soit l’US est trop complexe et doit-être découpée en sous-taches.

Attention toutefois à ne pas retomber dans du cycle en V « habillé de Scrum ».
Le principe de Scrum, c’est un développement itératif pilotée par la valeur, pas par des spécifications fonctionnelles détaillées…

18

Bonjour @Norbert

Il s’agit principalement des scénarios que je n’ai pas pensé. Par exemple : pour création d’un commentaire, J’ai écrit « un commentaire créé ne doit pas être vide » mais je n’ai pas pensé à préciser que « un commentaire ne doit pas contenir uniquement que des espaces » donc retour testeur et on a intégrer ce bug à corriger au sprint suivant.

Les développeurs font la plupart du temps ce que j’ai précisé mais si j’écris pas , il ne font pas ( par exemple, 1 numéro de tel doit avoir 10 chiffres, si je ne précise pas que le premier chiffre est 0, personne n’y pense et développe)

Il est clair que je ne peux pas penser à toutes les scénarios le premier coup. Si j’ai bien compris il est normale d’avoir ce genre de bug et les réparer au sprint suivant ?

Dans ce cas, vous présentez au review que les choses dans bug ou même celles avec bug connu ?

Merci beaucoup

19

@Hanh_NGUYEN je t’invite à te renseigner sur l’example mapping ou le 3 amigos qui a été l’objet d’une video de SL la semaine dernière

J’ai été pas mal de temps dans ton cas : on nous a pas dit que, on a pas fait parce que c’était pas écrit, etc.

Plus tu vas écrire « dans ton coin » les US plus tu vas avoir des déconvenues et plus tu vas vouloir les détailler et tu vas décrire TA solution qui sera forcément incomplète et pas implémentée comme tu le voulais.

Donc place au dialogue et à la réflexion en commun sur les critères d’acceptation nécessaires. Lors de ces ateliers des critères d’acceptation indispensables émergeront et seront joints à l’US, et d’autres, qui peuvent paraître tellement évidents ne seront pas écrits mais seront discutés avec le ou les développeurs pour ne pas être oubliés (ex. Des espaces à considérer comme des valeurs vides, des 0 à prévoir devant les numéros etc.)

Faut donc arriver à que les développeurs soient engagés dans ce qu’ils vont développer et qu’ils ne se considèrent pas juste comme des exécutants

1 « J'aime »
21

Bonjour @Hanh_NGUYEN ,
Vous devez essayer d’inviter un membre de la team testeurs externes au sprint planning en demandant si les critiques d’acceptions des us sélectionnés sont suffisamment complets.
Je penses que cela peut dans la plus part des cas aider à améliorer, anticiper et compléter ces critères d’acceptations pour la dev team.
Le problème que j’ai toujours rencontré dans cette démarche c’est que le responsable de la team testeurs externes ne comprends pas pourquoi il doit planifier des ressources en dehors de son périmètre de responsabilité.
Cordialement

22

On est dans un cas où on manque de dialogue entre PO et équipe de Dev.
Typiquement, ce genre de « problème » doit être craqué en refinment.

Un sujet « zone de commentaire », ça induit systématiquement de savoir combien de « caractères mini » et combien de « caractères maxi ». « Non vide » n’est pas pertinent. (un commentaire avec 3 lettres ou 2 chiffres n’est pas exploitable).
L’équipe de Dev ne peut pas deviner que la taille mini de commentaire que vous voulez et à combien elle doit le limiter (vous voulez quelques lignes ou un roman shakespearien ?)

Un sujet « téléphone » est différent à mon sens. Un Dev normalement constitué SAIT (ou DOIT savoir) qu’un numéro de téléphone commence par 0 (et que 06 et 07 sont systématiquement associé à un mobile, si vous dissociez fixe / mobile).

C’est comme si vous décrivez un zone email, il y a des normes qu’un Dev connait. Si vous allez au délà des normes dans les contrôles, c’est ça (et seulement ça) qu’il faut spécifier …

La limite, c’est si vous fonctionnez avec des équipes off-shore qui n’ont pas forcément les mêmes références que nous. Ca montre les limites du off-shore (en particulier) et du full-remote (en général)