Problèmes Scrum Burndown [fermés]

Question

Nous utilisons Scrum depuis environ 9 mois et le logiciel a connu un grand succès. Cependant, nos graphiques de burndown ressemblent rarement aux graphiques "modèles", ils ressemblent plutôt à une terrifiante montagne russe avec quelques vomissements provoquant des montées et des descentes.

Pour tenter de lutter contre cela, nous passons plus de temps avant le prototypage et la conception du sprint, mais nous semblons découvrir encore beaucoup de travail pendant le sprint qu'on ne le pensait initialement. Remarque: J'entends par là que le travail requis pour traiter l'arriéré est plus complexe que prévu, plutôt que d'avoir identifié de nouveaux éléments pour l'arriéré.

S'agit-il d'un problème courant avec Scrum et y a-t-il des astuces pour vous aider à bien rouler?

Je tiens à souligner que la plupart de nos travaux de développement ne sont pas de type "greenfield". Nous conservons donc les fonctionnalités d'une application existante volumineuse et complexe. Scrum est-il moins adapté à ce type de développement simplement parce que vous ne savez pas quels problèmes le code existant va poser?

Combien de temps devrions-nous passer avant que le sprint ne commence à traiter les détails du développement?

MISE À JOUR: Nous rencontrons plus de succès et une conduite plus douce maintenant. Cela tient en grande partie au fait que nous avons adopté une vision plus pessimiste lors de l’estimation de ce qui nous laisse plus de marge de manœuvre pour nous occuper de choses qui ne se passent pas comme prévu. Vous pourriez dire que cela nous permet d'être plus «agiles». Nous essayons également de changer la perception selon laquelle le graphique de burndown est une sorte de planning plutôt qu'une indication de la portée des ressources.

Answer 1

Quelques conseils pour lisser les choses.

1) Comme d’autres l’ont déjà dit, essayez de diviser les tâches en petits morceaux. La manière la plus évidente de procéder consiste à essayer de décomposer les tâches techniques de manière plus détaillée. Dans la mesure du possible, je vous encourage à parler au propriétaire du produit et à voir si vous pouvez réduire la portée ou "mince". l'histoire à la place. Je trouve ce dernier plus efficace. Il est plus facile de jongler entre les priorités et les estimations si l’équipe et le responsable du produit comprennent les discussions.

Mon règle générale est qu'une estimation supérieure à la moitié d'une journée idéale est probablement fausse: -)

2) Essayez de faire des sprints plus courts. Si vous faites des sprints d'un mois, essayez deux semaines. Si vous faites deux semaines, essayez-en une.

• Limite la taille de l'histoire en incitant le propriétaire du produit et l'équipe à travailler sur des histoires plus petites, plus faciles à estimer avec précision
• Vous recevez plus souvent des commentaires sur vos estimations - et il est plus facile de voir les liens entre les décisions que vous avez prises au début du sprint et ce qui s'est réellement passé
• Tout s’améliore avec la pratique: -)

3) Utilisez les perspectives et les rétrospectives pour examiner un peu plus les raisons des hauts et des bas. Est-ce quand vous passez du temps avec des zones particulières de la base de code? Est-ce causé par des gens qui comprennent mal le propriétaire du produit? Des urgences aléatoires qui prennent du temps de développement loin de l'équipe? Une fois que vous avez une meilleure compréhension des hauts et des bas, vous pouvez souvent traiter ces problèmes de manière spécifique. Encore une fois - des sprints plus courts peuvent aider à rendre cela plus évident.

4) Croyez votre histoire. Vous connaissez probablement celui-ci ... mais je le dirai quand même :-) Si vous manipulez cet horrible paquet Foo a pris 3 fois plus longtemps que vous ne le pensiez, il faudra aussi 3 fois plus longtemps que prévu. le prochain sprint. Même si vous pensez que vous serez plus efficace cette fois-ci ;-) Faites confiance à l’historique et utilisez des outils comme Météo d’hier pour guider vos estimations au printemps prochain.

J'espère que ça aide!

Answer 2

Je suis heureux d’apprendre que la mêlée a été largement un succès pour vous. C’est plus important que de faire en sorte que le graphique de burndown au sprint ait l’air idéal. Le burndown du sprint est simplement un outil permettant à l'équipe de l'aider à savoir s'il est sur la bonne voie pour atteindre les objectifs du sprint. si l'équipe a atteint les objectifs du sprint, je ne m'inquiéterais pas trop du fait que le tableau ressemble à des montagnes russes. Quelques suggestions

