Discussion :

[laclac]

Bonjour,

En scrum, on décompose un projet en story, qu'on estime en point.
On met les story dans des sprints, en fonction de la velocité.
Et on décompose les storys du sprint en taches.

Question:
Si on met les story en fonction de leur point et de la velocité, à quoi sert d'estimer les taches en heure/j ?

Car de toute façon, le total des heures doivent finalement, forcement correspondre à la durée du sprint si on l'a remplit au niveau point.
Limite donc une conversion point = x heures pourrait etre possible.

Merci d'avance de votre remarque

[Drawingrom]

Bonjour,

En scrum, on décompose un projet en story, qu'on estime en point.
On met les story dans des sprints, en fonction de la velocité.
Et on décompose les storys du sprint en taches.

Normalement, il faudrait estimer les tâches pour en tirer l'estimation de la story et savoir combien de point tu vas réaliser dans le sprint.

Avoir une estimation en h/jour pour les tâches et en points pour les stories n'est pas cohérent : il faudrait faire l'un ou l'autre. J'imagine que dans votre cas, les tâches ne sont pas en visibilité du client (ou product owner). Peut-être est-ce une contrainte de gestion de projet où un reporting à la tâche en heures ou jours peut être demandé.

[Luckyluke34]

A l'origine, la plupart des équipes Scrum mesuraient l'avancement de leur sprint et sa projection dans le futur non pas avec le nombre de story points abattus mais avec le reste à faire des tâches.

Dans ce mode, le fameux burndown n'affiche donc pas des points mais des jours-homme (ou heures, etc.) restant à faire. Lors du Daily Scrum, chaque membre de l'équipe peut mettre à jour (ou clore) sa tâche en cours en indiquant le reste à faire dessus. Cela permet de calculer le burndown juste après le daily scrum.

Au fil du temps, un certain nombre d'équipes sont passées sur un mode "sans tâches" et se sont mises à mesurer la progression du sprint uniquement en story points (= nombre de user stories abattues) ce qui est tout autant concevable puisque la user story est l'unité de base de valeur métier produite, et tant qu'on a pas finie toute la user story (= toutes ses tâches), on n'a pas réellement avancé...

Car de toute façon, le total des heures doivent finalement, forcement correspondre à la durée du sprint si on l'a remplit au niveau point.

Non, dans le mode "avec tâches" le nombre de story points d'une US et le temps estimé des tâches qui la composent sont deux valeurs sans lien, estimées durant deux phases différentes du sprint planning.

A la sortie du sprint planning, on peut donc tout à fait se retrouver avec un nombre total de story points qui "rentre" dans la vélocité de l'équipe (ex : vélocité prévue : 50 points, total des US du sprint : 48 points donc ça passe) mais une somme totale des temps des tâches qui dépasse la dispoinibilité de l'équipe (ex : total des tâches de dev = 40 jours/homme alors qu'on n'a que 30 jours/homme de disponibilité).

Il faut alors retirer des user stories du périmètre du sprint pour "faire rentrer" toutes les tâches.

A noter qu'avec le temps, la vélocité de l'équipe s'affine, les estimations en story points sont de plus en plus homogènes et fiables donc cette disparité entre US et tâches tend à s'estomper.

[lolpapa]

Si si, l'estimation en heures est utile, intéressante voir nécessaire.

Il faut bien comprendre qu'une user Story est une vue "métier" pas technique. Pour réaliser ce besoin métier, les développeurs vont devoir réaliser un certain nombre de tâches "techniques" et leur coller des story point n'a aucun sens.

Les story point son utilisés pour les user story et uniquement pour la planification relative du sprint (et donc le calcul de la vélocité). Je rappelle que cette mesure est approximative et on veut qu'elle le reste. Donc ici des heures n'auraient aucun sens d'autant plus que ce serait certainement faux.

Les heures sont utiliées par les dev, pour quantifier le temps qu'il leur faut par tâches. Les heures n'ont effectivement aucun intérêt pour les PO mais estimer une tâche en story point n'a aucun sens puisque le story point est une valeur relative approximative.

En suite, on s'en fout un peu de savoir si le nombre d'heures totales match avec les story point ou pas.

