Discussion :

[randriano]

Bonjour,

En plein sprint, le développement de certains user stories se fait trop doucement donc il est plus ou moins certain que la plupart des user stories en attente dans le sprint backlog ne peuvent pas être finalisées. Donc, c'est sur qu'on va les déplacer dans le sprint suivant mais côté "Burndown chart", que se passe-t-il?

Le scrum guide est très vague sur cette situation à mon avis:
L'équipe de développement constate en cours de sprint qu'ils ne pourront probablement pas développer tous les user stories planifiée. Que devrait faire le Product Owner?
Réponse: Renégocier le Backlog Produit sélectionné avec l'équipe de dev pour atteindre l'Objectif de Sprint défini.

J'ai toujours gardé mon burndown chart comme suit dans ce cas-là, est-ce ça se fait?

[Marco46]

La complexité d'une US est une estimation. Une estimation n'est pas un engagement c'est une hypothèse. Il n'y a donc rien à négocier.

Pour moi les US non-terminées sont simplement reversées dans le sprint suivant, et on indique simplement le consommé au fil de l'eau et on touche pas à la complexité.

La burndown chart est un indicateur qui illustre le déroulement du processus de production logicielle, pas un but en soi.

Si l'équipe n'arrive pas à avoir une burndown chart "propre" c'est le symptôme de plusieurs problèmes potentiels :

- US trop grosses
- Estimations trop imprécises (ça se régule au fil du temps normalement)
- Workflow qui inclus trop de choses (interactions avec d'autres équipes qui ajoutent du délai, par exemple QA ou revue des PO).

le développement de certains user stories se fait trop doucement

Cette phrase n'a pas de sens en agile. Le développement se fait au rythme auquel il se fait. C'est le consommé, c'est un état de fait. L'estimation de la complexité n'est pas un engagement.

[randriano]

merci pour retour. Tout à fait d'accord avec ça "L'estimation de la complexité n'est pas un engagement.", c'est ça l'Agilité sans toutefois être partisan du #NoEstimates

Les US non-terminés sont donc reversés dans le sprint suivant (ou bien mis en standby pour reprendre dans le sprint d'après même) mais moi j'ai l'habitude de refaire leur ré-estimation pour le nouveau sprint car il y a souvent une mauvaise estimation d'où le fait que cela n'a pas pu être achevé dans le sprint prévu pour eux initialement. Cette ré-estimation, c'est dans la pratique Scrum?

[Marco46]

Je ne sais pas mais si tu ré estimes une US non-terminée tu vas flinguer tes stats, il y a des points de complexité qui vont disparaître d'un sprint à l'autre.

[randriano]

Au final, ce n'est pas si Scrum de ré-estimer.

Revenant à mon graphe burndown, le graphe en rouge doit toujours s'arrêter au zéro de l'ordonnée car les US non teminés reviennent dans le backlog produit. C'est la vélocité du sprint qui devient de valeur faible mais le graphe ne doit pas être comme cela.