Estimation des tâches techniques

Communauté Scrum Life
1

Bonjour,
Nous sommes des novices sur Scrum et nous allons démarrer un nouveau projet où toute l’équipe est concernée. Nous sommes habituellement sur plusieurs sujets en même temps, nous n’avons jamais trouvé de solution jusqu’à présent et ça semble être le bon moment.
Nous nous sommes inspirés des vidéos Scrum Life et nous avons UserStory, DoD et un Sprint Goal. Nous n’avons pas d’expérience sur notre vélocité, on va la construire, et pour les premiers sprints se sera plutôt au ressenti.
Il y a l’étape de création des tâches qui n’est pas encore très claire. Nous avons compris qu’il fallait les créer durant le Sprint planning mais on ne sait pas si une estimation en H/J doit être précisée sur chaque tâche ?
Apporte t-elle (l’estimation) quelque chose en plus que le fait d’avoir pensé la tâche associée comme très petite dans le temps (qu’elle doit durer max 1ou 2 jours) ?

D’avance merci !

2

Bonjour et bienvenue !

L’estimation des tâches n’est pas une fin en soi (c’est l’erreur que beaucoup de monde fait).

Un sprint commence par le sprint planning, durant lequel :

  • On détermine un objectif de sprint pour ce sprint.
  • On affine la DOD si nécessaire.
  • On élabore un plan provisoire (liste de tâches) pour atteindre l’objectif d’ici la fin de sprint.

Dans ce contexte, estimer la durée des tâches est un outil qui peut aider l’équipe à déterminer la crédibilité du plan.

Beaucoup d’équipes estiment la complexité des tâches en points et l’utilisent comme base de calcul de la vélocité en divisant ensuite par la durée du sprint. En pratique, ça revient à diviser la durée théorique par la durée réelle. Cela permet seulement d’évaluer la précision des estimations des développeurs, certainement pas la qualité ou la performance de leur travail.

1 « J'aime »
3

Bonjour,

je ne sais pas ce qui est mis concrètement derrière le terme tâche technique. Quand on parle de tâche technique dans notre équipe on est sur la question de changement de version Angular ou DotNet, des trucs plutôt longs que l’on découpe en phases que l’on applique sur plusieurs sprints…

Si tu parles des tâches liées aux US (coder le front, créer le service en back, etc.), ces tâches permettent de « planifier » la réalisation en anticipant l’enchainement ou l’ordonnancement des tâches à réaliser. En découpant les étapes de réalisation, ça permet de se rendre un peu mieux compte de l’effort et (éventuellement) du temps nécessaire à la réalisation d’une US.

Pour moi le nombre de tâches à faire a plus d’impact que la durée des tâches.
Pourquoi ?
=> Si tu découpes un US en 10 tâches, ça peut être le bordel : plein de branches, de commits, de PR, d’interactions, de tests pour clôturer l’US
=> Si tu découpes ton US en 2, en respectant les critères INVEST, tu auras 5 tâches techniques x 2 au pire, car en général tu as l’effet d’échelle avec une première US qui a plus de tâches et la seconde qui n’a plus les tâches déjà traitées avec la première US. Au final, tu livreras plus vite des 2 US qu’une seule englobant tout.

Le temps de réalisation n’est donc pas linéaire.

L’important c’est de découper finement l’US en tâches « techniques » puis de redécouper l’US si besoin pour optimiser les flux à venir.

Si tu fais bien ce travail et que tu priorises ensuite les tâches qui sont absolument indispensables au sprint goal, et que sur ces tâches indispensables tu t’interroges sur le temps nécessaire à les réaliser, tu pourras assurer que ton sprint goal puisse être atteint car tu ne comptes pas t’attarder sur des tâches sans intérêt stratégique et que tu te comptes te focus sur ce qui te permettrait d’atteindre ton objectif.

Quand tu fais ça l’estimation n’a plus d’importance

Puisqu’on le répétera jamais assez, l’important est d’atteindre l’objectif, pas de réaliser toutes les tâches sélectionnées.

1 « J'aime »
4

Hello, en phase avec les autres avis
le découpage en tâches et estimation de celles ci est une vieille version du scrum guide, ce n’est plus d’actualité
je te conseille relire et faire relire à ton équipe le scrum guide actuel, il est très court et relativement simple 2020-Scrum-Guide-French-2.0.docx (scrumguides.org)

quand tu parles de tâches techniques, c’est des tâches pour réaliser une US ? ou c’est une TS comme le décrit Nicolas (changement de version angular, dotnet)
chez nous, la Technical Story est un besoin qui n’est pas créé par le métier, mais par l’équipe de développement pour identifier la dette technique et la résoudre dans les sprints.
par définition, une dette technique ne change pas le fonctionnel du produit.

une tâche technique pour réaliser une US, tu peux créer des sous tâches pour suivre l’avancement si cela est nécessaire, personnellement, je l’évite et si c’est nécessaire, on en crée. je ne mets pas en place une solution qui répond à un problème que nous n’avons pas forcément, surtout que ce n’est pas écrit dans le guide :wink:

concernant les TS donc, je milite pour faire la même chose que pour le métier, l’équipe de dev doit prioriser les cartes, les découper pour qu’elles rentrent dans un Sprint, etc.
ce n’est pas facile à appliquer mais on le comprends mieux quand on demande au métier de faire quelque chose qu’on s’impose également.