Du point de vue PO, à la fin du sprint, on sera dans les clous prévu ou pas.
Du point de vue dev, je sais que je dois pouvoir faire en un our deux tâhces estimées à 4h, donc je ne devrais pouvoir être plus précis lors du suivi fait via le daily (stand-up)

Ce sont donc deux mesures complémentaires mais pas utilisées par les mêmes personnes et pas pour les même raisons.

J'espère que ça aide un peu

[Husqvarna]

Hello,

Tu as reçu de bonnes explications jusque là. Fais attention toutefois quand tu estime en SP de ne pas penser en heure dans ta tête, sinon tu vas tuer la vélocité sur le long terme.

regarde la 2ème partie de ce poste "Continuer de donner une valeur temporelle au Story Point":
http://www.iteration.info/fr/calcul-...es-classiques/

[Drawingrom]

Bonjour,

regarde la 2ème partie de ce poste "Continuer de donner une valeur temporelle au Story Point":
http://www.iteration.info/fr/calcul-...es-classiques/

J'ai un peu de mal avec cet article. Si les story points représentent la complexité d'une story pour l'équipe, elle reste corrélée avec le temps nécessaire à sortir une story. Après, chacun peut trouver son coef entre temps et story points.

Dans l'article, il est dit qu'une story estimée à 8 story points à l'année 1 sera toujours estimé à 8 story points à l'année 2. Pour moi, ça envoie le message au PO que l'équipe n'a pas gagné en productivité pour ce type de story.

En fait, je pense que la vélocité doit être fixe. Montrer qu'on est plus productif en présentant une meilleure vélocité parce qu'on n'a parce qu'on base les estimations en US sur les sprints passés me parait malhonnête.

Je suis finalement assez fan de l'estimation en jours idéaux, tu peux ensuite bosser sur l'amélioration du focus factor, te demander pourquoi tu ne produit que 4h par jour, trouver ce que tu peux faire pour permettre à l'équipe de se concentrer plus sur sa réalisation.

[Husqvarna]

Bonjour,



J'ai un peu de mal avec cet article. Si les story points représentent la complexité d'une story pour l'équipe, elle reste corrélée avec le temps nécessaire à sortir une story. Après, chacun peut trouver son coef entre temps et story points.

Dans l'article, il est dit qu'une story estimée à 8 story points à l'année 1 sera toujours estimé à 8 story points à l'année 2. Pour moi, ça envoie le message au PO que l'équipe n'a pas gagné en productivité pour ce type de story.

En fait, je pense que la vélocité doit être fixe. Montrer qu'on est plus productif en présentant une meilleure vélocité parce qu'on n'a parce qu'on base les estimations en US sur les sprints passés me parait malhonnête.

Je suis finalement assez fan de l'estimation en jours idéaux, tu peux ensuite bosser sur l'amélioration du focus factor, te demander pourquoi tu ne produit que 4h par jour, trouver ce que tu peux faire pour permettre à l'équipe de se concentrer plus sur sa réalisation.

Tu parles d'une chose différente si tu estimes en jours idéaux, ce n'est pas des StoryPoints et donc ce n'est pas une vélocité. Le story point doit être une valeur abstraite non basée sur le temps, c'est la base même de la méthodologie.

[Drawingrom]

Le story point doit être une valeur abstraite non basée sur le temps, c'est la base même de la méthodologie.

Et comment définis-tu ton montant de base en story point, celui que tu utilises comme référence pour chiffrer tout le reste de tes story ? Tu te dis "oulà, ça a l'air compliqué mais il peut y avoir des trucs plus simples, alors on va dire que ça fait 5 points" ?

Les SP essaient d'abstraire la mesure en temps mais est de toute façon lié au temps que tu mets pour la réal. Ton sprint est fatalement borné.

Utiliser des valeurs type membre de la suite de fibonacci a pour but de contrebalancer l'incertitude de chiffrage pour les items longs. Je le fais même quand je chiffre en jours.

Tes SP sont forcément une image de ton temps de réalisation.

[Husqvarna]

Justement tu dois par exemple la comparer à autre chose que du temps, tu peux utiliser plusieurs techniques comme comparer à un ordre de tâche connu.

Exemple:
1SP = réalisation d'un nouveau champs sur l'interface graphique avec le crud.
2SP = réalisation d'une nouvelle table sur le datawarehouse
3SP ...

