A quelques jours de la fin de Sprint, quels récits remontés du backlog

Communauté Scrum Life
1

Bonjour,

j’ai une escouade back end qui a eu des récits glissants les deux derniers Sprints. Pour des raison de mise à niveau d’outils, les récits ont pris plus de temps que ce que prévoyait l’équipe.
La vélocité à baissé et nous avons pu l’ajuster pour ce sprint (Dans le contexte où je suis je ne peux pas faire du no estimate…Nous sommes en SAFe…).
Nous voilà à deux jours de la fin du Sprint et on se rend compte que les devs vont pouvoir aller chercher dans le backlog un récit.

Lequel choisir selon vous? et pourquoi?

  • Le récit le plus prioritaire même si on ne le termine pas?
  • Un récit prioritaire mais qui pourra être terminé pendant le Sprint en court?
2

Bonjour,

De manière générale il faut prendre le plus prioritaire, sinon a quoi sert de mettre une priorité ? Ça a l’avantage de permettre à l’équipe de prendre un sujet sans avoir à faire un point avec le PO, si par exemple le PO est absent.

Après si il y a une livraison a la fin du sprint et qu’il est possible d’ajouter un item de plus a cette livraison, ça se discute. Est-ce que cet item ne deviendrait pas prioritaire? C’est au PO de le définir.

3

Moi je suis en général assez contre cette pratique
L’expérience me prouve que bien souvent, par excès d’optimisme, ou pour rattraper un sprint précédent, on rajoute des stories à la fin du sprint et soit elles ne seront pas finies, soit elles ne permettent parfois même pas de finir des stories choisies au sprint planning. C’est une pratique très orientée dépilage de tickets et va à l’encontre de la notion d’objectif.
A moins que le récit puisse rentrer dans l’objectif, je vois pas trop l’intérêt si ce n’est livrer pour livrer.
Avec 2 jours restant ça ne me parait pas une marge de fou pour traiter un nouveau SBI jusqu’au done.
Avant de faire ce choix j’aurai tendance à m’assurer que les stories initialement embarquées sont vraiment done de chez done, conviennent au métier, anticiper les feedbacks métiers, et pourquoi pas refactorer, mettre à jour de la doc technique, apprendre…
En SAFe la part belle est donnée à la continuous Learning culture non ?

Citation
The three dimensions are:
Learning Organization – Employees at every level are learning and growing so that the organization can transform and adapt to an ever-changing world.
Innovation Culture – Employees are encouraged and empowered to explore and implement creative ideas that enable future value delivery.
Relentless Improvement – Every part of the enterprise focuses on continuously improving its solutions, products, and processes. The sections below describe each of these dimensions.

4

Comme je ne sais pas ce que veut dire ici « priorité », je dirais que c’est juste la priorité business.

Je proposerais de réfléchir sur une de ces 2 variables que juste la sacro-sainte priorité business, si c’est le cas :

  • le cout du délai = ROI / effort de l’équipe
  • les 4 risques produits : utilisabilité / faisabilité technique / valeur utilisateur / viabilité business.

Une vraie priorité peut alors dégager, et la prise de décision (que ce soit de faire une épopée qui dure plus d’un sprint ou pas) semblera plus évidente !

5

Merci pour vos réponses.
J’apprécie car cela vient immédiatement toucher les points sensibles dans la façon dont l’organisation met en place son « agilité » à l’échelle.

Je vais vous donner un peu plus de contexte, mais attention, je ne voudrais pas lancer le débat sur comment l’organisation a implémenté SAFe, mais avoir votre avis sur ce qui est le moins pire à faire, car j’ai très peu de marge de manoeuvre dans mon rôle et ce que je vous partage est déjà un enjeu qui prend de l’ampleur.

Nous avons donc une escouade de 4 devs back-end, un SM et un proxy PO/analyste fonctionnel/ AQ.

Aujourd’hui, le proxyPO a défini l’ordre de priorité des tickets de manière fonctionnelle. Il veut connaître la capacité de l’équipe pour le prochain Sprint une semaine à l’avance de manière à préparer le prochain sprint. Il ajuste la somme des récits pointés en adéquation avec cette « capacité ».
Son souhait est de pouvoir rapidement communiquer aux parties prenantes ( RTE, Responsables affaires, et consommateurs de nos APIs) ce qui pourra être fait ou non dans le PI (en gros un suivi d’avancement le plus « frais » possible)
Les sprints plannings, servent à trouver des objectifs de Sprint qui englobent les récits « à faire » courant du sprint. Sans surprise, c’est le proxyPO qui suggère fortement les objectifs de sprint pour l’escouade.

