Nous savons que la planification à long terme (planification de la publication) doit être en story points.
Mais pour la planification de sprint, cela doit être un engagement
Diviser lélément de backlog produit / user story en tâches et estimer les tâches, léquipe se demandant si elle peut sengager à livrer lélément de backlog produit, puis répéter jusquà ce quelle soit pleine?
Pour un sprint de trois semaines, quelle devrait être la taille de chaque histoire pour une personne?
De plus, jai vu que certaines équipes se débarrassent de cette planification basée sur les tâches et ont des histoires qui ne durent que 2 jours ?
Dois-je normaliser cela pour mon équipe?
Donc, avant un sprint, je divise mes histoires en histoires tellement courtes quelles correspondent à cette norme.
Sil vous plaît, faites-moi savoir vos points de vue à ce sujet. Et quelle est la pratique générale?
Commentaires
- Guide Scrum modifié depuis » engagement » à » prévisions « . Pour en savoir plus sur la raison de ce changement, cliquez ici.
- Ce lien peut être utile pm.stackexchange.com/questions/10119/ …
Réponse
TL; DR
Fondamentalement, lensemble de vos hypothèses de planification nest pas agile. Vous devez revoir la manière dont vous planifiez vos itérations et la manière dont votre équipe prévoit destimer le travail quelle pense pouvoir être effectué pour litération en cours. Une analyse plus détaillée suit.
Analyse détaillée
Nous savons que la planification à long terme (planification de la version) doit se faire en story points. [sic]
Non. La planification des versions Agile se fait en itérations . Par conséquent, un plan de projet Scrum évaluera une plage approximative ditérations nécessaires pour atteindre le produit minimum viable ou terminer le backlog produit initial. Ceci est seulement une estimation, car le contenu de larriéré changera avec le temps, et la longueur et la précision des estimations changeront également avec le Cône dincertitude .
Mais pour la planification de sprint, elle doit être basée sur lengagement.
Encore une fois, non. La planification de sprint est basé sur la capacité . Seul point de suivi (ou la création dune estimation initiale de) la vitesse moyenne de léquipe consiste à trouver la capacité durable de léquipe à travailler au fil du temps. Alors que léquipe doit sassurer de ne jamais trop sengager à travailler dans un Sprint simplement parce que la plage de vitesse ou la moyenne indique quil devrait y avoir de la capacité disponible, il est de la responsabilité de léquipe de planifier litération actuelle en prenant la composition de léquipe, la disponibilité , et dautres facteurs qui affectent le Sprint actuel en considération.
Dire que les Sprints sont « basés sur lengagement » est susceptible dêtre utilisé comme un matraque émotionnel pour inciter les équipes à sengager plus de travail qu’ils ne le devraient, car les membres de l’équipe doivent bien sûr être «engagés». Cependant, c’est «une mauvaise utilisation; dans le monde réel, la capacité de léquipe doit généralement être réduite mais rarement gonflée pendant la planification. Si léquipe est sous-engagée, alors du travail supplémentaire peut être retiré du Backlog produit si nécessaire, mais la réduction de la portée est presque toujours politiquement lourde et met souvent en péril lobjectif de sprint. Alors, ne faites pas cela.
La capacité peut être une mesure relativement objective. Dun autre côté, lengagement (tout comme le patriotisme) ne peut « être mesuré que si vous » demandez aux gens de «faire le sacrifice ultime», ce qui est en quelque sorte contraire à la prémisse de la durabilité agile. Ne vous engagez jamais dans une marche de la mort .
Pour un sprint de trois semaines, quelle devrait être la taille de chaque histoire pour une personne?
Cela mérite un livre entier rempli de «non». Les histoires ne sont jamais dimensionnées pour, ni acceptées par un individu. Toutes les histoires sont estimées sur la base des ressources complètes et coordonnées dune équipe interfonctionnelle travaillant ensemble pour terminer chaque histoire. Les histoires sont acceptées ou rejetées selon que:
- Elles sont essentielles à lobjectif de sprint actuel.
- Elles sinscriront dans la capacité estimée disponible pour le sprint en cours.
Un seul élément de backlog de produit peut être nimporte où re de 0 point dhistoire jusquau maximum disponible pour tout le Sprint. Cependant, une bonne histoire qui répond aux critères INVEST est généralement composée de tâches Sprint Backlog dune durée denviron 0,5 à 2,0 jours. Noubliez pas que plus la tâche ou lhistoire est petite, plus lestimation est généralement précise, donc une douzaine dhistoires en 5 points (lorsquelles sont estimées avec précision) sont généralement plus fiables quune seule histoire en 60 points. Cependant, la maturité de votre équipe et la précision des estimations peuvent certainement varier.
Réponse
Les user stories ne sont pas par membre de léquipe
Plusieurs membres de léquipe doivent travailler sur le même utilisateur histoire en même temps. Ce nest pas une exigence mais une recommandation. Lessence de la terminologie du rugby, mêlée , où léquipe se dirige vers la ligne de but en tant quunité. Le concept sappelle essaimage . Tout le monde se concentre sur une (ou moins) tâche à un moment donné, la termine et sattaque au travail suivant (répéter). Avantages:
- Cela permet de conserver_ en cours_ moins déléments.
- Il permet de compléter les éléments du backlog de sprint répartis tout au long du sprint, au lieu que tout soit terminé près de la fin du sprint.
- Maintient la charge qa / testing uniformément répartie sur la durée du sprint.
- Toute léquipe acquiert la connaissance du code et peut fournir des suggestions techniques.
Léquipe devrait Choisissez une histoire et divisez-la en tâches techniques. Une seule personne devrait travailler sur une tâche technique car la responsabilité est claire dans ce cas, ce qui aide lors des réunions de mêlée quotidiennes. Dans lidéal, une tâche technique doit être suffisamment petite pour être achevée en une journée.
Taille des user stories
Scrum ne définit aucune taille recommandée dune user story. Cependant, une histoire doit être dimensionnée de telle sorte quelle puisse être complétée pendant un sprint. « Achèvement » signifie quil couvre votre « Définition de Terminé ».
Une histoire doit être clairement comprise et avoir des critères dacceptation explicites, qui sont vérifiés au cours du même sprint. Normalement, il est plus difficile daplanir une grande histoire et dénoncer tous les critères dacceptation, donc une histoire doit être petite pour pouvoir être suffisamment bien estimée et testée.
Une histoire doit également être assez grande pour quelle apporte une valeur commerciale concrète aux parties prenantes.
La réponse est donc ni trop petite ni trop grande . Avec de la pratique et de lexpérience, vous vous améliorez dans lécriture et la division des user stories. Cest plus un art que de la science.
Réponse
La planification de sprint devrait également être en story points. Le processus est le même que pour la planification à long terme. Vous vérifiez votre vitesse et votre capacité (combien de membres de léquipe seront là, à cause des vacances, etc.) et vous montez avec un nombre.
Si vous planifiez le sprint 2, vous vérifiez votre vitesse au sprint 1 – par exemple 10 points – et mettez 10 points de user stories dans votre backlog ditération.
Si vous planifiez le sprint 3, vous vérifiez votre tendance de vélocité du sprint 1 au sprint 2 et trouvez le montant auquel vous pouvez vous engager.
Si vous prévoyez le sprint 1, vous ajoutez autant que vous voyez bon.
Essayez de ne pas voir combien de points une personne peut faire , car la mêlée est sur les équipes et non sur les personnes. Par exemple, un junior peut faire moins quun senior, mais si les gens sentraident, ils ne seront pas en mesure de livrer autant que « sur papier ». Travailler et calculer en équipe , car cela a plus de sens (et cest plus facile).
Commentaires
- Oui, Je suis daccord avec vous, le total des points de stockage des sprints précédents doit être référencé et comme vous / CodeGnome la dit, la capacité doit également être prise en compte.En fait, je ne comprends pas à quel point la longueur doit être » chaque » histoire afin quelle puisse être testée en parallèle car il ny a pas de phase de test séparée.
- De plus, jai déjà fait référence à ce qui suit: mountaingoatsoftware.com/blog/…
- @Roop, comme dautres lont dit, » chaque » histoire na pas besoin dêtre assez courte. Elle sera exécutée par plusieurs membres de léquipe, mais les tâches de lhistoire doivent être conservé 0,5 jour à 2 jours