Unité d'estimation des heures dans l'outil Scrum

Question

J'ai appris Scrum et essayé un outil appelé Acunote pour l'utiliser. Ma question concerne deux domaines que j'ai pour chaque tâche. Ils sont "estimation" et "restant". Quelle unité dois-je utiliser pour ceux-là? Est-ce que j'utilise des points d'histoire? Qu'en est-il du reste? Par exemple, j'ai une tâche qui prendra 10 unités, disons. Je remplis le reste à la fin de la journée avec combien de "unités" je crois qu'il me faudra pour compléter?

Merci!

Answer 1

J'ai quelques suggestions pour vous:

• Si vous êtes nouveau point de presse; utiliser un tableau blanc et ne pas s'enliser dans la sémantique d'un outil particulier; cela entravera votre apprentissage et votre adoption. Brisez vos histoires suffisamment petites pour ne pas avoir à créer et estimer des tâches.
• Ne faites rien avec des heures, c'est une perte de temps à estimer à ce niveau.
• Brûlez les points de l'histoire.

Il est trop facile et courant pour les équipes de "penser" qu'elles sont sur la bonne voie car les tâches sont en cours de finalisation et de destruction. Ensuite, ils arrivent à la fin du sprint et constatent que 5 histoires sont toutes faites à 90% et rien n'est terminé. Si vous brûlez des histoires, vous êtes en train de suivre la valeur commerciale livrable et pas seulement une quantité arbitraire de développeur indésirable.

Answer 2

IMHO vous ne devriez pas utiliser restant pour les points SCRUM, parce que les points devraient être vraiment subjectif et vous ne pouvez probablement pas dire jusqu'où vous êtes allé. Je vous recommande de décomposer la tâche en tâches plus petites (celles-ci seraient les étapes dont vous avez besoin pour implémenter les fonctionnalités), puis de les estimer en heures. De cette façon, vous pouvez facilement suivre la progression de la fonction

Answer 3

Utilisez les heures pour l'estimation initiale et le temps restant. Les tâches sont généralement estimées en heures.

Vous pouvez utiliser le point de contrôle - ou n'importe quelle autre unité - pour estimer les éléments du carnet de commandes.

Answer 4

Comme toujours, mon premier conseil serait pas utiliser un outil lors de l'adoption/apprentissage Scrum (je commence à être fatigué de répéter la même chose encore et encore :). Au lieu de cela, commencez par la chose la plus simple qui pourrait fonctionner (une feuille de calcul pour le produit Backlog, un tableau blanc et des notes post-it pour le Sprint Backlog). La raison derrière cela est que vous voulez apprendre et maîtriser Scrum, pas un outil. Donc, ne laissez pas un outil vous dire comment faire Scrum et piloter le processus. Ensuite, en ce qui concerne la question, il y a deux écoles de pensée: 1. ce que Scrum dit en théorie, 2. ce que font certaines personnes dans la pratique.

En théorie, Scrum a deux niveaux d'estimation: un pour le travail (Tâches) à accomplir dans le Sprint actuel et un pour les Articles de Backlog de produit (PBI) plus éloignés. Au niveau du Backlog produit, les éléments (le «quoi» est en cours de construction) doivent être estimés dans les points Story/T-Shirt/Unit-less qui ont un faible degré de précision. Cette approche évite les pièges de la «paralysie de l'analyse» et reflète avec précision l'incertitude générale entourant le travail en question. Au niveau Sprint Backlog, les éléments sont répartis en tâches (le «comment» un PBI sera atteint) qui sont estimées en heures. Un schéma d'estimation distinct est approprié car les tâches décrivent un travail granulaire (généralement de l'ordre de quelques heures, jamais plus de 16 heures). En fait, Scrum recommande d'utiliser des «heures d'ingénierie idéales» pour les estimations au niveau des tâches.En pratique, certaines personnes n'évaluent pas en heures parce que les heures de combustion ne montrent pas de «vrais» progrès, ce qui n'est pas faux, et elles préfèrent brûler des points d'histoire (ce qui signifie vraiment qu'un article est fait ou non, c'est plus binaire).

Bien que je comprenne l'esprit de la dernière approche, je ne l'applique pas et je m'en tiens à la théorie. En fait, pour les raisons mentionnées précédemment, l'estimation en heures a du sens pour moi et je trouve qu'elle donne un meilleur "contrôle" du processus empirique Scrum pendant un Sprint (à la fin de chaque journée, vous devriez mettre à jour le travail restant estimé peu importe le temps passé et c'est plus facile avec les heures). De plus, je n'aime pas l'inconvénient d'avoir seulement de petites histoires (ce qui peut être vu comme un gâchis aussi) mais comme quand une équipe identifie clairement ce qui doit être fait dans un Sprint (c'est bon pour la transparence et aide le Product Owner doit également comprendre la quantité réelle de travail, en particulier les tâches "orientées qualité"). Enfin, je pense que vous pouvez éviter les pièges mentionnés par DancesWithBamboo avec des heures aussi. Restez vigilant et:

• Toujours se concentrer sur les plus importants PBI (et les tâches connexes) en premier. Portez une attention particulière aux tâches non finies, elles devraient continuer à bouger sur le tableau blanc (si vous utilisez des colonnes pour représenter des étapes comme par exemple "todo", "en cours", "à vérifier", "fait" "); une tâche non mobile est une odeur .
• Ne commencez pas un nouvel élément avant que le précédent ne soit terminé.

Donc, à mon avis, il est possible d'utiliser les heures et pour éviter le « rien fait » à la fin du syndrome Sprint. Utilisez simplement votre cerveau (Scrum et/ou n'importe quel outil ne le remplacera pas, heureusement pour nous). Cela dit, et si vous ne jetez pas votre outil, les questions à répondre sont les suivantes: qu'est-ce que vous voulez montrer sur le burndown (points ou heures selon que vous répartissez le travail en tâches ou non, Je vous ai donné mon point de vue) et quel champ Acunote utilise-t-il pour tracer le burndown (c'est-à-dire où dois-je mettre à jour l'estimation du travail restant)? Si vous choisissez des points et n'utilisez pas de tâches, il ne serait pas logique de mettre à jour le travail restant sauf si c'est totalement fait IMO (un PBI est fait, ou pas).

Answer 5

Je ne voudrais pas déranger avec reste. Une histoire ou une tâche est un booléen (soit fait soit pas fait). Dans notre équipe, nous avons commencé à n'accepter que les tâches qui devraient durer moins d'une journée. De cette façon, aucun membre de l'équipe ne devrait travailler sur la même tâche lors de deux mêlées quotidiennes consécutives. Le troisième jour sonne à coup sûr les cloches d'alarme! La fragmentation de la tâche est également facile et rapide, car elle ne nécessite pas beaucoup d'estimation. Est-ce moins d'un jour: OK, sinon le décomposer.