Evidemment, l’escouade a une vélocité changeante et dernièrement nous avons eu une vélocité beaucoup plus basse que ce que nous pensions (absence, changements de version des outils, etc.)

Des récits avaient glissés d’un sprint à l’autre et j’avais proposé à l’escouade d’engager une quantité moindre de points, quitte à plus tard aller remonter du backlog un récit. (Le but est de leur enlever la pression que l"entourage met: « si on met plus de récits, ils avanceront plus vite, sinon les gens vont se contenter de faire ce qu’il y a dans le backlog au lieu de faire TOUT ce qu’ils peuvent »)
Et, nous sommes effectivement arrivés dans cette configuration, dont je vous parlais; les gars on terminé leurs récits avant la fin du Sprint.

-Donc sommes nous en dépilage de tickets? oui
-La priorité est-elle établie selon les critères que nous imaginons? En fait, on ne sait pas car il n’y a pas de dialogue ou d’explications de la part de la proxy-PO dans sa stratégie de priorisation.

Comme nous sommes en mode dépilage de tickets, le proxy Po demande de prendre le ticket le plus prioritaire, sans se préoccuper si on peut le finir ou non dans le sprint ( de toute façon ça doit être fait) et concernant l’inspection et la connaîssance de la vélocité, « il suffit de faire la moyenne de tous les sprints précédents ».

Sans surprise dans du dépilage de tickets, les devs ont tendance à travailler en silo: chacun son ticket et « appelle moi si t’as un problème ».
Donc mon objectif en mettant une contrainte de remonter un récit assez petit pour rentrer dans le sprint et qu’il soit terminé, c’est:

  • leur permettre de faire un plan pour s’organiser ensemble;
  • leur permettre de stopper le processus de « c’est pas grave si on termine pas, ce sera fait dans le prochain sprint »;
  • améliorer la connaissance de leur vélocité réelle suite aux changements qui impactent l’équipe.

Maintenant, ma stratégie n’est peut-être pa la meilleure et j’aimerais bénéficier de l’expérience du groupe :slight_smile:

6

J’aurais tendance à dire: si vous faite du waterfall, autant faire du vrai waterfall et le faire bien…

7

Ça c’est une balayette

1 « J'aime »
8

Exactement :laughing:, @Samuel_Abiassi attaque balayette.

C’est super efficace.

— Un peu de sérieux.

Comme le dit Samuel, il suffit de prendre le premier élément de la pile puis de le commencer.

J’ai une idée

Personnellement, j’ai envie de te conseiller d’ouvrir ton parapluie. Comprendre le théorème du parapluie.

Il consiste en trois étapes :
Inventer un monde dans lequel modéliser notre question ;
Résoudre le problème dans ce monde ;
Transférer le résultat dans le monde réel.

— source : Principe du parapluie

Intention

L’intention est de simplifier dans ton esprit, les éléments dont tu as le contrôle. Ceux qui sont sous le plafond de verre. Donc de casser le décor fictif et faire émerger la réalité factuelle.

À quoi cela pourrait ressembler ?

L’ouverture du parapluie a pour effet de remplacer l’idée de Sprint par l’idée du Kanban.

  • La période du Sprint est remplacé par une période où on compte le nombre de sujets réalisés.
  • Les événements sont conservés.

Par contre, cela devrait rester interne à l’équipe. Il faut fermer le parapluie lors des communications avec l’extérieur.

On peut faire encore plus simple, que l’idée du Kanban, avec une liste d’éléments ordonnés.

Question

Est-ce qu’avec ce parapluie cela te permet d’y voir plus clair ? Sinon, tu peux choisir un autre parapluie.

9

merci pour ta réponse @Alexandre_Quercia
Je vais essayer de reformuler pour etre certaine de bien avoir compris ta suggestion :slight_smile:

Comme je n’ai pas de maîtrise sur l’organisation autour de mon escouade et comment ils souhaitent appliquer le processus, ce serait de concentrer l’attention des devs sur ce qu’ils ont réussi à terminer pendant le sprint.
Ouvrir le parapluie au début du sprint et le refermer à la fin de la période en ne comptabilisant que ce qui est vraiment terminé?
L’image qui me vient serait comme une bulle transparente qui intégrerait uniquement les métriques qui répondent à la DOD ? Et appuyer la communication de l’équipe, dans l’équipe, là-dessus?

10

Merci de t’avoir prêtée au jeu de la reformulation, c’est une excellente idée.

Je ne suis pas certain que tu as compris. En me relisant, je remarque que je n’ai pas réussi à écrire un message compréhensible.

Cependant, ce que tu exprimes est un relatif bon état d’esprit.
Je le reformule comme ceci : Se focaliser sur ce dont nous avons le contrôle.

Pour revenir à ma suggestion

J’ai essayé d’utiliser un exemple pour l’illustré, mon sentiment est qu’il ne se suffit pas à lui-même.

Ta reformulation est ancrée dans la période du Sprint. Alors que mon idée est de prendre de la hauteur, de dézoomer. Comme tu l’expliques qu’un ticket peut traverser le cocon du Sprint.

En prenant cette hauteur, c’est comme monter au sommet de la tour Eiffel et voir un plus grand paysage.
L’interprétation de ce paysage varie en fonction du point de vue de l’observateur. Nous avons :

  • Le manager qui voie l’usage de Scrum avec ce qu’il comprend de ce cadre.
  • Ton équipe qui semble voir une incohérence sur la mise en pratique de ce cadre. Une dissonance est présente. Et donc se pose des questions afin de trouver un sens aux faits observés.
  • … il y a potentiellement d’autres observateurs

Et donc

L’ouverture du parapluie applique une transformation.
La fermeture du parapluie applique la transformation inverse.

Ceci est incohérent avec le concept d’objectif de Sprint.
Par contre, ce n’est pas incohérent avec le concept de flux tiré.

Parler d’une poule qui se comporte comme un chat, c’est contre-intuitif.
Autrement-dit, appeler un chat, un chat permet de facilité nos réflexions.

D’où

C’est contextuel

Ceci est applicable pour pallier l’effet du plafond de verre.
Qui nous enferme dans le « dépilages de tickets ».

Idéalement, nous voudrions faire changer les mentalités.
En pratique, c’est très difficile.

Impossible n’est pas français. :sweat_smile:

Au passage, Scrum dans SAFe et Scrum du ScrumGuide sont différents.
cc @Robin_Beraud-sudreau

11

De ce que je comprends, vous avez atteint votre objectif de sprint. Dans ce cas, super, vous avez réussi votre sprint!

Souvent on pense à 2 cas de figures :
1- Anticiper le sprint suivant
2- Rattraper la dette

1:
Si vous anticiper le sprint suivant, très bien vous gardez une dynamique, vous continuez a avancer.

Mais il faut le faire en gardant du sens, en ayant un objectif. Souvent je vois écrit « dépilage de ticket » comme si c’était un gros mot. Dans beaucoup de méthode on dépile des tickets. On prend un ticket dans une pile (pile priorisée par exemple un sprint backlog ou product backlog) et on le traite. L’important c’est de le faire avec un sens, ici un objectif de sprint ou de produit.

Le mauvais cas serait, dépiler un ticket car ce sujet est écrit noir sur blanc dans un contrat, mais a la fin cette fonctionnalité ne sera jamais utilisée, car elle aura été réalisée juste parce qu’on avait dit qu’on le faisait, c’est une mauvaise raison de dépiler ce ticket. Ou par exemple, dépiler un ticket pour une question de vélocité, c’est aussi une mauvaise raison.

2:
Rattraper la dette, refactorer, est une bonne façon de s’améliorer, d’améliorer le produit.

Mais attention, si vous prenez les jours a la fin du sprint pour faire, un peu a la manière de safe, une phase d’IP. C’est sûrement un mauvais signe, le signe que vous n’integrez pas assez vos axes d’améliorations continue de manière pèrenne.

Pour conclure, de mon point de vue, je traite « l’amélioration continue » en continue dans le sprint et non pas si j’ai du temps de dispo a la fin.
Je garde une dynamique en anticipant les prochains sujets, tout en gardant la cohérence avec les objectifs de sprint ou du produit.

12

merci @Alexandre_Quercia je comprends mieux :slight_smile:
oui j’avais pensé à Kanban, mais cela nous a été refusé car il faut faire des PI et des sprint commes les autres équipes.
Mais j’aime beaucoup ton idée de parapluie :slight_smile: Je retiens le concept.
Je vais voir quelles adaptations je pourris faire et comme tu dis manoeuvrer ce sur quoi j’ai de l’influence

13

Je partage tes recommandations à 100%, j’ai de la misère à me faire entendre du proxyPO :frowning:
Selon lui il faut avancer au plus vite pour répondre aux engagements de PI. J’essaie de faire comprendre que la maintenance a aussi une valeur d’affaire.

Je vous avoue que pour cette histoire de ticket, je relache un peu la bataille pour le moment car la relation avec le proxyPO devient vraiment difficile
Je pourrais écrire bientôt un témoignage dans la catégorie " ma pire expérience" LOOL

Merci à tous pour vos réponses. Cela fait chaud au coeur de vous lire

1 « J'aime »
14

Je pense que tu as compris. C’est dans ce contexte que le parapluie « Kanban » pourrait aider, car il y a que toi qui le « vois ».

L’intérêt est surtout de se préserver psychologiquement.

1 « J'aime »
15

Yup. Un backlog est effectivement une pile (ordonnée par ordre de livraison plutôt que par priorité au passage), et donc, techniquement, on dépile effectivement des items. Rien de mal à ça.

16

Ce qui me gêne c’est associer depiler à ticket
Comme chez le boucher

17

Qu’est ce qui te gênes derrière ça ?

18

Le process machinal que suggère l’expression.
Dépiler c’est prendre le premier élément d’une liste, ça implique forcément l’absence de réflexion de la personne qui prend le ticket
Tu vas forcément répliquer que dans ce cas là la liste doit être ordonnée pour pouvoir être dépilée
Certes, mais l’empirisme nous montre que c’est rarement le cas

19

1- Pour l’ordre du backlog :
J’utilise le terme priorité car il est générique. La priorisation dépend du fonctionnement de l’équipe. Il y a peut être deux types de priorité, celle qui sert à planifier (pour optimiser l’avancement) et celle qui sert à se concentré sur un item (si on doit réduire le périmètre)

Pour la priorité qui sert à la planification :
Si tu livres à la fin d’un sprint 10 items, ces 10 items on le même ordre de livraison il faut donc bien ajouté une « priorité » pour planifier au mieux le sprint.

Si tu parles d’ordre de livraison pour dire « atteindre la DOD », c’est pareil, un item peut mettre plus de temps qu’un autre à être traité, par ex tu commences l’item A avant le B mais le B sera fini avant le A. Ou autre cas pour optimiser l’avancement en fonction des congés des gens. Il y a pour moi plein de critères qui peuvent entrer en jeux dans une priorisation autre que l’ordre de livraison.

2- Pour la phrase « Dépiler des tickets » :
Si le rôle d’une personne se limite a ca, effectivement c’est mauvais.

Le contexte scrum amène les gens à remettre en cause chaque chose si il l’estime nécessaire :

  • On priorise le product backlog
  • On planifie la réalisation du produit (ce qui peut remettre en cause la priorité)
  • On priorise le sprint backlog (ce qui peut remettre en cause la priorisation du product backlog)
  • On planifie la réalisation du sprint (ce qui peut remettre en cause la priorité des items)
  • On planifie la journée (daily scrum) (ce qui peut remettre en cause la priorisation du sprint backlog)
  • On remonte un problème (hors cérémonie scrum) → Remise en cause priorisation/planification

Scrum permet de se remettre en cause à beaucoup de moment lors d’un sprint, mais surtout il doit amener à se remettre en cause perpétuellement.

Si un dev dépile sans réfléchir, il y peut être un problème de management ou de motivation, généralement les gens réfléchissent par eux même, surtout dans un contexte qui se veut scrum ou on doit remettre en cause les choses.

20

Je parlais dans ce contexte du Product Backlog. Aucune notion de DOD ou autre. C’est purement de la planification de ce qu’on prévoit de sortir dans les prochains sprints. Un élément peut être ultra-prioritaire mais pas « ready » (dépendances externes), se retrouvant de facto derrière des choses livrables plus tôt.

1 « J'aime »