Si je comprends bien Scrum, c'est ainsi que je détermine le travail que mon équipe peut effectuer lors du prochain sprint:
Je fais la moyenne du nombre de points terminés pour les derniers sprints.
Cette quantité est notre vitesse moyenne. Au prochain sprint, nous aborderons autant de points d'histoire.
C'est une moyenne , donc si l'histoire se répète, ce sprint, il est 50% probable que nous prenons trop peu de points d'histoire, et 50% probable que nous prenons trop de points d'histoire.
Dans le cas de 50%, nous avons pris trop de points d'histoire que nous pourrions:
Impossible de terminer le sprint. Cela signifie que nous ne respecterons pas notre engagement de sprint la moitié du temps.
Travail supplémentaire pour rattraper son retard. Le problème est que ce cliquet ne fonctionne que dans un sens. Nous accomplirons le sprint, et le nombre de points d'histoire complétés reflétera cela. Puisque nous finissons toujours, au fil du temps, notre moyenne tendra à la hausse au point où nous accomplissons toujours un grand nombre de points d'histoire et restons en retard.
Ma compréhension de la vitesse moyenne et des engagements de sprint est-elle correcte?
Si oui, que devons-nous faire pour les 50% de sprints où nous sommes derrière la moyenne?
Sinon, qu'est-ce que je me suis trompé?
la source
Réponses:
Oui, vous en avez l'essentiel.
Ce que vous avez oublié, c'est que les points d'histoire sont les choses que vous faites . Il est presque impossible pour tout le monde de travailler sur des histoires jusqu'à la fin du sprint. Si vous faites les choses correctement, la plupart de vos développeurs seront "inactifs" pendant quelques jours pendant que les histoires sont testées (et vos testeurs au milieu du sprint alors que le développement bat son plein).
Je mets inactif entre guillemets parce que vos développeurs ne sont pas assis à regarder des vidéos de chats, ils corrigent des bugs, peaufinent des tests de code / unité, ajoutent de la documentation sur les processus, réfléchissent à la conception des histoires dans le backlog ou l'un des d'autres dizaines de choses utiles dont une équipe de développement peut bénéficier mais qui ne s'intègrent pas bien dans une histoire.
Donc, même si vous devinerez 50% du temps et sous-estimerez 50% du temps, cela ne signifie pas que vous allez échouer au sprint ou devoir faire des heures supplémentaires . Cela signifie que vous n'aurez pas autant de temps pour effectuer ce travail divers (sauf si vous manquez vraiment vos estimations). Mais ce n'est pas un gros problème, car le travail divers n'est pas sensible au temps, et les choses vont même s'éteindre à long terme.
la source
Malheureusement, vous avez été mal informé sur certaines choses concernant la planification de sprint dans Scrum. Premièrement, l'équipe de développement (DT) est
Le mot pour cela est auto-organisé. Cela comprend le travail de prévision du travail qui sera effectué dans un Sprint donné. Le DT n'est pas informé de ce qu'il fonctionnera à chaque sprint, il est plutôt autorisé à choisir son propre travail. Le DT peut avoir besoin d'informations telles que la vitesse historique, un carnet de produit bien affiné et la capacité DT du prochain Sprint pour créer une prévision. En fin de compte, c'est la détermination du DT de ce qui peut et ne peut pas être accompli dans un sprint qui devrait prévaloir dans ses prévisions; on ne devrait pas leur dire combien de travail ils feront.
Remarquez aussi, prévision et non engagement. Le mot c a été supprimé du Scrum Guide car il était utilisé pour abuser de l'équipe de développement. La prévision est le terme préféré.
En ce qui concerne la probabilité de manquer les prévisions Sprint sur le bas ou le haut de gamme, je ne considère pas cela comme important. À un moment donné, une analyse plus approfondie ne donne pas une meilleure précision et je pense que nous sommes au-delà de ce point maintenant.
En outre, un sprint ne peut être «annulé»; cela ne peut jamais échouer. Un sprint n'est annulé que lorsque l'objectif du sprint devient complètement obsolète et hors de propos. C'est très rarement le cas. Si une prévision est incorrecte, restez calme et Scrum. Avez-vous une rétrospective. Prochain Sprint, vos prévisions seront meilleures :).
la source
Tout d'abord, votre vitesse provient de votre sprint précédent, ou parfois d'une moyenne de quelques sprints récents (Météo d'hier), et non d'une moyenne de tous les sprints passés. Bien sûr, si vous n'avez pas de données historiques de votre équipe ou entreprise, vous devez trouver une valeur raisonnable pour votre premier sprint. Lors de votre deuxième sprint, vous saisissez les points d'histoire terminés dans le sprint. Si vous deviez le représenter graphiquement, vous pourriez voir des variations au cours des premiers sprints (par exemple, 17 dans le premier sprint, 22 dans le second, 26 dans le troisième, 24 dans le quatrième). Il faut s'y attendre à mesure que vous normalisez votre travail d'équipe et votre processus d'estimation, tout en acquérant une meilleure compréhension du projet (technologie, domaine).
Cela ne veut pas dire que vous ne vous ajustez pas. Par exemple, si vous avez une semaine qui est une semaine de vacances, assurez-vous de tenir compte des vacances où le travail est fermé. Si vous savez que les membres de l'équipe prennent des vacances, prévoyez moins de personnes travaillant. Bien sûr, des événements imprévus se produisent également, mais vous pouvez les expliquer dans une rétrospective de sprint et vous pouvez décider comment cela influence le nombre de points d'histoire que vous apportez au prochain sprint.
En ce qui concerne ce qu'il faut faire, "ne pas terminer le sprint" est différent de "nous n'avons pas terminé toutes les histoires". Pour moi, un échec d'un sprint signifie que vous n'avez pas produit un produit potentiellement livrable à la fin - aucune de vos histoires n'est terminée, vous n'avez pas de build, vous ne pouvez pas démontrer de valeur ajoutée au client ou utilisateurs.
Quoi que vous fassiez, vous ne devez pas travailler tard ou excessivement avec le temps. C'est ce qu'on appelle le rythme durable ( Agile Alliance , Scrum Alliance ).
Les indicateurs qu'il peut y avoir des problèmes sont les suivants:
la source
La méthodologie agile varie d'une entreprise à l'autre, dans une mise en œuvre, elle pourrait être très différente d'une autre. J'ai travaillé sous Agile avec deux entreprises. Dans la première entreprise où j'étais, ils prenaient leurs mesures très au sérieux, dans la deuxième entreprise pas vraiment du tout. Donc, pour tout ce que vous savez, personne ne fait attention à vos mesures.
Cela dit, il semble que vous ne souhaitiez pas atteindre vos objectifs de sprint ou ce qui se passe lorsque vous avez une estimation inexacte. Je pense que ce type de préoccupation et de perspective est courant, mais ce n'est pas particulièrement important. Agile, avant tout, est un système de développement logiciel qui fait plusieurs choses:
En fin de compte, si vous évaluez mal un sprint ou si vous échouez, ce n'est pas vraiment un problème. Les personnes qui sont au-dessus de votre équipe dans votre entreprise sont probablement plus préoccupées par le fait que votre équipe se déplace constamment et que les projets soient menés à leur terme logique.
En tant qu'individu sous Agile, vous devriez être plus préoccupé par la quantité de travail que vous effectuez efficacement en référence au reste de votre équipe. Si vous êtes nouveau, vous ne pouvez pas vous attendre à être trop productif, mais à un moment donné de votre période d'emploi, vous devriez être au même niveau qu'au moins une partie de votre équipe. Si vous ne produisez pas de travail, vous ne faites pas vraiment votre travail.
la source
Votre vitesse moyenne est parfaite. D'après mon expérience, cela est très utile pour les estimations à long terme de l'achèvement - en supposant que vous avez un arriéré important; mais pas aussi utile pour les engagements de planification de sprint.
Le processus que j'ai vu pour la planification du sprint est de tirer des histoires du haut de l'arriéré et de laisser l'équipe décider si elles peuvent les réaliser. Les équipes ont décidé cela en fonction de la sensation intestinale, de la répartition en tâches d'une demi-journée, de la pression du propriétaire du produit, de l'alignement avec un objectif de sprint, de la meilleure estimation (basée sur la vitesse) ou d'une combinaison de tous.
Parfois, le propriétaire du produit a autorisé le saut de quelques éléments afin d'en ajouter d'autres.
Parfois, l'équipe et le propriétaire du produit conviennent au préalable des articles extensibles pour passer.
la source
C'est une excellente question et il est très important pour les équipes de s'améliorer. Le sujet est trompeur et est largement mal compris. Le but initial du pointage d'histoire était de trouver une méthode rapide et suffisamment précise pour estimer le niveau d'effort (LOE) nécessaire pour compléter la fonctionnalité définie dans les histoires. L'objectif global: donner aux équipes une méthode de PRÉVISION ou de prédire combien de temps il faudrait pour terminer un effort (comme un projet). Votre compréhension de Velocity est correcte: ce sont les points MOYENS par Sprint terminé (vraiment FAIT). Donc, si vous avez un projet à livrer et qu'il est de 250 points et que votre équipe en moyenne 25 points par sprint, le projet prendra environ 10 sprints, plus ou moins un certain temps tampon.
Certains sommités, comme Ken Schwaber, suggèrent que la vitesse et les points ne doivent être utilisés que pour les prévisions à moyen et long terme. Ils suggèrent d'utiliser les heures de tâche comme un deuxième "test de santé mentale" sur ce qui peut réellement être fait dans un sprint. Ainsi, le nombre de points dans chaque sprint peut varier en fonction de la capacité. D'autres (y compris moi-même) croient qu'une équipe mature s'installera dans un modèle de dimensionnement très cohérent qui peut prédire avec précision la capacité, et finalement les heures de travail deviennent un fardeau supplémentaire inutile. (Il est essentiel de performer pour de nouvelles équipes pendant au moins 6 à 12 sprints, à mon humble avis, jusqu'à ce que la compréhension de l'équipe des points et du dimensionnement de l'histoire soit exacte.)
Votre première petite erreur est que vous avez dit que l'équipe devrait connaître la vitesse et apporter autant de points d'histoire. En fait, les entraîneurs encouragent les équipes à déduire de 10% à 20% et à s'engager * à ce niveau à la place. Donc, si votre équipe a tendance à compléter 25 points par sprint, ne remplissez pas le sprint à 25 points, mais plutôt, arrêtez-vous à 20 à 22 points. Rappelez-vous: il est parfaitement FINE d'apporter des histoires lorsque l'autre travail est terminé. Vous pouvez donc "vous engager" à 22 points et en terminer 28. C'est super. Faites juste attention à ne pas encourager l'équipe à "faire des sacs de sable" et à constamment s'engager. Il n'y a rien de mal à s'étirer pour voir si nous pouvons faire plus.
Maintenant, à votre point sur la variance entre les sprints. C'est un schéma très courant (mais NON OPTIMAL) de voir une équipe qui complète 20 points un sprint, puis 50, puis 22, puis 45, puis 15, puis 60. Si vous calculez l'écart, il peut montrer des oscillations de 50% à 100% sprint après sprint. Pourquoi les équipes ne complètent-elles que 15 points dans un sprint, puis 60 dans le suivant?
Cela pourrait signifier que l'équipe ne sait vraiment pas ce qu'elle peut faire. (Hé, nous avons complété 50 points au dernier sprint, nous pouvons recommencer ce sprint).
OU, cela pourrait indiquer que les propriétaires de produits forcent l'équipe à se sur-engager, ou ajoutent du travail après le début du sprint, etc. Ce ne sont que quelques-uns des ANTI-MOTIFS qui pourraient être à l'origine de cette oscillation sauvage des points terminés.
Cette mesure de prévisibilité est importante pour les maîtres de mêlée à observer et à porter à l'attention de l'équipe.
Souvent, la raison pour laquelle ils ont obtenu quelques points dans un sprint, puis de nombreux points dans le sprint suivant, c'est ce que j'appelle la "ONDE ROULANTE DU TRAVAIL INCOMPLETE". Voici un schéma très courant:
Le propriétaire du produit est sous pression pour respecter une date. L'équipe ressent donc le besoin d'essayer de faire beaucoup de travail. Ils commencent comme une nouvelle équipe et ne savent pas vraiment ce qu'ils peuvent réellement faire.
Alors sprint 1, ils planifient le sprint et comme ils sont en phase de formation, ils ne peuvent pas terminer tout le travail. En fait, ils ont un travail plus incomplet que fait. L'œuvre incomplète est COMMENCÉE mais INCOMPLETE. Il est déplacé au prochain sprint, et cette fois, ils ont plus de travail que incomplet. Au prochain sprint, cette grande charge de travail incomplet tombe dans TERMINÉ et la confiance de l'équipe monte en flèche.
Le propriétaire du produit est excité et augmente donc à nouveau sa charge. À la fin de ce sprint, ils ont une énorme quantité de travail incomplet et une quantité décevante de travail FAIT.
Ici, vous commencez à voir les VAGUES de Done vs Incomplete alterner sprint après sprint. Si les équipes ne réalisent pas ce qui se passe, ce schéma peut se poursuivre pendant des mois. Mais en moyenne, ils complètent environ 24 points par sprint. Alors, que se passe-t-il quand ils arrêtent de trop s'engager?
Vous noterez qu'ils ENCORE 24 à 26 points, mais le travail de report est réduit. Maintenant, au lieu d'être submergée en essayant de terminer une quantité impossible de travail, ce qui détruit également le moral de l'équipe, l'équipe peut commencer à améliorer ses processus.
Au fil du temps, la vélocité commencera à augmenter, sans les énormes oscillations du travail terminé vs incomplet.
Si vous ne laissez pas à l'équipe un peu de «temps libre», elle n'aura JAMAIS le temps d'effectuer un travail qui la rendra plus légère, plus rapide et meilleure. Les Dev-Ops, par exemple, ne peuvent pas arriver. Automatisation des tests - Qui a le temps pour ça!? Mais ce sont précisément les choses sur lesquelles les équipes doivent travailler pour augmenter la vitesse.
la source