Les tâches techniques, pour quoi faire ? Découpage de User Story en taches

🎁 Le guide du Scrum Master compétent 👉 sl.run/siaGHw
Alors comme ça, vous ne faites pas de tâches techniques ?
Moi j'vous dis que c'est important, et j'vous explique pourquoi dans cet épisode de Scrum Life !
C'est également la première apparition du "Développeur junior" et de son doudou !
💜️ La communauté Scrum Life 👉 sl.run/10eCJN
----------
LIENS EN RAPPORT AVEC CETTE VIDÉO
- Présentation "Une semaine dans ma peau de Scrum Master" : • "Une semaine dans ma p...
- Scrum Life 7 à propos du Sprint Planning : • L'équipe n'arrive pas ...
- Le Scrum Guide, section "Sprint Planning" : www.scrumguides...
- Le Scrum Guide, section "Scrum Values" : www.scrumguides...
- Scrum Life 5 à propos du Definition of Ready : • Le Definition of Ready...
- Scrum Life 1 et 2 à propos du Burn-Down Chart : • Le Burn Down Chart - S... • Les Dérives du Burn-Do...

[@ScrumLife]

Découvrez toute la communauté Scrum Life ! 👉 sl.run/yecOhU

[@pwisshella_inprogress]

Super video !! Merci beaucoup !

[@ScrumLife]

Merci à toi ! Y'a-t-il un passage en particulier que tu retiens ? -- JP

[@damienlebris7119]

Encore une super vidéo. Merci. Bien pratiqué en tant que dev, j'avais adoré la partie conception en équipe par le découpage en tâche. On avait été même plus loin avec des DOD sur les tâches pour s'assurer de la qualité (TU done, couverture de code non detoriorée, ...) A l'inverse, je n'ai pas réussi à le faire accepter dans une mission délicate en tant que Scrum Master. Résultats : l'enfer avec le PO et une intégration des nouveaux entrants apocalyptique.

[@ScrumLife]

Merci beaucoup pour ce partage. Avec le recul, sais-tu pourquoi ces pratiques n'ont pas pris dans cette équipe ?

[@fun3000able]

Très bon ! je forme de la même manière (dynamique, expérience, humour, fermeté) et ça marche !

[@lutaseb]

Cette vidéo est juste géniale

[@ScrumLife]

Je suis d'accord, les tâches technique ne sont pas appréciées à leur juste valeur.

[@jimthouvenot1781]

Salut JP. Merci pour ton travail.

[@coach-okr]

Merci pour vos videos

[@carriernicolas]

Bonjour ! Tout d'abord, Merci pour cette vidéo (et toutes les autres, elles sont une mine d'information !). Ensuite j'ai deux questions. Faut-il "chiffrer" les tâches techniques (en strory points) ? Si oui, alors les points de la story sont comptés 2 fois et faussent les indicateurs (vélocité, charts...), non ? Quand faire les tâches techniques, durant le sprint planning ? Il ne risque pas un peu de déborder ? Encore merci ^^

[@ScrumLife]

