Hello les Scrum lifeurs
Mon ami m’a proposé une proposition de division du tableau Jira pour un sprint actif. Voici comment cela pourrait être formulé :
À faire : Cette colonne contient toutes les user stories liées à ce sprint.
Prêt : Le Product Owner (PO) est responsable de déplacer les tickets de la colonne « À faire » vers « Prêt » une fois que ces tickets contiennent toutes les informations et descriptions nécessaires, ainsi que les priorités.
En cours : C’est à l’équipe de développement de déplacer les tickets de la colonne « Prêt » vers « En cours ». Cette colonne contient les tickets sur lesquels l’équipe est en train de travailler.
Testé par le PO (facultatif) : Cette colonne contient les tickets prêts à être testés par le PO.
Terminé : Une fois que le ticket est entièrement prêt, il est déplacé dans cette colonne.
Avez-vous d’autres suggestions ou commentaires à apporter à cette proposition ?
La colonne ‹ Prêt › devrait pas exister. Si c’est pas prêt, ça part pas dans le sprint. C’est la meilleure façon de se bananer. Après, ce que ‹ prêt › veux dire, c’est à l’équipe de le définir.
Hmm… Je suis en phase, l’étape « prêt » ne devrait pas exister. On met les items du Product Backlog dans un Sprint quand ils sont prêts, ça n’a pas de sens de les mettre « prêts » pour des tickets déjà dans un Sprint. C’est une étape en trop, c’est du « gâchis » au sens Lean.
Et aussi c’est aux développeurs de dire quand c’est « prêt », surtout si c’est pendant un Sprint ! Ce n’est pas au PO de décider ça, car sinon on sort totalement de l’esprit de Scrum. Le Sprint Backlog appartient aux développeurs.
Normalement l’étape « prêt » serait à faire « en dehors » du processus du Sprint. Avec une étape de discovery / maturation / affinage (utilisez le mot que vous préférez ) pour rendre des items du product backlog « prêts » à être pris dans un Sprint Planning.
A faire / En cours / Terminé doivent être suffisants;
La validation, le testing et le déploiement doivent être couverts durant le en-cours (qui peut contenir d’autres colonnes au besoin - Kanban).
Si ce n’est pas livrable (ou livré) ce n’est pas terminé et ne sera pas présenté au client lors de la review.
Je rejoins mes 2 collègues pour le « Prêt ».
Les tickets peuvent contenir un status « A faire » et « Prêt » si ça aide l’équipe, mais le sprint board devrait commencer avec la colonne « Prêt ».
On peut aussi utiliser la notion de « Funnel ». C’est un pré-backlog où le PO peut balancer toutes les idées géniales qu’il a eut le matin sous la douche. Mais les tickets ne rentrent dans le backlog que lorsqu’ils sont prêts (ou au moins un minimum raffiné). Le Funnel peut être un board Jira séparé ou carrément un autre outil comme plus orienté roadmap comme Aha!.
L’idée est de ne pas polluer le backlog (et l’équipe de dev) avec des idées immatures ou obsolètes, afin de garder de la visibilité sur ce qui est vraiment important.
Aussi, c’est une bonne chose de faire tester le ticket par le PO avant de le passer à terminer. Trop souvent le ticket passe à Done et disparait des radars.
J’aurais plutôt dis que c’est une mauvaise chose parce qu’on fait un hand-off au PO, mais je pense qu’on en est pas encore là au niveau de la réflexion sur le process.
@Samuel_Abiassi En tant que membre d’une petite équipe, je joue le rôle de Product Owner (PO) et j’effectue des tests sur les tickets considérés comme terminés par l’équipe de développement avant de les présenter lors des réunions avec le client pour la démonstration. Lorsqu’une fonctionnalité ne fonctionne pas correctement, le ticket reste dans la catégorie « testé par le PO ». Voila l’utilité de cette colonne
L’utilité de cette colonne est de regrouper les tickets qui sont liés les uns aux autres et d’identifier ceux qui nécessitent probablement des retours de la part des clients avant d’être développés.
J’entends bien. Mon problème c’est qu’apparemment, ça n’a pas l’air de déranger l’équipe de développement que des choses qui ne marche pas partent en « démo »
POUR CLARIFIER : L’utilité de cette colonne est de regrouper les tickets qui sont liés les uns aux autres et d’identifier ceux qui nécessitent probablement des retours de la part des clients avant d’être développés.
Merci de nous proposer ce sujet de discussion @Mary_Bgh
D’abord, comme plusieurs ici, je pense qu’amener une demande dans un état « prêt à être développé » est une activité continue décorrélée du rythme des sprints, et qui a lieu en amont du sprint. Surtout si es échanges avec le client sont encore nécessaire. Attention cependant à ne pas tomber dans le piège de la préparation à outrance (ex: « Définition de Prêt » trop riche/stricte). On doit accepter qu’il subsiste une part d’incertitude ou de découverte durant le sprint. Cette « préparation » devrait avoir 2 objectifs selon moi : 1. avoir une compréhension commune de la problématique à résoudre / du bénéfice à apporter à l’utilisateur 2. s’aligner sur la solution qui devrait être implémentée.
Ensuite, bien que tout soit affaire de contexte, ma conviction est que les « tickets » ne devraient pas être testés par le PO. Un PO a bien d’autres choses à faire et bien plus importantes et utiles pour guider l’équipe dans la création du bon produit. Surtout, « testé par le PO » signifie « testé manuellement », ce qui a terme devient intenable. Les développeurs ont une grande responsabilité dans cette situation. Celle de créer un produit testable. La testabilité est une des propriétés d’un produit bien construit.
Pour te faire part de mon expérience actuelle par exemple : je coache une petite équipe Scrum (1 UX/UI designer, 2 devs, le PO et moi même). Nous partons d’un principe : le test fait partie du dev. Ecrire un test c’est en fait écrire une spécification. Et si nous ne pouvons pas spécifier un comportement il sera sans doute très difficile de l’implémenter, sans se tromper ou sans inventer. Nous nous concentrons donc sur l’écriture de spécifications exécutables et les pratiques de dev guidé par les tests (automatisés donc). Pour autant, notre Définition de Fini inclut une forme de vérification du PO. Elle est centrée sur l’utilisabilité, l’exploration (cf. Agile Testing Quadrant). Ensuite nous déployons sans attendre sur un environnement à disposition de notre client. Nous l’invitons alors à utiliser (pas tester!) le produit et nous donner du feedback.
Ces changements d’approche ne s’opèrent pas du jour au lendemain, et ils demandent des compétences, mais il existe de nombreuses ressources ou accompagnants disponibles pour qui souhaite adopter de telles pratiques.
Arpenter le chemin est plus important que d’arriver à destination.
@Mary_Bgh Quel est l’état actuel, et les précédents ?
À mon avis, la destination serait d’avoir une WIP limite de 1 sur l’« En cours ».
Donc 3 colonnes est la seule configuration qui respecte cette contrainte.
Ici, je ne parle pas des tâches techniques.
Il ne faut pas oublier la validation qualitative et quantitative des hypothèses, qui a lieu après la mise à disposition à l’utilisateur final. Cela peut ajouter au moins une autre colonne.
À faire
En cours de réalisation | WIP limite 1
Validation qualitative et quantitative à ce moment, c’est à disposition à l’utilisateur final. Interview utilisateurs. Suivi des métriques.
Terminé avec les états « validé » et « annulé »
Ceci est un mensonge, car ça dépend toujours du contexte du produit.
Drôle d’idée la colonne prêt
Je rejoins mais confrère là dessus (ça claque les confrères )
On n’a pas de colonne Teste par le PO
Les gars ont voulu une colonne Delivered intégration et une autre Delivered preprod
On interagit avec les devs en pour voir en inté puis vérifier en preprod en mode tests utilisateurs, bout-en-bout voire exploratoire
Des qu’un feedback émerge, un nouveau ticket repart dans la colonne todo sur la même ligne de PBI et suit le même cycle
Dans le cas contraire, C’est done quand on n’a plus rien à dire et que ça vient compléter l’incrément
Je rejoins les réponses précédentes, 3 colonnes « A faire », « En cours » et « Terminé » devraient normalement être suffisantes pour gérer le sprint backlog, mais s’il y a besoin de préciser certains cas (par exemple un blocage, ou une attente de précision de la part du PO) j’utilise les couleurs de cartes.
Une équipe auto-géré décide ensemble, j’expose le problème à l’équipe (existe-il ?)
S’il existe, je prend l’avis de mon ami et le propose à l’équipe qui construit une solution, la teste et la revoie régulièrement.
Une de mes équipes n’utilise pas la vue car elle n’en a pas besoin. C’est juste du gaspillage de temps de déplacer des tickets ou devoir les montrer au chef qui dit si c’est bien ou pas.
@Mary_Bgh , je comprend que c’est du scrum framework (et non Kanban framework).
Tu souhaites utiliser une vue Kanban durant l’exécution du sprint.
Les Sprints sont au cœur de Scrum, où les idées sont transformées en valeur. (extrait du scrum guide 2020)
Je t’invite à clarifier ce point avec ton équipe. au moment de construire ta vue.
@Samuel_Abiassi Parfois, lors des réunions de stand-up, il arrive que l’on identifie un scénario manquant dans la rubrique prévue pour le sprint en cours, et qui n’a pas été abordé dans le backlog ni envisagé par le client.
@laurent.speyser je vous remercie énormément pour votre retour si enrichissant .
Pour le test fait par le PO , ce n’est pas un test technique mais plutôt en tant du coté user expérience , car parfois le développeur échappe quelques fonctionnalités ou bien quelques détails .
) pour rendre des items du product backlog « prêts » à être pris dans un Sprint Planning.
)