Durant nos sprint , parfois on a besoin de mettre en stand-by une fonctionnalité qu’on a commencé à développer pour différents raisons, par exemple :
elles ne sont pas prioritaire et on peut laisser à côté sans que cela impact l’objectif de notre sprint pour pouvoir concentrer sur celles plus urgents
il y a des dépendances techniques qu’on n’a pas rendu compte avant, il faut donc développer d’autres choses avant
le client a changé d’avis
Etc
Jusqu’à maintenant, je les laisse trainer dans le sprint backlog et quand celui ci est terminé, je la laisse dans le produit backlog, sans forcément transférer au sprint suivant. Elles gardent leur status « dev en cours » tout au long.
Avez vous une autre méthode de gérer ces US pour plus de transparence et visibilité. Faut il créer un statuts stand-by par exemple ?.
Si elles ne sont pas prioritaire pourquoi elle sont dans le sprint backlog? Pour moi il y a un problème de priorisation à traiter
Si il y a des dépendances non anticipées, ca n’est pas grave, si les refinements on bien été réalisé normalement ces dépendances sont mineures, si ca n’est pas le cas c’est qu’il y a surement un problème lors des refinements. Il faut donc analyser ca pour traiter le problème.
Si le client change d’avis, à moins que la fonctionnalité n’est plus de sens auquel cas il faut annuler la fonctionnalité, il faut toujours aller au bout de se qu’on commence pour plusieurs raisons. Le sujet est frais dans la tête des gens, si il a été commencé on perdra énormément de temps et d’énergie à reprendre le sujet plus tard (conflits git, sujet à revoir, sujet traité par une personne différente, etc…). Le fait de constamment changer de sujet sans aller au bout est très démotivant pour les équipes. Il faut mieux aller au bout des sujets pour les finaliser rapidement et garder l’équipe motivée.
Globalement je ne suis pas contre le statut stand by mais pour moi la fonctionnalité en pause doit quand même être finalisée dans le sprint ou au pire dans le sprint suivant. Si le stand by est plus long ca montre qu’il y a des problèmes en amont à traiter.
On les a pris dans le sprint parce que elles sont prioritaires dans l’ensemble, mais quand on est à moitié ou 2/3 du sprint et on se rend compte qu’il reste trop de choses à faire, et cette tâche est moins prioritaire que les autres dans le sprint
oui, nous sommes tous juniors dans le poste et ça nous arrive de faire des erreurs mais on s’améliore en apprenant de nos erreurs
Du vécu dernièrement : j’ai appris pendant un discovery qui fonctionnalité qu’on est en train de développer (calculer un certain frais) doit intégrer d’autres attributs dans la BDD, de nouveaux champs de saisir pour pouvoir tenir compte des situations exceptionnelles, alors que auparavant, on m’a informé que de la situation standard. J’ai demandé le dev en charge de cette tâche de la mettre en stand by le temps que je comprenne bien comment ça fonctionne (une bonne semaine avec les échanges en allers-retours avec le client → impossible de terminer dans le même sprint) et reviens vers lui avec une description claire de modification à faire. À ma place, vous mettez en stand by aussi , vous allez jusqu’au bout quitte à corriger après, ou vous annuler tout et recommencer de zéro plus tard ?
Le statut Standby n’a pas de sens selon moi. Une US est soit dans le flow de dev soit dans la backlog en « ready to share » ou « ready to dev ».
Beaucoup d’indices dans vos récits tendent à penser que vous fonctionnez en mode « best effort » mâtiné de Scrum … il est où le Scrum master ? Il dit quoi quand vous décidez d’abandonner une feature en cours de sprint ou que des adhérences n’ont pas été vues en refinment ?
Citation
j’ai appris pendant un discovery qui fonctionnalité qu’on est en train de développer (calculer un certain frais) doit intégrer d’autres attributs dans la BDD, de nouveaux champs de saisir pour pouvoir tenir compte des situations exceptionnelles,
C’est dans une nouvelle itération que vous devez prendre en compte cette nouvelle évolution
Best effort … « On fait au mieux, comme on peut. Le livrable sortira quand il sortira »
« Best effort » annihile le concept d’engagement de l’équipe Scrum.
L’engagement, c’est une des 5 valeurs fondamentales de Scrum : lors du Sprint planning, l’équipe s’engage à atteindre l’objectif qu’elle s’est fixé, en livrant les US mûries et embarquées ENSEMBLE.
Le SM est garant de l’application de la méthode au sein de l’équipe. Il doit orienter, re-orienter au besoin, cadrer, re-cadrer … le Scrum doit être identifié dans l’organisation et légitimé par la hiérarchie. C’est pas juste une casquette qui traîne dans un coin et portée par untel ou untel.
Les US qui traînent de sprint en sprint, les US abandonnées au milieu du sprint, les US où on découvre en cours de Dev qu’elles ont des adhérences avec ceci ou cela … c’est tout sauf du Scrum.
Pour ce dernier point, avant d’embarquer une US de Build / Dev, on peut tout à fait faire une US d’étude d’impact où le livrable n’est pas du code mais une étude listant les impacts/adhérences et proposer 2-3 solutions pour régler le probleme
@Norbert merci pour explication. C’est vrai qu’encore beaucoup de choses à améliorer mais nous faisons de notre mieux pour mettre en place de bonnes pratiques. Toute l’équipe est motivée, et on ne demande qu’on nous montre le bon chemin à suivre. Ton expertise est précieuse pour nous !
Est-ce que tu pourras développer ton dernier point concertant US d’étude d’impact s’il te plait?
Si je comprend bien le cas que tu as vécu, tu as découvert pendant le développement d’une fonctionnalité (appelons la « item1 ») que celle-ci n’est pas complète.
Ce cas peut être traité simplement en finissant le développement de l’item1 qui doit respecter le concept INVEST. En écrivant un « item2 » qui vient compléter l’item1, car ici tu parles de nouveaux attributs en BDD ça ne remet donc pas en cause ce qui à été fait avant. On aurait item1 : « situation standard » et item2 : « situations exceptionnelles », c’est donc bien complémentaire.
Par contre si cela remet fortement en cause les développements de l’item1, effectivement il ne faut peut être pas investir trop dessus, en tous les cas ça sera du temps de perdu, soit a développer quelque chose qui sera remodifé, soit en arrêtant le développement et en repartant de 0 sur la conception de la fonctionnalité. Dans certains cas ça peut être compliqué de trancher sur la meilleure approche a prendre…
De toute manière tant que vous êtes dans une approche d’amélioration continue, c’est le principale car si vous avez un doute vous pouvez prendre une solution de façon arbitraire et voir à posteriori si c’était la bonne approche. Jusqu’à trouvé l’approche qui correspond à votre façon de travailler.
Ah ? Même si cette découverte met en péril le sprint goal ?
D’accord avec le premier, par contre les deux autres c’est faux. J’ai aucun problème avec l’abandon d’un SBI qui mettrait en péril le sprint goal. Et pour ce qui est de l’adhérence, perso, non seulement je n’ai pas de boule de crystal, donc même si on peut les réduire au maximum, c’est inconcevable de ne pas ‹ découvrir des adhérences ›, mais en plus, je vois aucune référence à ça dans le scrum guide.
Et encore une fois, dépendance découverte à mi-sprint = annulation pure et simple. Arrêtez les frais parce que le goal sera pas atteint de toute façon.
En pratique, ce qui peut être fait est le comportement suivant :
On découvre qu’un SBI (Sprint Backlog Item) ne contribuent plus à l’objectif de Sprint pour X raison.
On place cet élément dans une colonne « Corbeille ». Si cela invalide le PBI (Product Backlog Item) correspondant, alors ce PBI passe aussi à la « Corbeille ».
Lors de la Sprint Review, on est transparent sur l’état de cet élément.
L’élément pourrait revenir dans un Backlog, dans une autre forme ou pas.
Le board de l’équipe est le radiateur d’information.
La différence principale est la suppression du passage des SBI non terminé d’un Sprint à l’autre.
Le Kanban comportait un maximum de 7 éléments ordonnés dans la colonne « Todo ». Parmi les éléments la majorité étaient des sujets qui pourrait correspondre à un « objectif de Sprint » à lui seul. Le reste des éléments étaient dans une réserve, non ordonné.
Pour le reste, rien n’empêche de faire des évènements réguliers ou même à la demande.
Voici la dernière version du board
L’expérimentation de l’ajout d’une colonne dédiée « code review » était politique, à la demande du management. À la prochaine version la colonne « En cours » repassera à une limite de 1.
Best effort … « On fait au mieux, comme on peut. Le livrable sortira quand il sortira ».
Où les pré-requis à Scrum n’existe pas, même un objectif de Sprint.
Je suis d’accord que cette affirmation n’a aucun sens.
Affirmation véridique
J’appellerai plutôt cela une hypothèse pensée d’après les informations partagées dans les messages précédant.
Comme toutes hypothèses, ceux qui font ont la liberté de choisir de l’expérimenter ou pas.
Conscience
J’ai conscience que ma façon de parler/écrire peut-être assez tranchante. Cela peut donner le sentiment que je veux partager ma vérité.
Je vous invite à voir mes écrits, non pas comme une opinion statique, mais comme un flux de pensées attrapées en plein milieu de leur mise à jour.
Pour revenir à la question d’@Hanh_NGUYEN, ça m’est arrivé d’avoir des story en standby sur un vieux projet legacy (blocage technique, attente de réponse client, changement de priorité, etc…)
Pour le sprint backlog, je préfère ne pas y toucher pendant le sprint. Si la story disparait en court de sprint, on risque d’oublier à la rétro que quelque chose s’est mal passé. C’est un des grands principes du Toyotisme: les taches (d’huile ^^) doivent être visible. Si on s’est planté, il vaut que ça se voit.
Par contre, niveau product backlog, l’important est de ne pas garder une story qui n’est plus prioritaire:
Soit la priorité a juste un peu diminué et on prévoit quand même de la faire dans 1 ou 2 sprints.
Soit la story arrive en bas du backlog mais « Tu comprend on sait jamais, on la laisse ouverte peut-être qu’un jour on la finira parce qu’on a passé du temps dessus blablabla… ». Dans ce cas ma stratégie est de tirer à vue.
Garder des story ouverte pour rien a beaucoup d’effets néfaste:
Ca démotive de se dire qu’on n’a jamais le temps de la finir
Ca alourdi le backlog: Les story importante sont noyé dans les stories historique
Ca donne l’impression que c’est normal de commencer un truc sans le finir.
Idéalement, le product backlog te donne une visibilité sur quelques mois, un an max. Si tu as l’équivalent de 10 ans de boulot dans ton product backlog, tu es complètement noyé et tu perds la visibilité court/moyen terme.