Beaucoup d'équipes "chiffrent" les tâches techniques, mais pas avec la même unité que les éléments du backlog produit. En effet, les deux estimations ne servent pas à la même chose. - L'estimation des éléments du backlog produit servent à faire des prévisions au long court, par exemples de releases et surtout au-delà du prochain Sprint. On utilise de préférence une unité volontairement abstraite qui permet de simplifier la gestion de projet (les points), qu'on concrétise via une mesure factuelle (la vélocité). - L'estimation des tâches techniques sert à l'équipe de développement pour s'organiser au quotidien et détecter les points de blocage. On va là utiliser une unité concrète (Jours.Homme/Heures.Homme) qui permettra par exemple à l'équipe d'être confiante en Sprint Planning en se projetant sur le travail qui sera fait. Le but n'est cependant pas de rentrer dans une estimation détaillée à l'heure près, aussi une bonne manière de faire est de se forcer à choisir entre les valeurs suivantes : 0, demie-journée, 1 jour ou 2 jours -- à plus de 2 jours, il faut découper la tâche technique. Une encore meilleure manière de faire est de simplement s'assurer que chaque tâche fait moins de 1 jour : tout en limitant les problèmes liés aux estimations, c'est aussi un excellent moyen d'aider l'équipe à détecter les points de blocage -- chaque tâche faisant au maximum 1 jour, alors si un jour on déplace une tâche vers "en cours" alors le lendemain elle doit bouger vers "terminé" sinon il faut se poser des questions. Il est vraiment important de ne pas mélanger les deux unités. Quand on fait les tâches techniques, quand on "déroule" tout le travail à faire, il ne faut pas se projeter par rapport à l'estimation en points et se dire "oh là là on a estimé ça à 2, il faut qu'on ne passe pas trop de temps dessus" ou inversement "ah on est large, on a estimé ça à 8, c'est l'occasion de se faire plaisir". Il faut juste faire le travail bien, comme il faut. Pour l'équipe de développement, il vaut mieux oublier les points tant qu'on est dans le cadre du Sprint courant. À la fin du Sprint, on mesurera combien de points ont été faits et on mettra à jour la vélocité, sans biais. Oui, a priori on fait les tâches techniques durant le Sprint Planning, c'est justement un des buts et livrables de cette réunion. À nuancer tout de même : - L'équipe peut avoir parfois besoin de faire le découpage des tâches techniques en amont du Sprint Planning, sur certains sujets compliqués, où ils ne savent pas comment avancer. Par exemple, c'est le meilleur moyen pour l'équipe de déterminer si elle a besoin de faire une investigation technique en amont. Essayer de découper en tâches techniques peut être la première étape avant de partir sur un Spike. - L'équipe n'a pas à faire l'intégralité du découpage en tâches techniques en Sprint Planning. Elle doit en faire suffisamment pour pouvoir démarrer le Sprint, et elle continuera au fil de l'eau. - Une exception tout de même : lorsque l'équipe de développement a du mal à "s'engager" en Sprint Planning, ce qui est assez courant avec une équipe jeune, qui n'a pas encore l'habitude de travailler ensemble et sur ce produit, cela peut réellement aider l'équipe à faire le découpage en tâches techniques pour l'ensemble des éléments du backlog de Sprint. - Au final, c'est à l'équipe de développement de s'organiser au mieux pour réussir ses Sprints. Une approche possible pour faire de découpage en tâches techniques est la Design Review, une réunion où l'équipe échange sur l'architecture d'un élément du backlog et donc en définir les tâches techniques. Pour aller plus loin, divers Scrum Life sur ces sujets : - Utiliser les tâches techniques pour aider l'équipe à s'engager en Sprint Planning : kzbin.info/www/bejne/rn3EkGCrqcpoirc - Comment utiliser les estimations en point : kzbin.info/www/bejne/hIvblKSbnpqkf6c - Comment bien utiliser la vélocité : kzbin.info/www/bejne/gJTTiKSjZ5hgp6M - Le Burn-Down Chart (2 vidéos) : kzbin.info/www/bejne/oZrGenyErNqDq6s kzbin.info/www/bejne/Y6aUm6FrZ7Jma5I - La Design Review : kzbin.info/www/bejne/aHPVlmigaLiBoLc - Les Spikes : kzbin.info/www/bejne/l5XQd3WFrp2ed8k

[@carriernicolas]

@@ScrumLife Wow, quelle réponse ! Pour préciser la situation, à l'origine, je suis développeur et je me suis retrouvé Scrum Master parce mon chef part et que c'était l'une de ses multiples casquettes (PO, manager, dév...). Du coup, après (beaucoup) des lectures et (beaucoup beaucoup :) ) des visionnages de vidéos de Scrum Life, je retrousse les manches et j'essaye d'aligner nos pratiques sur un Scrum un peu plus, disons... orthodoxe :). Lors de la prochaine retro, je vais splitter l'équipe (17 dévs :/), poser la DOD, mettre en place la DOR qu'on vient de définir, réduire le sprint de 2 à 3 semaines... En gros, pas mal de changements en cours. Du coup, je pense dans un premier temps - juste pour le sprint qui vient -, ne faire que des US et détailler les tâches techniques seulement en commentaire, lors, ou en avant du sprint planning, avec potentiellement des ajustements en cours de sprint. D'ici au sprint suivant, j'essayerai de poser un peu plus les choses avec un type de ticket Jira dédié. L'équipe étant distribuée (US / France), on doit passer par des outils numériques et subir leur lourdeur... En tout cas, merci 1000 fois pour cette réponse, je vais re-visionner ces vidéos en les passant au prisme de ce sujet. Et surtout, encore merci pour vos vidéos !

[@ScrumLife]

Rassurez-moi, car j'ai quelques doutes suite à la formulation de votre message : - Les 17 développeurs ont bien été consultés dans la constitution des nouvelles équipes ? - Les 17 développeurs ont bien été impliqués dans la définition de la DoD, et ont signé leur accord ? - Idem pour la DoR ? - Les 17 développeurs sont d'accord pour essayer le changement de durée de Sprint ? - Ce sont bien les 17 développeurs qui détaillent les tâches techniques ? Et qui font les ajustements en cours de Sprint ? - Ce sont bien les 17 développeurs qui mettent à jour JIRA ? - Les 17 développeurs ont bien été consultés dans les évolutions de JIRA, puisque ce sont eux qui l'utiliseront ensuite ? Avec plaisir pour les vidéos ! Avec plaisir aussi pour échanger ici même dans les commentaires 😁 -- JP