• Pendant la rétrospective de sprint, demandez à l'équipe d'où provient le travail supplémentaire
• Le travail supplémentaire peut provenir du fait de ne pas avoir de bons tests d'acceptation au début du sprint
• Le travail supplémentaire peut provenir du fait que votre arriéré n'est pas soigné. Une bonne règle consiste à consacrer au moins 5% du temps de l'équipe à la planification du prochain sprint.
• Surveillez les travaux en cours - l'équipe en fait-elle trop en parallèle?
• Pendant la planification du sprint, que pense l’équipe de la répartition des tâches qui composent les histoires?

Si vous n’avez pas atteint les objectifs du sprint, utilisez la vélocité d’équipe établie pour en faire moins lors du prochain sprint. Il faut bien marcher avant de pouvoir courir.

Answer 3

D'après mon expérience, Scrum est nettement plus orienté vers les nouveaux développements que vers la maintenance. Les nouveaux développements sont beaucoup plus prévisibles que de conserver une base de code ancienne et volumineuse.

Cela dit, l’un des problèmes possibles est que vous ne divisez pas les tâches en petits morceaux. L’un des problèmes les plus courants en matière de planification de logiciels est qu’ils pensent «oh, cette tâche devrait me prendre deux jours». sans vraiment penser à ce qui se passe dans la réalisation de cette tâche. Souvent, vous constaterez que si vous y réfléchissez bien, cette tâche consiste à effectuer les tâches A, B, C et D, et aboutit à plus de deux jours de travail.

Answer 4

Comme d'autres l'ont déjà dit, je m'attendrais à ce qu'une panne se produise. Des choses arrivent! Vous devez utiliser les options "haut et bas". bits comme aliment pour vos rétrospectives.

Assurez-vous que tout le monde a bien compris ce qui est "en cours de réalisation". signifie et utilise cette compréhension commune pour vous aider à organiser vos séances de planification. Avoir souvent une liste de ce qui est fait est disponible aidera (a) à vous rappeler des choses que vous pourriez oublier et (b) déclenchera probablement plus d'idées pour des tâches qui, autrement, apparaîtront plus tard.

Un autre point à prendre en compte - si vous travaillez tous les mois avec une base de code imprévisible, je m'attendrais quand même à ce que votre vitesse se normalise à un rythme raisonnablement stable. Suivez simplement votre succès par rapport à votre travail planifié et utilisez uniquement les éléments terminés au maximum lors de la planification. Ensuite, concentrez-vous sur vos tâches non planifiées et voyez s’il existe des modèles suggérant que vous pouvez faire différemment pour inclure ces éléments dans le travail planifié.

Answer 5

J'ai eu des problèmes similaires. Mon équipe précédente (qui y travaillait depuis plus d’un an) était nombreuse et nous avons conservé une base de code très vaste et évoluant rapidement pour les séries de lancements de produits initiaux. Nos burndowns étaient honteux, mais c’était le mieux que nous puissions faire.

