Discussion :

[randriano]

Bonjour,

Je gère des projets sous méthode Scrum mais je ne sais pas encore ce que prévoit vraiment la méthode sur
- les cas des tâches non terminées à la fin du sprint
- les stories déclarées terminées à un sprint se retrouvent avec un bug dans un sprint suivant
- story déclarée annulée que le vendredi matin avant la revue de sprint

Que faire?
- Reconduire la story dans le sprint suivant
- Créer une nouvelle story avec la mention version 2 par exemple
- Quelle est la conséquence de cette annulation sur le burndown chart?

et bien d'autres cas similaires ...

[Logan Mauzaize]

Je ne pratique pas Scrum mais voici comment je vois les choses :

les cas des tâches non terminées à la fin du sprint

Le RAF retourne dans le backlog. Elles feront peut-être l'objet d'une attention particulière pour l'élection au prochain Sprint mais (sur le principe) elles ne sont pas différentes des autres tâches du backlog.
Si le RAF est mineur (ex : 2 jours), est-ce qu'il ne conviendrait pas de repousser la fin du sprint ?

Ceci étant, dans le cadre d'un projet d'amélioration continue, il conviendra de bien étudier les raisons de ce retard : mauvaise estimation, mauvaise granularité, etc.

les stories déclarées terminées à un sprint se retrouvent avec un bug dans un sprint suivant

Cela génère une nouvelle tâche dans le backlog.

story déclarée annulée que le vendredi matin avant la revue de sprint

annulée car retirée du projet ou simplement annulé du sprint (ex: pour tenir un calendrier) ?

Quelle est la conséquence de cette annulation sur le burndown chart?

Une chute verticale : "X" quantité de travail en moins pour "0" produit/consommé, si c'est un retrait complet du projet. S'il s'agit simplement d'un retour au backlog : une ligne horizontale/rien du tout (la charge de travail reste la même, et rien n'a été consommé).
Bien sûr, c'est si on tient compte uniquement de la tâche en question. Sinon la courbe se lissera en fonction des autres activités.

[randriano]

Tes réponses me suscitent d'autres questions.

Est-ce que l'on peut repousser la date de fin d'un sprint?

Le RAF (reste à faire) retourne dans le backlog => qu'en est-il de la story correspondante? Créer une version 2 de la story?

Le RAF peut-il tout à coup augmenter? mardi: 8 - mercredi: 5 - jeudi: 9 car tout à coup il y a des difficultés

[Logan Mauzaize]

Est-ce que l'on peut repousser la date de fin d'un sprint?

Je pratique très peu l'agilité mais j'ose espérer qu'on peut s'adapter sinon cela n'a rien de très agile. Bien sûr il n'est pas question de repousser systématiquement, mais je pense qu'une marge de 20-25% me semble pas extraordinaire.

En revanche, cela ne doit pas être une habitude sinon cela veut dire que tout le planning (et le contrat ?) est faussé. Dans ce cas plutôt que de rajouter continuellement 3-5 jours, il vaut mieux prévoir moins par sprint en se gardant une marge de 2-4 jours.

Le RAF (reste à faire) retourne dans le backlog => qu'en est-il de la story correspondante? Créer une version 2 de la story?

J'aurais tendance à simplement découper la story. Si elle n'a pas pu être produite dans les temps, c'est qu'elle était trop grosse à la base. Il vaut mieux perdre 1-2j à bien découper le travail entamé et bien tracé le RAF (réécrire une nouvelle story).

Le RAF peut-il tout à coup augmenter? mardi: 8 - mercredi: 5 - jeudi: 9 car tout à coup il y a des difficultés

La force de l'agilité c'est la réactivité. Même sans être agile passer de 5j/h à 9j/h (unité supposé), c'est une forte charge qu'il faut absorber. C'est la réalité. La réaction la plus prudente étant de décider immédiatement (réunion improvisée) de ce que l'on fait. La réponse la plus sage sera de sacrifié 4j/h de tâches non démarrées pour terminer, proprement et assurément, ce qui est entamé ; ou bien, terminer ce qui peut l'être et créé une nouvelle tâche.

Il faut par contre bien garder à l'esprit que ces augmentations ne doivent pas être la normalité. C'est surement que les tâches ont été sous-estimées et/ou que la force de production a été surestimée. Il faudra donc réajuster l'estimation des tâches et de la force de production pour l'avenir (et donc le planning).

[Laurent 1973]

En effet, toutes stories non "done" au moment du Review Meeting retourne au backlog.
Et donc, elles ne sont pas comptabilisés dans le burndown: en résumé, l'équipe aura une vélocité de sprint plus faible.
Par contre, même si ces stories ont été commencés, on ne change pas leur valeur d'effort: celle-ci sera alors entièrement comptabilisée lorsqu'elles seront "done" dans un prochain sprint (qui alors aura probablement un vélocité plus forte)
=> Le burdown visualise alors bien l'effort sur le produit "livré"

Après, à la "Review", le PO aura pas le même discours si le but du sprint a changé ou pas avec ce retrait de stories (voir http://www.scaledagileframework.com/sprint-goals/).
Si celui-ce ne change pas, cela n'a pas d'incidence sur l'esprit du produit potentiellement livrable.
Si le but change, le produit n'a pas forcement de sens alors: conséquence possible sur de 'client' qui attendais la livraison => Là, le PO aura un travail de communication important.

Est-ce que l'on peut repousser la date de fin d'un sprint?

Pour moi, ce n'est pas une bonne solution de décalé la date de fin de sprint:

• Des personnes extérieurs ont pu être invité à la Review: difficile parfois de changer des agendas chargés.
• Des "clients" attendent cet incrément
• Mieux vaux être transparent au problème que de vouloir le "rustiner"
• La culture de l'erreur: l'erreur est humaine, on ne doit pas en avoir honte, mais apprendre à rebondir.
• Si on commence à repousser la date de fin de sprint, c'est une porte ouvert à beaucoup de dérive: on commence par 1 ou 2 jours, on fini avec des sprints sans durée officiel de plusieurs mois
• Est-ce que la qualité sera toujours la même sur une story fini à l'arrache à 22h la veille de la nouvelle Review ?
• On ne parle pas là de souplesse des réunions, mais du sens premier du développement logiciel: réaliser un produit de qualité en toute transparence
• Un sprint qui "merdouille" donne encore plus de valeur à un sprint qui "déchire grave"

=> On conserve la réunion de Review comme prévu où on expliquera à nos partenaires les problèmes rencontrés.

Par contre, dans ce type de cas, la rétrospective est un lieu très important pour comprendre pourquoi on a eu ce problème.
Attention, on recherche le pourquoi, pas le responsable: de toute façon, en Scrum, l'ensemble de l'équipe (développeur, SM et PO) sont responsables conjointement (au minimum, l'équipe n'a pas assez aider)
Et de là, on cherche ensemble une action pour que cela ne se reproduise pas.

Par contre, il existe toujours la possibilité d’interrompre un sprint en cours d’itération. (http://agileatlas.org/articles/item/...on-of-a-sprint)
Cette mesure d'exception peut être prise par le PO si l'orientation du produit change où si l'équipe s'est "planté" dans son Planning Meeting de début de sprint pour revenir sur une situation propre.
Mais alors, on reprend l'ensemble des RDV: Review, Retrospective + Planning Meeting.