Comment travailler des tâches intactes dans un sprint Scrum? [fermé

Question

Je suis le Scrum Master d'une petite équipe de 4 développeurs. Le projet sur lequel nous travaillons a beaucoup de tâches que nous n'avons jamais accomplies auparavant et ne pouvons pas facilement estimer lors d'une réunion de planification de sprint. Quelle est la meilleure façon pour moi de gérer un sprint avec cette incertitude? J'ai du mal à terminer un sprint avec un produit potentiellement relemable. J'ai également du mal à planifier des sprints lorsqu'il y a beaucoup de tâches de longueur inconnus.

Answer 1

Je ne sais pas quel est le terme dans Scrum, mais dans la terminologie des utilisateurs, vous feriez un "pic", qui est essentiellement une très courte période de recherche sur le sujet afin que votre équipe puisse estimer la tâche au fin de la pointe.

Exemple:

Histoire:

L'analyste souhaite être en mesure de revoir les données financières dans les graphiques circulaires.

Votre équipe n'utilise aucun outil de cartographie, vous devez donc savoir combien de temps il faudrait pour construire quelque chose comme ça. Ou peut-être à la place, vous pouvez investir dans des outils tiers et intégrer un ensemble d'outillage avec votre application.

Vous feriez un pic pour rechercher ces sites et trouver des estimations sur eux, puis décider de quelle voie prendre.

Answer 2

Sont les «tâches» des choses que quelqu'un dans le monde a faites auparavant, ou sont-elles tout simplement nouvelles dans votre équipe. Je suppose que le plus tard. Si tel est le cas, ce que vous trouvez, c'est que vous n'avez pas l'expérience nécessaire sur votre équipe pour résoudre le problème. Ainsi, vous développerez cette expérience au fur et à mesure. Tout cela signifie que la complexité de vos histoires est plus élevée. Dans les deux premiers sprints, vous pouvez marquer certaines des histoires à 13 ans, puis plus tard, ils deviennent 8s parce que vous avez ensuite les connaissances dont vous avez besoin.

Vous n'avez pas besoin de savoir comment faire les histoires pour les estimer. Il vous suffit de les en faire moins en raison de votre écart d'expérience.

J'aime réserver des "pointes" (oui, c'est le terme utilisé dans Scrum) pour tenter de résoudre des problèmes de domaine commercial qui n'ont pas de solution connue. Pas pour que l'équipe fasse la formation.

Answer 3

