Hello les agilistes
J’ai une question par rapport au backlog grooming
Quand on travaille dans un grand projet où le produit final a plusieurs versions, à quel moment est fait le refinement ? Avant la release planning ou entre la release planning et le sprint planning ?
Merci d’avance pour vos retours!
Hello.
Petit disclaimer: le terme grooming n’est plus utilisé depuis longtemps, portant bien trop de connotations négatives. On lui préfère le refinement que tu évoques.
Pour ce qui est de la réponse… J’ai l’impression que la question concerne SaFE donc je ne m’avancerais/m’impliquerais pas.
1 « J'aime »
5 messages ont été scindés en un nouveau sujet : Ne plus dire « Grooming »
L’affinage(qui déjà noté, le terme « grooming » a une connotation péjorative qui renvoie à la pédophilie et très vite abandonné par Scrum) peut se faire à tout moment, le Po et les Devs peuvent convenir de la durée et de la fréquence(n’est pas obligatoire sauf si on utilise le framework Scrum d’agilité à l’échelle SPS-Nexus, ni timeboxé) en tenant en compte différents facteurs comme la complexité des fonctionnalités selon le niveau de granularité(features, epics, US), les dépendances techniques à identifier/lever…etc.
On recommande en général à l’équipe de réserver 10% du temps des Devs sur le sprint pour les sessions d’affinage(ex pour des sprints de 2 semaines soit 10 jours, en comptant 8hr de travail par jour, l’équipe peut réserver jusqu’à 8hrs d’affinage par sprint à répartir sur une ou plusieurs session(s).
Vous pouvez aussi faire des sessions de release planning qui seront donc plus haut niveau et faire de l’affinage au cours de chaque sprint pour préparer le prochain sprint.
2 « J'aime »
On recommande en général à l’équipe de réserver 10% du temps des Devs sur le sprint pour les sessions d’affinage
Non, surtout pas de réserver 10% du temps, c’est plutôt que ça doit prendre (bien ?) moins de 10% du temps ! Ca ne devrait jamais atteindre les 10%. Sinon, c’est un signe de sessions qui prennent bien trop de temps, et ça doit être modifié rapidement. Même le guide scrum en 2017 disait bien que « ça ne doit pas prendre plus de 10% du temps de l’équipe », c’est pas parce que c’est 10% qu’il faut réserver (c’est un anti pattern que j’ai bien trop vu…)
Pour répondre à la question je vais être cash : le refinement est fait quand il y en a besoin ! Chaque équipe doit trouver sa propre manière de faire, tant que c’est relativement court et que c’est efficace pour l’équipe.
1 « J'aime »
Bonjour @Hind et bienvenue,
Désolé mais comme mes confrères, je ne partage pas certains principes de SAFe.
Je te répondrai sous l’angle du guide Scrum.
Je trouve Scrum assez imprécis sur cette étape du processus. Il peut laisser plusieurs d’entre nous sur une interprétation différente.
Si tu te poses ces questions, alors j’ose te demander Qu’est-ce que l’affinage pour toi et ton équipe ?
En fonction de cette réponse, je pense que tu comprendras comment t’organiser.
Ci-dessous les extraits du scrum guide.
Le Product Backlog est affiné si nécessaire
la Scrum Team affine ces éléments, améliorant ainsi leur compréhension et leur confiance dans leur capacité à les développer
Les éléments du Product Backlog qui sont susceptibles d’être réalisés dans un seul Sprint par la Scrum Team sont considérés comme prêts à être traités en Sprint Planning. Ils acquièrent généralement ce degré de transparence après avoir été affinés.
L’affinement du Product Backlog consiste à décomposer et à définir davantage les éléments du Backlog en éléments plus fins et plus précis. Il s’agit d’une activité continue visant à ajouter des détails, tels qu’une description, un ordre et une taille. Les attributs varient souvent en fonction du domaine d’activité.
1 « J'aime »
Le release planning ?
Le refinement doit de toutes les manières être fait avant le sprint planning. Ca serait perdre un temps fou d’affiner des sujets après les avoir découpés lors du sprint planning. Voire même incohérent.
Ensuite il faut mieux, à mon avis, faire le refinement au plus proche du sprint planning, l’expérience montre que c’est plus simple ensuite pour les développeurs de travailler sur les items lors du sprint planning.
Enfin, le refinement n’est pas obligatoire, faire du refinement pour du refinement peut devenir plus une contrainte et une perte de temps qu’autre chose. Il faut que l’équipe en parle pour savoir si un sujet doit être affiné. Pour ma part, l’atelie concerne un sujet bien précis et ne dure pas plus d’1h, voire au max 1h30 dans un sprint de 2 semaines.
1 « J'aime »
Salut à tous,
Un grand merci pour vos retours clairs. J’avais vraiment besoin de l’avis de praticiens agiles. Pour ma part, je ne travaille pas en équipe Scrum, je suis plutôt dans le domaine de la recherche.
Je lisais « Essential Scrum » de Rubin, et même s’il parle du refinement, du release et du sprint planning, il ne précise pas l’ordre à suivre, c’est pourquoi je me suis posée la question. En tout cas, je constate que la mise en pratique de Scrum diffère souvent de ce que la théorie raconte 
2 « J'aime »
Ok, je comprend ta démarche et ton intérêt.
Je te propose de lire le scrum guide Home | Scrum Guides parce qu’il est facile à lire, moins facile à comprendre profondément.
Ce sera plus digeste de mon point de vue que de te noyer dans la mise à l’échelle, le release management, …
1 « J'aime »
Merci, d’où « peut se faire à tout moment, le Po et les Devs peuvent convenir de la durée et de la fréquence » par exemple dans certaines équipes que je suis même si on a choisi le lundi pour les affinages(entre 1H30 à 2hr) il arrive régulièrement selon les sprints à ne pas en faire du tout et dans l’autre sens, on peut programmer plus de sessions.
Je te rejoins…
Se poser la question du pourquoi faire un refinement ?
Les tickets ne sont pas assez clairs ? Manquent d’informations ? Dans ce cas, l’équipe ne peut pas les traiter, donc il va bien falloir se pencher dessus et que le PO ou BA apporte les éléments manquants pour plus de clarté sur le travail à faire.
La session peut se faire en plusieurs fois, selon la durée nécessaire pour traiter les tickets à clarifier… selon leur nombre et le temps nécessaire pour que l’équipe soit alignée avec le quoi et le comment.
Il ne faut pas forcément ritualiser ou planifier cet événement, comme toujours, ça dépend…
Si le PO ou le BA ont besoin de plus de temps, n’ont pas les éléments à apporter à l’équipe, le point n’apportera rien donc autant ne pas le poser. Si à l’inverse, l’équipe a des questions et qu’il faut clarifier certains éléments, l’équipe peut estimer le temps nécessaire pour le refinement à faire et s’adaptera/s’organisera en fonction… faudra-t-il en prévoir un autre ou pas ? …
Peut-être qu’un one to one avec le dev est suffisant pour éclaircir un ticket, peut-être que seulement certains membres seront intéressés par certains sujets… rester souple et éviter les zones d’obscurité pour que l’objectif du sprint soit atteint… le refinement est un bon moyen d’apporter plus de lumière. On boit quand on a soif… pas parce que c’est l’heure de la pause 
Pavlov would disagree.
1 « J'aime »
j’aime ta capacité de relance à chaque fois, c’est génial !
2 « J'aime »
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…