Quand faire l’affinage

Un message a été fusionné à un sujet existant : Ne plus dire « Grooming »

Perso, on reserve 1h chaque semaine pour le backlog refinement
Ce n’est pas de trop et c’est très supportable pour l’équipe

1 « J'aime »

Le contenu de ce qu’on fait pendant ce temps est plutot variable.
Et on est pas obligé d’occuper l’heure si on a terminé plus tôt, mais bon, ça n’est pas arrivé depuis janvier.
Tantôt on modélise le programme/Épopée
Tantôt on la priorise, avec le métier, pour sortir un MVP puis des MMF
Tantot on decoupe juste des fonctionnalités en des cartes en visant une taille étalon
Tantot on relis juste les cartes et on repère les eventuelles adhérences
Tantot on preaffecte même les cartes suivant les affinités des devs, même si derrière le dev qui tire n’est pas forcément celui preaffecté

En gros, tout ce qui peut alimenter la notion INVEST

Ça permet aussi à l’équipe d’appréhender ce qui va arriver, ce qui facilite la planif de sprint

J’en parlais tout à l’heure avec 2 amis.

IMHO le backlog refinement je l’aime en mode tres amigos => pas tout le monde en même temps, le P.O. à chaque fois, mais une chaise musicale pour l’amigo du « est-ce faisable » et l’amigo du « est-ce utilisable »
Et je vois 2 sous classe de refinement.
Le travail sur les PBI qu’on voudrait voir ready parce qu’elles vont probablement être pertinentes pour le prochain objectif de sprint. (En se laissant des latitudes, on sait un peu vers quoi on veut aller si on relance un sprint de plus après le sprint en cours)
Et on a le travail sur les PBI encore toutes fraiches, assez floues.
Là j’aime l’idée d’une présentation à toute l’équipe, en mode « plantons une graine de réflexion ».
Pendant cette session, on demande juste de réagir à chaud, en silence, par écrit. Un écrit (postit ou note) par PBI proposé. Et cela sert de matière première pour les sessions en tres amidos ultérieures.

1 « J'aime »

3 messages ont été scindés en un nouveau sujet : Renommer un sujet

6 messages ont été scindés en un nouveau sujet : J’ai l’impression que personne n’a réagit sur ton message et cela m’embête

En phase, je suis un grand fan de l’atelier 3 amigos en example mapping.
Sauf que le 3 A, je le fais quand on tire une carte/US.
Comment tu fais emerger cette carte/US?

Le backlog refinement je m’en sert pour ça : c’est quoi le prochain sujet à decouper en cartes, et hop on le decoupe pour que les 3A sur le sujet soient fluides. Quand on mets le sujet en sprint goal, l’équipe l’a déjà découpé, priorisé pour en sortir une version qui correspond à la durée du sprint.

Ce n’est pas une perte de temps, quand ton équipe commence à avoir l’esprit agile. Aime avoir une appropriation collective du backlog, anticiper.

C’est une perte de temps, quand ton équipe pense que les carte sont entièrement écrites pas une tierce personne, le PO, le metier, voir les BA…

Le faire sur les elements du sprint, c’est un coup de retard, le faire sur les prochains sujets qui seront dans de prochains sprints goal, là c’est le bon moment.
C’est donc, à mok sens, pendant un sprint pour le ou les sprints futurs

Préférez le faire régulièrement qu’à chaque release

Et si le coup de retard c’était justement de ne pas -permettre de - le faire pendant le sprint ? Si c’est une découverte pendant le sprint, on fait quoi ? On fait le refinement mais on attend le prochain sprint ? L’opportunité, l’occasion d’apporter plus de valeur n’est elle pas manquée ?

(Je précise que je ne dit pas qu’il faut le faire UNIQUEMENT sur les éléments du SPRINT backlog ni que cela devrait être la majeure partie des sujets etc, mais je dis l’inverse, c’est à dire qu’il ne faut pas le faire QUE sur les éléments du PRODUCT backlog pour préparer. Cela pour permettre de s’adapter pendant le sprint et de garder un périmètre négociable pendant sprint sans mettre en péril l’objectif).

Clarifions un peu le concept: les espaces problemes/solutions sont des idées intéressantes pour comprendre les dynamiques du management produit. Cependant, ces deux espaces ne sont clairement pas séparés strictement l’un de l’autre et sont même bien plus poreux qu’on l’imagine. Du coup on navigue souvent à la frontière entre les deux. Ce qu’il faut retenir du modèle double diamants, c’est plutôt le fluctuation entre élargissement et rétrécissement des scopes. Le raffinage est en l’occurrence clairement un exercice de rétrécissement dans le fait que si vous en sortez avec plus de questions que d’hypothèses, vous n’allez clairement pas pouvoir avancer vers le sprint planning sereinement.

2 « J'aime »

Ce serait un cas à la marge, il ne faudrait pas que cela devienne la règle.
Genre tu tires une carte, tu fais le 3 Amigos dessus, et tu vois que c’est trop gros, tu challenges le sujet pour que ça tienne dans le sprint.
Si le sujet est vraiment gros, il faut changer le rituel, le passer en refinement et en sortir les 2-3 US les plus importantes pour les délivrer dans le sprint.

Mais encore une fois, cas à la marge. La gestion du backlog, le role de PO, l’agile, c’est pas de l’arrach’

Je te rejoins complètement sur ‹ l’arrache ›.
Et je crois qu’on ne parle pas de la même chose.