Une chose qui peut aider (améliorer l'apparence de votre graphique) est de vous en tenir au nombre d'heures / points constant. Si vous avez sous-estimé une tâche et devez doubler le nombre d'heures, retirez quelque chose du sprint. Si vous vous engagez dans une nouvelle tâche, votre priorité sera évidemment supérieure à celle pour laquelle votre équipe s'est engagée, alors retirez-la.

Nous avons essayé de diviser la tâche en plusieurs tâches dans et avant la planification, et cela n'a jamais semblé aider. En fait, cela nous a juste donné plus de fichus billets à suivre pendant le sprint. Les exigences ont commencé à migrer vers les tickets et (sans surprise) se sont perdues dans tous les remaniements.

Au sein de ma nouvelle équipe, nous avons adopté une approche assez radicale et commencé à créer de gros tickets (certains d'une durée supérieure à une semaine) qui disent des choses telles que "implémenter les fonctionnalités v1.2 dans ProjectX". Les exigences / fonctionnalités de ProjectX (version 1.2 incluse) sont conservées sur un wiki afin que le ticket soit très propre et ne fasse que suivre le travail effectué. Cela nous a beaucoup aidés - nous avons moyen moins de tickets à suivre, et avons pu terminer tous nos sprints même si nous continuons à nous décharger de nos tâches de sprint pour aider d'autres équipes les feux.

Nous continuons à pousser des éléments du sprint si (et seulement si) nous sommes forcés (par l'homme) à importer de nouveaux éléments.

Autre astuce simple qui nous a aidés: ajoutez le "nombre total d'heures de sprint". à votre burndown. Cela devrait être la somme de toutes les estimations. Travailler à garder cette ligne à plat peut aider, et augmente la visibilité des problèmes auxquels votre équipe peut être confrontée (en supposant que cela ne vous rendra pas rétrogradé ...)

-ab

Answer 6

J'ai eu des problèmes similaires dans mon burndown également. Je " fixe " en affinant ce qui était inclus dans le burndown.

SiKeep a commenté:

  

Ses progrès contre l'arriéré   sélectionné pour ce sprint, qui peut ou   ne peut pas finir comme une libération.

Étant donné que vous avez sélectionné certaines choses pour le sprint et que c'est ce qui est sur le burndown, je ne sais pas si tous les "nouveaux travaux" devrait apparaître dans le burndown. Je verrais cela aller dans l'arriéré (n'affectant pas le burndown), à moins que ce ne soit suffisamment important pour entrer dans votre sprint actuel (qui apparaîtrait alors comme une tendance à la hausse dans le burndown).

Cela dit, les hauts et les bas mineurs sont normaux , si la courbe de tendance suit essentiellement la vitesse attendue. Je serais préoccupé par la tendance des montagnes russes que vous mentionnez. Cependant, l'idée d'isoler le burndown en ajoutant uniquement des éléments de haute priorité au sprint actuel peut aider à atténuer ces hauts et ces bas dans votre burndown.

Comme d'autres l'ont dit, la planification avant le début du sprint devrait être courte ... ( pas plus que 4 heures ).

Answer 7

Nous utilisons une tâche "boîte de temps" pour les tâches non planifiées. À chaque fois que des tâches hautement prioritaires arrivent ou que des bugs surgissent, nous pouvons utiliser l'heure de la boîte de temps (mais nous ne pouvons jamais aller en dessous de zéro). Cette méthode présente l’avantage supplémentaire de pouvoir facilement identifier les tâches imprévues et de les prendre en compte lors de la planification de notre prochain sprint.

Answer 8

Vous pouvez intégrer le nouveau travail à la date de début du sprint pour obtenir un superbe diagramme de Burndown.

Vous pouvez baliser le travail supplémentaire avec un marqueur spécifique et évaluer à la fin du sprint pourquoi vous ne pouvez pas identifier ces tâches auparavant.

Answer 9

Nous utilisons maintenant un graphique de burn up. Au lieu de simplement représenter la quantité de travail restante, nous présentons deux éléments: la quantité de travail achevée et la quantité totale de travail (c'est-à-dire achevée + en suspens).

Cela vous donne deux lignes sur le graphique qui devraient se rencontrer lorsque tout le travail est terminé. Il présente également un gros avantage, car il indique clairement que les progrès sont lents, car davantage de travail a été ajouté.

Si vous le souhaitez, le bon de commande "possède" une ligne (le travail total) et les développeurs / testeurs "possèdent" l'autre ligne (travail terminé).

La ligne du bon de commande augmente et diminue au fur et à mesure qu'elle ajoute / supprime du travail.

La ligne dev / tester augmentera uniquement à la fin du travail.

Answer 10

Article S'agit-il de votre graphique de réduction? / strong> explique la signification de l'état dans le graphique de réduction. Il fournit également des suggestions sur ce qu'il faut faire avec cela.

Quelques exemples décrits dans l'article:

Answer 11

C'est comme il se doit. Si votre graphique de burndown ressemble au graphique modèle, vous avez des problèmes. Le tableau vous aidera à savoir si vous pourrez vous engager et finir toutes les histoires.

La découverte d'histoires pendant le sprint aura toujours lieu. Dans l’idéal, vous seriez en mesure de concevoir et de déterminer les tâches à l’avance, mais si elles fonctionnaient, pourquoi une grande conception initiale ne fonctionnerait pas? Pour répondre à votre dernière question, la planification du sprint doit prendre au plus tard .