Si vous avez vraiment besoin de faire des recherches pour obtenir une bonne estimation, vous pouvez faire la recherche en tant que tâche en soi, ou la mettre de côté et la faire (par quelqu'un) avant la planification du sprint.

Généralement, je pense que si vous ne pouvez pas obtenir une bonne estimation, vous devriez soit opter pour une mauvaise estimation (c'est-à-dire une supposition sauvage), soit vous devriez faire du cale un sprint. Après cela, vous aurez soit une solution faite, soit vous aurez un meilleur compter pour que vous puissiez l'estimer ou le décomposer en sous-tâches pour le prochain sprint (ou un sprint ultérieur).

Answer 4

Voulez-vous vraiment dire des tâches ou parlez-vous des articles du backlog de produit (PBIS)? En fait, j'ai du mal à croire qu'une tâche n'est pas estimable. S'ils ne le sont vraiment pas, ils sont très probablement trop gros (les tâches ne devraient pas dépasser 16h, ce qui est déjà énorme).

Si vous parlez de PBIS, la situation que vous décrivez est assez surprenante et si théoriquement ne se produit pas. Dans le pire des cas, attribuez-leur simplement un nombre élevé de points d'histoire, cela signifie précisément qu'il y a beaucoup d'incertitude sur eux. Mais, parce que les PBI prêts pour un sprint ne devraient pas dépasser la moitié de votre vitesse (ou vous metterez trop de risques sur votre sprint), la façon évidente de résoudre cette situation est de diviser ces éléments en petits morceaux qui peuvent Inclure l'exploration. Mais la partie importante est de garder les choses dans le temps, même (ou surtout) de la R&D. Gardez à l'esprit qu'avec Scrum, tout est dans le temps.

En d'autres termes, pour réduire l'incertitude, décomposer les choses en choses plus petites (que ce soit des éléments ou des tâches)!

Answer 5

Si les tâches ne semblent pas estimables, je pense que la meilleure approche serait de décomposer ces tâches en tâches plus petites que vous pouvez estimer. Cela pourrait prendre plusieurs itérations, mais vous trouverez probablement un pseudo de conception pendant que vous y êtes. Joel mentionne cela dans l'un de ses des articles.

Answer 6

Divisez la tâche intacte en une tâche pour supprimer l'incertitude et "le reste". Retirez l'incertitude avec des tests de preuve de concept ou des solutions de pointes. Soit planifier les pointes de ce sprint et le reste de l'œuvre suivante, soit retarder le début du sprint pendant une semaine de dopage.

Answer 7

Nous ne savons souvent pas assez pour décomposer une histoire en tâches. Nous avons une période de découverte avant de savoir quelles seront les tâches. Les "pointes" semblent difficiles à gérer. D'une part, vous ne pourrez peut-être pas chronométrer la période de découverte. Deuxièmement, je ne peux pas planifier efficacement un sprint sans savoir combien de temps une histoire prendra.

On dirait qu'une autre option consiste à faire le pic dans Sprint 1 et les tâches de Sprint 2. L'inconvénient est qu'il semble que le processus oblige une rupture contre nature du travail. Pourquoi découvrir cette semaine, puis attendre un certain temps avant de commencer le travail.

Answer 8

Nous utilisons des «contingents» ou un arriéré spécifique pour de telles tâches. La Scrum Tool Agilo soutient cette façon de travailler et calcule ces problèmes également, par exemple dans le Burndown. De cette façon, vous obtenez un bon contrôle sur les éléments "non planifiables".

Answer 9

Vous confondez la précision avec précision?

L'idée derrière l'estimation agile est de proposer un nombre assez bon, pas un nombre exact. C'est pourquoi l'utilisation de points d'histoire pour l'estimation des articles du carnet de commandes est une meilleure pratique; Il met l'accent sur l'effort / la complexité au lieu de la durée.

Vous n'avez pas besoin de savoir combien de temps chaque tâche nécessaire pour mettre en œuvre un élément du backlog dans un sprint prendra. Ce que vous devez savoir est, étant donné le travail auquel vous vous êtes déjà engagé dans ce sprint, pouvez-vous vous engager dans cet élément du carnet de commandes? Parce que nous savons que nous ne pouvons pas savoir exactement combien de temps chaque élément du carnet de commandes prendra, nous devons faire une supposition éclairée.

Plus important encore, que signifie échouer dans Scrum? Est-ce que chaque élément du carnet de commandes de Sprint a terminé un échec? Non ... si vous avez obtenu quatre articles sur cinq et le cinquième est principalement terminé, vous obtiendrez du crédit pour les quatre articles terminés (en termes de vitesse pour le sprint), et lorsque vous terminez les tâches restantes pour cela Cinquième élément dans un futur sprint, vous obtiendrez un crédit complet pour cet article. Mais, auriez-vous fait de plus si vous n'utilisiez pas Scrum? Le seul échec de Scrum est de ne pas apprendre de vos erreurs, de continuer à faire les mêmes choses dysfonctionnelles à plusieurs reprises tout en s'attendant à des résultats différents.

Donc, lors de votre réunion de planification de sprint, ne passez pas beaucoup de temps à vous soucier de quelque chose que vous ne pourrez pas savoir. Laissez l'équipe réfléchir au travail, puis laissez-les s'inscrire à la quantité de travail qu'elle se sent à l'aise qu'ils peuvent terminer pendant le sprint. S'ils sous-engagent, vous pouvez toujours faire glisser quelque chose dans l'arriéré ou mettre fin au sprint tôt. S'ils surmontent, vous terminez les éléments du backlog que vous pouvez en priorité et discutez des raisons pour lesquelles les articles inachevés ne pourraient pas être terminés dans la rétrospective de sprint, ainsi que comment éviter d'avoir des articles inachevés dans les futurs sprints.

Soit dit en passant, je sais que c'était probablement un mauvais choix de mots de votre part, mais un Scrum Master efficace n'exécute pas le sprint. L'équipe gère le sprint et le Scrum Master recherche activement des obstacles qui réduisent leur productivité et interfèrent avec leur capacité à respecter leurs engagements. Les Scrum Masters ne sont pas des managers, ils sont une combinaison d'arbitre, d'entraîneur et de gardien de score. Ils sont le gardien du processus, ils aident l'équipe à suivre le processus, ils protègent l'équipe des agents extérieurs qui essaient de contourner le processus, et ils suivent les progrès pendant le sprint via s'assurer que le sprint est mis à jour et le graphique de Burndown Sprint reflète la réalité, quotidiennement. Dans la situation que vous avez décrite, où l'équipe ne sait pas combien de travail il doit s'inscrire, le Scrum Master devrait laisser l'équipe se décider comme un reflet du respect de la possession de l'équipe de l'engagement. Quelle que soit la décision, ce ne sera pas faux.

Answer 10

Les pointes doivent être en boîte à temps. Il exerce une pression sur l'équipe pour limiter la portée et avoir une meilleure idée des coûts-avantages que la recherche impliquera; c'est-à-dire qu'il est inutile de réaliser 3 jours de recherche pour une tâche qui coûterait quelques dollars.

Ceci est également soutenu par le travail de Latham sur la théorie des objectifs où il aborde spécifiquement ce problème.