Je (l’équipe) suis dans mon sprint. Dans mon plan, j’ai un item déjà passé en refinement, il est suffisamment petit pour être fait dans le sprint et il permet d’atteindre l’objectif (avec d’autres copains items). Je commence à écrire les tests et là en lisant les critères d’acceptation qui me paraissait très clairs, soudain cela ne l’est plus trop compte tenu de ce que j’ai appris en écrivant les tests ou en regardant comment tester. Je décide d’échanger avec les parties prenantes, ensemble nous confirmons que c’est plus compliqué que ce qu’on avait prévu, on détaille voir même on découpe encore. On se confirme (avec
le po) que c’est la bonne chose à faire etc. Ces activités après avoir découvert quelque chose qu’on n’avait pas vu, pour moi, sont du même type que le refinement. L’objectif est le même, comprendre, detailler et découper. C’est juste pas fait pour préparer le prochain sprint, mais je ne m’en passe pas parce que c’est maintenant que c’est la bonne chose à faire.

Autre exemple, je (toujours l’équipe) suis dans mon sprint, pareil sur un élément du backlog de sprint, on est en train de valider que c’est done et on se rend compte que pour atteindre l’objectif de sprint, ce n’est pas l’item d’après qu’il faut faire mais autre chose qu’on n’a pas vu avant et qu’on a découvert grâce aux feedback qu’on est allé chercher pendant le sprint. Échange, négo, on prend ce nouveau sujet, on sort l’autre éventuellement si nécessaire. Ce nouveau sujet il faut le détailler, voir le découper. Ben là encore selon ma compréhension, c’est le même type d’activités que du réfinement

Se priver de ça, c’est se priver d’adaptation.
C’est de ça, par exemple, dont je parle et qui me semble important. Mais je l’appelle peut être abusivement ‹ refinement ›.

Qu’en penses tu ?

Le seul truc qui se cache derrière pour moi, c’est : Est ce que l’objectif est encore possiblement atteignable à la fin du sprint. Du coup, est ce qu’on doit annuler le sprint ou pas.

Je pense que ça dépend de la finesse des items. C’est une question qu’il faut se poser je suis complètement d’accord.

Se priver de ça, c’est se priver d’adaptation.
C’est de ça, par exemple, dont je parle et qui me semble important. Mais je l’appelle peut être abusivement ‹ refinement ›.

Oui totalement d’accord avec toi. Sans transparence, sans adaptation on n’est plus agile du tout. Et je pense que personne ne remet en cause cela.

L’idée de base c’était l’affinage du product backlog, c’est l’activité essentielle pour éviter l’écueil que tu décris. Car pour moi ce que tu décris ne doit arriver qu’à la marge comme le dit @TheLimande sinon on va droit vers l’annulation du sprint comme le rappelle justement @Samuel_Abiassi
Et donc si ce cas arrive comme ça en cours de sprint, moi en tant que PO je me dis que j’ai pas fait ma part du taffe. En fait, l’empirisme ne se limite pas à faire du code et s’apercevoir que ce qui est développé ne va pas. Il y a plein d’autres moyens d’avancer dans l’entonnoir de la solution et de mitiger le risque de se planter.

Donc bien sûr que oui on affine en cours de sprint mais cet affinage, comme je le disais au dessus, c’est pour moi juste du travail quotidien qui vient avec la collaboration, la communication, l’alignement, le focus.

1 « J'aime »

Allez, remettons une pièce. La pratique du développement de ces dernières années à pris la tendance de dire qu’il n’était pas efficace de travailler en amont sur de l’analyse. Les fameuses « specs émergente », « (un)know/(un)known », « logiciel qui marche plus que doc exhaustive » et plus globalement, la création itérative de système.

Dans les faits, on peut arriver à des résultats très variables de cette manière. D’un côté, tout peut très bien se passer (c’est généralement le cas pour des systèmes simples). De l’autre, on peut se retrouver avec une architecture à la complexité accidentel galopante parce qu’on a décidé de faire « émerger » une architecture alors que le système est bien plus complexe que la somme de ses parties. La majorité des choses qu’on pense ne pas savoir relève plus du manque de communication et de profondeur de la connaissance du domaine que de facteur réellement non prévisible (comme pour un système chaotique).

L’abandon tout azimut qu’on eu les pratiquants de l’agilité des outils d’analyse, comme le use-case par exemple, a fait beaucoup de mal à la manière dont on approche le métier de développement, au point d’en arriver à ce que tout le monde soit peu ou prou sur un mode « système 1 » les 3/4 du temps.

En phase, c’est pour ça que je veux donner une vision moyen et court terme à l’équipe.

Le très court terme, c’est l’US (decoupage et priorisation en Example mapping)
Le moyen, c’est sur 6 à 10 semaines (decoupage et priorisation en ateliers de refinement)

Le court terme, c’est le sprint (decoupage et priorisation avec l’objectif de sprint)
Sauf qu’en se donnant un objectif de sprint, on cherche aussi les cartes dépendantes, obligatoires, à redecouper.

Hé ben, t’en as mis du temps ! :joy:

T’as des sources fiables, faciles à ingurgiter (genre une vidéo bien foutue lisible en x1.5 :sweat_smile:) qui me permettrait de découvrir ces uses cases ?

J’en ai en anglais si ça te déranges pas :stuck_out_tongue: Pour le français, c’est plus compliqué x)

Je prends yes, ce sera peut être pas en accéléré haha