Je reprends aussi ce que tu as dit sur la vélocité. Pour toi elle doit être toujours idem, en fait il faudrait tendre à l'augmenter (raisonnablement) au fil du temps. Le but est de suivre l'évolution de ta vélocité dans le temps, exemple on refait tout le logiciel d'un vieux Cobol en Windev. En mesurant de manière relative tu vas baisser ta vélocité dans les premiers sprint (ton équipe faisait du cobol et est en phase d'apprentissage), puis remonter graduellement à un moment tu vas même pouvoir sortir "ce sprint on est au même stade que connaissance/réalisation qu'avant" et plus tard voir que ton team est plus rapide avec la nouvelle techno.

Si tu mesures en heure tu vas juste mesurer que 2 semaines à x personne à x heures par jour ça fait ça Y heures, le plus ou le moins obtenu ne sera que le degré d’incertitude de l'évaluation ou des blocage.

[Luckyluke34]

Ah, l'éternel débat sur les Story Points J'ai l'impression que chacun a une définition légèrement différente et les utilise à sa manière.

A mon avis, il n'y a pas de vérité avérée, mais je trouve une approche intéressante, c'est celle de Mike Cohn. Selon lui :

• Les Story Points ne mesurent pas une complexité mais un effort requis pour abattre une User Story. Ex : dans une équipe de 2 personnes, un enfant de 10 ans et un chirurgien, la US consistant à coller 1000 timbres (peu complexe) et la US consistant à faire une opération de chirurgie du cerveau (très complexe) auront le même nombre de Story Points.

• On n'utilise pas les Story Points et la vélocité pour le Sprint Planning mais pour des projections de plus long terme.
  
  Lors du Sprint Planning, on ne se demande pas "combien de SP rentrent dans ce sprint étant donné notre vélocité ?" mais on sélectionne une portion du backlog et on découpe en tâches qu'on estime en heures ou jours, et on regarde si ça rentre dans le temps du sprint. En effet, l'estimation en heures/j est la plus précise et la plus adéquate à utiliser à ce moment là (cela répond à la question d'origine de laclac).
  
  En revanche, quand le client nous demande quand telle ou telle grosse portion du backlog sera finie, on regarde la somme des points des US correspondantes et on projette en fonction de la vélocité moyenne.

• Du coup, on évite tous les débats du genre "Faut-il reporter tous les Story Points d'une US non terminée d'un sprint sur l'autre ?", "Faut-il réestimer les US"... car cela importe peu pour une estimation à long terme et à grosses mailles.

http://www.mountaingoatsoftware.com/...not-complexity
http://www.mountaingoatsoftware.com/...print-planning
http://www.mountaingoatsoftware.com/...s-the-question

Sinon, je pense qu'on sera tous d'accord pour dire que les Story Points sont une mesure relative : si on prend une seule US, c'est un chiffre abstrait et inutile. Si on prend 2 US, on commence à avoir une idée de l'effort relatif nécessaire pour compléter l'une par rapport à l'autre. Si on prend 3 US, on peut encore affiner notre jugement. Etc.

Pourquoi est-ce important ? Car le Product Owner, quand il priorise des items du backlog, ne regarde pas chaque US dans l'absolu mais les met en regard les unes avec les autres et pondère leur importance en fonction de la valeur métier qu'elles apportent vis à vis du "coût" en Story Points.

[crystina]

Salut ;
Comment determiner le nombre de release et le nombre de sprint pour chaque release et les user stories
Merci d'avance

[Drawingrom]

Bonjour,

Vous déterrez un peu le topic mais pourquoi pas .

L'important au début (premiers sprints) c'est d'estimer les stories les plus prioritaire et d'y associer des points ou des nombres de jours ou d'heures et d'estimer combien de stories l'équipe pourra embarquer dans le sprint. Les premiers sprints réalisés vous donneront la vélocité de l'équipe (la quantité de boulot réalisée par sprint).

Pour la durée des sprints, c'est à vous de voir. Le plus court est le mieux.

Ensuite, le nombre de sprints par release et le nombre de releases, c'est au client de voir, cela dépend du nombre de mise en prod qu'il a envie de faire, de sa capacité de recette, de son time to market, etc...