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.
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.
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 ! 
T’as des sources fiables, faciles à ingurgiter (genre une vidéo bien foutue lisible en x1.5 
) qui me permettrait de découvrir ces uses cases ?
J’en ai en anglais si ça te déranges pas 
Pour le français, c’est plus compliqué x)
Je prends yes, ce sera peut être pas en accéléré haha
C’est la meilleure ressource que j’ai trouvé à ce jour sur le sujet. Après, ça me dérange pas de refaire une présentation si besoin =)
Ah ouais grave j’ai vu passer des infos comme quoi tu avais fait ça. Ça m’intéresse beaucoup de comprendre cette approche/outil (je ne sais pas encore comment l’appeler haha). Merci pour la vidéo, je vais regarder ça.