Scrum Burndown Patterns

Question

Je fais partie d'une équipe de 10 personnes travaillant sur une base de code héritée importante avec un propriétaire de produit moins qu'idéale. Notre carnet de commandes est en très mauvais état et de grandes épopées ont souvent brisé nos sprints. L'équipe a aussi du mal avec sa définition du fait - certains membres écrivent religieusement un test unitaire, d'autres pas, parfois selon le temps disponible.

Donc, j'ai vu quelques modèles intéressants burndown, et je me demande qui d'autres modèles voient et ce qu'ils signifient.

Motif 1:

# 
# # 
# # # 
# # # #  
# # # # # 
# # # # # # 
# # # # # # # 

• explication positive: "All good."
• explication négative: «Trop beau pour être vrai Quelle est vraiment se passe? »

Modèle 2:

# 
# 
# # 
# #  
# # # # 
# # # # # 
# # # # # # # 

• explication positive: "Ce fut beaucoup plus facile que nous avons pensé, nous allons tirer dans plus d'histoires."
• Explication négative: ??

Motif 3:

# 
# # # # 
# # # # 
# # # #  
# # # # # 
# # # # # # 
# # # # # # # 

• explication positive: "Je ne sais pas sur ce travail d'abord, puis se révèle plus facile que nous le pensions"
• Explication négative: «Pas assez de progrès, arrêtons d'écrire des tests unitaires pour être« fini »à temps.

Answer 1

Ceci est reconnu autour de notre bureau comme le "Ah, merde! J'ai oublié à ce sujet." burndown:

# # # 
    # # # # 
    # # # # # 
    # # # # # # 
# # # # # # # 
# # # # # # # # 
# # # # # # # # 

Answer 2

Le motif 2 du côté négatif est "n'a pas estimé trop bien".

Voici quelques diagrammes de burndown que j'ai utilisés. Ignorer les images d'arrière-plan - ils sont là juste pour divertir les gens avec qui je travaille et n'ont rien à voir avec notre travail autrement. alt text http://www.atalasoft.com/cs/photos/techtalkgallery/images/16157/425x285.aspx

J'aime ce tableau. C'est très typique d'un bon tableau que nous commençons un peu lentement alors que nous nous débarrassons d'autres tâches, que nous nous arrêtons dans le travail, que nous sommes interrompus par d'autres choses et que nous poussons pour finir.

alt text http://www.atalasoft.com/cs/photos/techtalkgallery/images/16155/425x262.aspx

Dans ce tableau, nous avons commencé très régulièrement et a décollé effectivement terminé à l'avance.

alt text http://www.atalasoft.com/cs/photos/techtalkgallery/images/16156/425x264.aspx

Dans ce tableau, vous pouvez voir que nous avons commencé très généralement et une tâche qui semblait facile avéré être odieusement dur. Je pense que nous avons fini par arrêter ce sprint et en construire un nouveau.

Answer 3

Un problème avec burndowns est que les changements de périmètre sont mélangés avec les progrès par rapport portée.

Dans votre exemple 2, une explication possible est ... sainte fumée, je n'aurais probablement pas dû attendre la fin de l'itération pour commencer cette histoire/tâche risquée ... c'est beaucoup plus d'efforts que je ne l'imaginais! Dans l'exemple 3, vous avez peut-être ajouté plus tôt la portée ou découvert que le travail est plus important que prévu (par exemple, la tâche est estimée à 4 heures par jour, puis 4 heures par jour après 8 heures de travail). plus dur). Je préfère les burn-ups à burn-down pour cette raison ... il dissocie les changements de portée de la progression en deux lignes - une portée et un travail restant, de sorte que vous pouvez voir l'impact du changement de portée plus clairement.

Answer 4

Ici, il est souvent comme ça:

##### 
####### 
######## 
######### 
######### 
######### 
########## 

Positif: livraison à temps. Négatif: Les éléments de backlog trop importants ou trop d'éléments de backlog démarrés en même temps depuis le début.

Answer 5

Mon point de vue n'est pas de prendre au sérieux les graphiques burndown. Ils sont un indicateur. En fin de compte, il s'agit de savoir si vous avez terminé une histoire ou non.

Avez-vous des rétrospectives efficaces à la fin de vos sprints?

Les actions rétrospectives sont-elles suivies? Si vous constatez que les gens n'écrivent pas de tests unitaires religieusement, faites-les le faire (si tel est le standard de votre équipe). D'accord sur une définition commune de fait et respectez-le. Voir definition of done

Avoir un processus agile comme SCRUM nécessite une inspection et une adaptation constantes.

Pour moi, il semble qu'il y ait des problèmes, mais votre équipe ne résout pas ces problèmes. Si le propriétaire du produit n'est pas idéal, les problèmes liés à ce problème devraient apparaître dans vos rétrospectives afin que vous puissiez l'éviter lors du prochain sprint.

Si vous avez des épopées, vous pouvez toujours les décomposer, les redéfinir et les re-planifier.

Answer 6

En voici une que je n'ai pas encore vu. C'est arrivé lors de notre dernier sprint.

# 
## 
### 
##### 
############# 
################## 
################### 
#################### 

Il est le « nous avons fait mieux que les progrès attendus sur nos premières tâches, alors pensé étaient devançaient, relâchés, puis a dû pousser fort rattraper à la fin ou le risque de glisser une fonction. »

Leçon apprise: Les Burndowns sont excellents pour suivre les efforts passés, mais ne sont pas nécessairement représentatifs de vos progrès futurs.