Je suis le maître Scrum pour une petite équipe de 4 développeurs. Le projet sur lequel nous travaillons a beaucoup de tâches que nous n'avons jamais fait auparavant et ne peut pas facilement estimer dans une réunion de planification de sprint. Quel est le meilleur moyen pour moi de courir un sprint avec cette incertitude? Je trouve qu'il est très difficile de finir un sprint avec un produit potentiellement libérable. Je trouve aussi difficile de planifier des sprints quand il y a beaucoup de tâches de longueur inconnues.
10 Réponses :
Je ne suis pas sûr de ce que le terme est dans Scrum, mais dans la terminologie de l'histoire d'utilisateur, vous feriez une "pointe", qui est fondamentalement une très courte période de recherche sur le sujet afin que votre équipe puisse estimer la tâche à la fin de la pointe.
Exemple:
histoire:
analyste veut pouvoir revoir Données financières dans les cartes à tarte.
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 plutôt, vous pouvez investir dans un outillage tiers et intégrer un ensemble d'outils avec votre application.
Vous feriez une pointe pour rechercher ces lieux et proposerait des estimations sur eux, puis décidez quelle route à prendre.
Une pointe est-elle prévue pour le même sprint que les tâches découvertes dans la pointe? Ou les tâches sont-elles découvertes dans une pointe prévue pour le prochain sprint?
@Dave habituellement pas. Habituellement, vous pointerez sur un sprint, puis faites la tâche sur le prochain sprint. C'est pourquoi il est important de vous assurer de rendre compte de vos pics pendant votre gestion de publication.
+1 @Joseph, en disant que vous craignez sur un sprint donné, vous dites implicitement qu'une picture est temporelle temporelle (c'est-à-dire une quantité de temps fixe spécifique est attribuée à celle-ci). Je pense que cela vaut la peine de dire explicitement que les pointes devraient être temporées temporelles.
Si les tâches semblent ONU 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 allez probablement proposer un pseudo-conception pendant que vous y êtes. Joel mentionne cela dans l'un de ses articles .
Tout va bien pour des tâches complexes difficiles à estimer. Mais pour des tâches vraiment inconnues, vous ne savez peut-être pas ce que vous voulez construire ou comment cela fonctionnera. Il existe des tâches dans divers projets de R & D où le temps requis n'est pas connu tant que le problème n'est pas résolu ni que la question est répondue.
Si la tâche est vraiment inconnue, alors il est impossible de l'estimer (au moins avec une sorte de précision). Ce que je suggérais d'essayer d'essayer de penser à ce que vous savez déjà, essayez de penser à ce que vous devrez peut-être faire, peut-être que la main soit un plan, n'importe quoi pour avoir une idée de ce que vous pourriez avoir besoin de faire et de commencer votre estimation basé sur cela.
diviser la tâche inimalable en tâche pour éliminer l'incertitude et "le reste". Supprimer l'incertitude avec des tests de la preuve de concept ou des solutions de pointes. Soit planifie les pointes de ce sprint et le reste du travail suivant Sprint, soit retarder le début du sprint pendant une semaine de spiking.
sont les «tâches» des choses que quelqu'un au monde a déjà fait, ou sont-ils simplement nouveaux pour 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 de votre équipe pour résoudre le problème. Ainsi, vous développerez cette expérience comme vous allez. Tout cela signifie que la complexité de vos histoires est plus élevée. Dans les premiers sprints, vous pouvez marquer certaines des histoires comme 13, puis plus tard, ils deviennent 8s parce que vous avez alors les connaissances dont vous avez besoin.
Vous n'avez pas besoin de savoir comment faire les histoires pour les estimer. Il vous suffit de prendre moins d'entre eux en raison de votre écart d'expérience.
J'aime réserver "Spikes" (oui c'est le terme utilisé dans Scrum) pour tenter de résoudre des problèmes de domaine commercial qui n'ont aucune solution connue. Pas pour l'équipe de faire une formation.
Nous ne savons souvent pas assez pour casser une histoire en tâches. Nous avons une période de découverte avant de savoir quelles seront les tâches. "Spikes" semblent difficiles à gérer. Pour un, vous ne pourrez peut-être pas que le temps de découverte. Deuxièmement, je ne peux pas planifier efficacement une sprint sans savoir combien de temps une histoire prendra une histoire.
semble être une autre option consiste à faire la pointe de Sprint 1 et aux tâches de Sprint 2. L'inconvénient est qu'il semble que le processus force une panne non naturelle du travail. Pourquoi découvrir cette semaine puis attendez un moment avant de commencer le travail.
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 l'avoir fait (par quelqu'un) avant la planification de Sprint.
En règle générale, je pense que si vous ne pouvez pas obtenir une bonne estimation, vous devriez soit aller avec une mauvaise estimation (c'est-à-dire une supposition sauvage), soit vous devriez vous faire face à la tâche, vous devez donc mettre de côté une quantité de temps fixe. pour cela dans un sprint. Après cela, vous aurez soit une solution terminée, ou vous aurez une meilleure compréhension de celle-ci afin que vous puissiez l'estimer ou la casser dans des sous-tâches pour le prochain sprint (ou un sprint ultérieur).
Est-ce que vous voulez vraiment dire des tâches ou parlez-vous d'éléments de rétro-éclairés de produits (PBIS)? En fait, je trouve difficile de croire qu'une tâche n'est pas estimable. S'ils ne sont vraiment pas, ils sont très probables trop gros (les tâches ne devraient pas dépasser 16h, qui est déjà énorme).
Si vous parlez de PBIS, la situation que vous décrivez est assez surprenante et de ne pas se produire théoriquement. Dans le pire des cas, il suffit de lui attribuer un grand nombre 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 mettrez trop de risque sur votre sprint), le moyen évident de résoudre cette situation est de diviser de tels éléments en petits morceaux qui peuvent inclure l'exploration. Mais la partie importante est de garder les choses temporelles, même (ou surtout) R & D. Gardez à l'esprit que avec Scrum, tout est temporable.
En d'autres termes, réduire l'incertitude, briser les choses dans des choses plus petites (que ce soit des objets ou des tâches)!
Nous utilisons des "contingents" ou un arriéré spécifique pour de telles tâches. Le outil Scrum Agilo prend également en charge cette façon de travailler et calcule également ces problèmes, par ex. dans la burndique. De cette façon, vous avez un bon contrôle sur les éléments "non plannables".
Êtes-vous confondre précision avec précision?
L'idée de l'estimation de l'agile est de trouver un nombre suffisant, pas suffisant, pas un nombre exact. C'est pourquoi utiliser des points d'histoire pour l'estimation de l'article d'arriéré 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 implémenter un élément d'arriéré dans un sprint prendra. Ce que vous devez savoir est, étant donné le travail que vous avez déjà engagé dans ce sprint, pouvez-vous vous engager à cet article d'arriétrage? Parce que nous savons que nous ne pouvons pas savoir exactement combien de temps chaque article d'arriéré prendra, nous devons faire une supposition éduquée.
Plus important encore, qu'est-ce que cela signifie échouer dans Scrum? N'a-t-il pas obtenu chaque élément d'arriéré Sprint terminé une défaillance? Non ... Si vous avez eu quatre articles sur cinq sur cinq et le cinquième est principalement fait, vous obtiendrez un crédit pour les quatre articles terminés (en termes de vitesse pour le sprint) et lorsque vous avez terminé les tâches restantes pour que Cinquième article dans un futur sprint, vous obtiendrez un crédit complet pour cet article. Mais vous auriez-vous plus fait si vous n'utilisiez pas Scrum? Le seul échec de Scrum ne fait pas apprendre de vos erreurs pour continuer à effectuer les mêmes choses dysfonctionnelles à plusieurs reprises tout en vous attendant à des résultats différents.
Donc, dans 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 penser au travail, puis laissez-les s'inscrire à la quantité de travail qu'ils se sentent à l'aise qu'ils peuvent compléter pendant le sprint. S'ils souscrivent, vous pouvez toujours faire glisser quelque chose dans l'arriéré ou mettre fin au sprint tôt. S'ils surgivent, vous terminez ensuite les articles de l'arriéré que vous pouvez dans l'ordre de priorité et discutez de la raison pour laquelle les articles inachevés ne pouvaient pas être terminés dans la rétrospective Sprint, ainsi que de la manière de prévenir d'avoir des articles inachevés dans les sprints futurs.
Au fait, je sais que c'était probablement un mauvais choix de mots de votre part, mais un maître de mêlée efficace ne fonctionne pas le sprint. L'équipe dirige le sprint et le maître Scrum recherche activement des obstacles qui abaissent leur productivité et interfèrent leur capacité à respecter leurs engagements. Scrum Masters ne sont pas des gestionnaires, ils sont une combinaison d'arbitres, d'entraîneurs et de marqueurs. Ils sont le gardien du processus, ils aident l'équipe à suivre le processus, ils protègent l'équipe d'agents extérieurs qui tentent de contourner le processus et de suivre progresser pendant le sprint en garantissant que le carnet de sprint est mis à jour et le graphique de brûlures de sprint reflète la réalité, au quotidien. Dans la situation que vous avez décrite, où l'équipe ne convient pas à quel point ils devraient s'inscrire, le maître Scrum devrait laisser l'équipe décider comme un reflet du respect de la propriété de l'équipe de l'engagement. Quelle que soit la décision, ce ne sera pas faux.
Les pointes doivent être en boîte de temps. Il met la pression sur l'équipe pour limiter la portée et avoir une meilleure idée des coûts-avantages que la recherche entraînera; C'est inutile d'effectuer 3 jours de recherche pour une tâche qui coûterait quelques dollars.
Ceci est également sauvegardé par le travail de Latham sur la théorie de l'établissement d'objectifs où il s'attaque spécifiquement à ce problème.