concernant la vélocité, je préfère mesurer qu’estimer, car la mesure est exacte, factuelle, on peut observer son progrès au fil des semaines. Le débit par semaine peut t’aider pour ça

ça permet de dire que ton équipe a un rythme et si vous arrivez à découper les cartes (User ou Technique) en des choses d’une taille assez petite (ça rentre dans un sprint ou une semaine) tu vas devenir de plus en plus prédictible :wink:

5

Merci à tous pour vos réponses très éclairées.

Si tu parles des tâches liées aux US (coder le front, créer le service en back, etc.), ces tâches permettent de « planifier » la réalisation en anticipant l’enchainement ou l’ordonnancement des tâches à réaliser. En découpant les étapes de réalisation, ça permet de se rendre un peu mieux compte de l’effort et (éventuellement) du temps nécessaire à la réalisation d’une US.

C’est effectivement les tâches du style « Ajouter tel bouton à tel écran », « Implémenter le ws X », « Implémenter le test sur l’echec de synchro », … Nous avons l’impression, si la user story est bien définie et pas trop grosse, qu’il faut créer des sous tâches pour que chacun puisse se les attribuer et logguer le temps passé dessus. Mais quelles n’avaient pas de story point.

la Technical Story est un besoin qui n’est pas créé par le métier, mais par l’équipe de développement pour identifier la dette technique et la résoudre dans les sprints

J’aime bien cette approche. Ca reste une UserStory macro qui contient des tâches ?

une tâche technique pour réaliser une US, tu peux créer des sous tâches pour suivre l’avancement si cela est nécessaire, personnellement, je l’évite et si c’est nécessaire, on en crée. je ne mets pas en place une solution qui répond à un problème que nous n’avons pas forcément, surtout que ce n’est pas écrit dans le guide :wink:

Concrètement la UserStory se suffit à elle même sans avoir besoin de faire des sous tâches derrières ?

Encore merci pour vos réponses.

6

Un des aspects que ça soulève c’est qu’il existe parfois une distinction entre utilisateur et bénéficiaire.
Le bénéficiaire c’est encore un rôle différent du sponsor, la dynamique entre les 3 est parfois complexe.

C’est en particulier vrai dans les applications d’entreprises où un logiciel sert à la fois à guider et à contraindre les utilisateurs selon des règles qui sont au bénéfices d’un tiers au sein de l’organisation. L’exemple typique dans les ESN c’est le logiciel pour les imputations et les congés. L’utilisateur est le salarié ou le manager. Le bénéficiaire c’est le service comptable.

Ce qui nous intéresse dans Scrum c’est la maximisation de la valeur. Or, celui qui reçoit la valeur, c’est le bénéficiaire. Dans un contexte B2C la distinction n’existe pas : l’utilisateur agit pour son propre compte. C’est pour ça qu’on parle de « user » story. Mais en vrai, si on devrait parler de « beneficiary-story ». Mais bon, ça ferait BS qui est l’acronyme habituel de bullshit en anglais …

Et donc comme le produit est un logiciel, il y a des bénéficiaires qui sont autres que les utilisateurs : le DPO, le RSSI, le DSI, etc … Tous ces gens sont des parties prenantes qui ont des exigences pour le produit. La question c’est de savoir si on traite leurs exigences sous forme de PBI ou au niveau de la DOD.

Car par exemple, on peut parfaitement imaginer que la DOD indique :

  • Le logiciel utilise la dernière version LTS de dotnet

Ca évite de traiter cela comme des PBI qu’on peut donc planifier ou pas dans un sprint, mais comme un exigence qualité intrinsèque du produit, et donc d’un critère pour qu’une version devienne un incrément utilisable. A fortiori si la position de ces parties prenantes est forte et qu’elle est prête à s’opposer au déploiement d’une version de l’application si la version du runtime est obsolète.

7

Perso, je ne comprends pas l’utilité de suivre les temps aussi finement, ça devient du flicage, c’est malsain et hors cadre du scrum guide.
Toutes ces choses sont sorties du guide à cause de ces ecarts malveillants, ne vous forcez surtout pas de les remettre

8

Plus ou moins, d’un côté la User Story représente une dette fonctionnelle, un manque pour l’utilisateur, une idée
Et de l’autre, la Technicak Story représente une dette technique, une librairie obsolete, un OS qui ne serait olus supporté, de la dette de code (code smell) etc…

Je n’aime pas les taches pour les cartes, une carte est assez petite pour ne pas encore devoir la découper en sous tâches

Je trouve ça tellement réducteur de devoir décrire les choses à faire pour une user story et devoir les materialiser. Je préfères faire un example mapping de la carte, pour bien dire comment on va tester la carte, ça donne un nombre de regles et un nombre d’exemples, du coup, tu peux donner un avancement : j’ai fait 2 regles sur les 5. Il me reste un exemple pour la dernière règle.

9

Yes, exactement, après, tout est possible, mais autant decouper ton US pour qu’elle soit assez petite pour etre réalisée en une semaine.
Surtout pas de decoupage technique, toujours fonctionnel.

La video sur l’exemple mapping de la chaine scrum life peut t’aider