J’ai l’impression que personne n’a réagit sur ton message et cela m’embête haha.
Alors je le remets sur la table.
Je vous invite à me convaincre qu’apporter des détails, des précisions, découper encore etc… est perdre du temps, incohérent en sprint planning et pendant le sprint et n’apporte pas de valeur. Pour moi, c’est un contre sens à l’inspection / adaptation. De plus cela signifierai que tout le sprint backlog ait été affiné, découpé… figé ? Nan, cela ne me séduit pas du tout.
(Zut @Moosh j’ai zappé de l’extraire pour faire un fil à par entière. C’est possible après coup ?)
Le backlog refinement est une action à mener sur le Product Backlog (cf. le scrum guide) afin de découper, affiner, définire, faire comprendre les items du Product backlog. Ce que je veux dire c’est que pour choisir les items du Sprint backlog avec le plus de prédictabilité possible.
En effet, les items pris en sprint backlog sont aussi affinés en sprint planning et tout au long du sprint.
Je parlais bien de ça :
Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items.
Le scrum guide explique bien que les items sélectionnés sont jugés prêts car un affinage a eu lieu avant le sprint planning
Donc tu es d’accord de dire que ce n’est pas perdre du temps de faire du refinement pendant le sprint, après découpage, sur les éléments du backlog de sprint et sur d’autres ?
Je pense que je n’ai pas compris de quelle incohérence tu parles.
Nuancer me semble important, le risque est de penser qu’une fois que c’est refined avant ou pendant le sprint planning, on lève le crayon et on arrête cette activité pour les éléments qui sont entrés dans le backlog de sprint notamment, rendant le plan et les items figés, voir ne permettant pas d’entrée ou de sortie (donc figer le périmètre au passage).
Je pense que l’on ne parle pas forcément de la même chose.
Quand je fais des ateliers d’affinage, ce qui me semblait être l’objet de la discussion de ce thread (le « grooming »), nous travaillons sur les items de backlog pour dans 1 ou 2 sprints (parfois plus quand la priorisation de nos objectifs changent) afin de travailler sur le « pourquoi » et le « quoi ». Nous sommes dans l’espace du problème. On travaille sur des nouveaux besoins, des feedbacks (du terrain) et on essaye de les comprendre, de s’aligner en équipe sur ces enjeux.
Lorsque l’on part en sprint planning, on va travailler sur le « comment » des éléments sélectionnés pour un objectif donné. Ensuite on va travailler 2 semaines sur le « comment » et on va apprendre tous les jours et évoluer (diverger et converger), mais pour moi, en tout cas, ce n’est plus de l’affinage. On est sur l’espace de la solution.
Donc dans ce que j’ai voulu dire, c’est que oui, ça me semble incohérent d’affiner des items de backlog lors d’atelier dédiés (donc par nature des items qui ne sont pas affinés, pas compris et sur lesquels l’équipe n’est pas alignée) une fois que l’on s’est engagé sur un objectif, en plus du sprint planning.
Après évidemment que dans le sprint les développeurs se parlent entre eux et discutent des solutions avec le PO et les parties-prenantes, mais ça c’est du travail en fait, tout simplement.
Je crois cette idée là me dérange, pour moi on ne parle pas que solution quand on travaille dans le sprint sur un ‹ item › on parle aussi du pourquoi et du quoi et on vient mettre à jour éventuellement les critères d’acceptation en fonction de ce qu’on a découvert appris ou de ce qui a changé (ou peut importe comment on appelle ce qui nous permet de s’assurer qu’on prend la bonne direction avec notre solution où ce qu’on en fait en cascade comme mettre à jour les tests, @Samuel_Abiassi va remettre un jeton pour les use case probablement ). Pour moi, ce n’est clairement pas uniquement orienté solution Et ce travail là, selon ma compréhension, c’est clairement du refinement.
). Pour moi, ce n’est clairement pas uniquement orienté solution 
Et ce travail là, selon ma compréhension, c’est clairement du refinement.