[@carriernicolas]

@@ScrumLife Bonjour, Encore une fois merci pour toutes ces bonnes questions que j'ai dû me poser grâce à vous ! Tout d'abord, est-ce qu'il serait possible de continuer cette discussion ailleurs ? Elle devient de plus en plus intéressante mais j'avoue ne pas trouver youtube très pratique pour ça. Je viens tout juste de rejoindre le slack des agilistes (hier ^^), du coup est-ce que c'est une option ? Si oui, est-ce que je crée un channel dédié ? N'hésitez pas à me dire ici, ou voire, directement à m'envoyer un message sur slack. Pour vos questions : - Les 17 développeurs ont bien été consultés dans la constitution des nouvelles équipes ? Pas encore, pour l'instant, on a fait une réunion avec 2 des 3 managers (ceux qui font partie de l'équipe en tant que dév.), pour valider le principe, ensuite, je pensais proposer une composition des équipes lors de la prochain (et première) rétrospective et la discuter avec les dévs, tout en précisant que cette composition n'est pas figé et que chaque dév peut la remettre en question à n'importe quel moment en réunion, ou en 1 on 1 s'il / elle préfère. - Les 17 développeurs ont bien été impliqués dans la définition de la DoD, et ont signé leur accord ? Pas encore non plus :) c'est prévu pour la prochaine rétro, je veux essayer de la construire avec eux, ou mieux, que ce soit eux qui la construisent, on verra comment ça fonctionne. - Idem pour la DoR ? Non, elle a été définie lors d'une réunion avec 2 dévs, le PO, une stakeholder et moi-même. Après, je pense avoir été clair sur le fait qu'elle peut-être remise en question et ajustée. Mais peut-être que j'aurais pu / dû m'y prendre autrement ? - Les 17 développeurs sont d'accord pour essayer le changement de durée de Sprint ? J'avoue je ne voulais pas leur demander leur avis pour le passage de 2 à 3 semaines. Par contre, je voulais remettre sur le sujet de la durée du sprint lors de futures rétrospectives, en laissant la porte ouverte à tout, raccourcissement, comme rallongement. Ceci dit, rien n'est encore fait, je peux juste aborder le sujet lors de la rétro, mon principal problème est que nos backlogs, de sprint et global, sont de behemoths complètements ingérables et que j'espérais améliorer au moins le backlog de sprint, en terme de lisibilté, en jouant sur les deux tableaux : taille de l'équipe + durée du sprint, mais peut-être suis-je trop pressé :) - Ce sont bien les 17 développeurs qui détaillent les tâches techniques ? Et qui font les ajustements en cours de Sprint ? Pour l'instant, ça dépend, mais c'est un des buts visés par le changement que je voulais mettre en place : * la DOR spécifie que le ticket doit se limiter au "comportemental" et laisser le choix de l'implémentation aux dévs. Elle se met en place petit à petit :) * pour les ajustements, la plupart du temps, ce sont les dévs, par contre, il y a souvent trop de tickets qui rentrent par la fenêtre durant le sprint et je comptais sur la réduction de la durée pour limiter ça - Ce sont bien les 17 développeurs qui mettent à jour JIRA ? Ce devrait être le cas ? Je pensais que le PO devait gérer au moins les US ? En pratique, un peu tout le monde met les mains dedans, c'est le bazar :) mais au moins, pour les tâches techniques, ce sont principalement les dévs. - Les 17 développeurs ont bien été consultés dans les évolutions de JIRA, puisque ce sont eux qui l'utiliseront ensuite ? Pas encore, pour l'instant, les modifications prévues sont d'avoir un type de ticket pour les US, qui suivrait la DOR et la création d'un deuxième board pour la séparation en deux équipes. Encore une fois, 1000 mercis pour le temps que vous prenez pour me répondre.

[@ScrumLife]

D'une manière générale nous préférons les échanges en public, car ils peuvent alors servir à plus de personnes -- et le reste de la communauté peut également intervenir ! Le Slack Les Agilistes est définitivement une option, là aussi pas forcément besoin d'un channel dédié, il y a un channel pour échanger et cela permettra de tirer parti de l'expérience du reste de la communauté. J'en profite aussi pour mentionner qu'il existe un groupe WhatsApp dédié aux "VIP de Scrum Life" accessible à ceux qui nous soutiennent sur le Tipeee ! D'ailleurs message à toute la communauté : soutenez-nous sur le Tipeee 😁 ⮕ fr.tipeee.com/scrum-life