Archive

Posts Tagged ‘gestion priorité carnet produit’

Faut-il réestimer les stories non terminées ou celles refusées par le PO à la fin du sprint?

June 3rd, 2010 6 comments

À maintes reprises ces derniers mois, j’ai dû répondre à la question qui tracasse beaucoup d’équipes et de Product Owner (PO) lorsqu’ils viennet d’échouer une ou plusieurs stories :

Faut-il réestimer les stories refusées lorsqu’on les prend dans l’engagement du sprint suivant?

Je demande alors ce qui fait sens pour eux. Quelle information tirent-ils de l’estimation d’une storie? Qu’est-ce qui serait le plus pertinent pour réussir le prochain sprint puisque le dernier vient d’échouer?

Les réponses varient bien évidemment, mais le plus important est alors de déclencher avec l’équipe une conversation autour de la notion de vélocité1, de son utilité, de son utilisation. Cette discussion ne fait pas l’objet du billet d’aujourd’hui mais j’y reviendrai éventuellement (au sens québécois du terme icon wink Faut il réestimer les stories non terminées ou celles refusées par le PO à la fin du sprint? ) dans un prochain billet.

burndown infrastructure 300x225 Faut il réestimer les stories non terminées ou celles refusées par le PO à la fin du sprint?

L'allure générale du burndown va varier en fonction de votre façon de gérer les stories échouées à la fin d'un sprint

Aujourd’hui je souhaite principalement partager ma pratique actuelle. Je dis actuelle car ma réflexion et ma préconisation ont évolué au cours du temps.

Actuellement, au moment de la planification d’un sprint, je préconise à l’équipe de réestimer les stories et de mettre à jour le backlog pour refléter l’effort nouvellement évalué. Cette façon de faire à les effets  suivants :

  • lisser la vélocité,
  • réduire le volume global du backlog, (sur l’instant bien entendu car j’exclus ici la création de story ou la réévaluation de story précédemment estimées, etc),
  • perdre l’historique de l’effort initialement estimé pour la story.

Dans le passé, je ne réestimais pas les stories au moment du sprint, l’équipe évaluait ou plutôt devrais-je dire pariait, comme pour un premier sprint, sur le ‘volume’ des stories qu’elle pensait être capable de réaliser. Cette façon de faire avait les effets suivants :

  • générer des fluctuations parfois importantes de la vélocité, pour finalement calculer une moyenne sur le long terme,
  • rendre l’engagement très aléatoire, l’équipe n’avait pas de repère (vélocité précédente) et pariait sur un engagement, comme lors d’un tout premier sprint,
  • conserver le volume du backlog tel qu’initialement estimé (sans faire entrer ici d’autres considérations telles que la réestimation des stories déjà estimées au cours des planifications de release précédentes, la division d’une story en plusieurs, la création de stories,…),
  • maintenir l’historique de l’effort estimé pour la story.

J’ai aussi vu une troisième méthode qui consistait à réestimer ‘oralement’ le reste-à-faire (en story points), mais sans mettre à jour le backlog. Cela permettait de prendre un engagement raisonnable car il incluait le nouvel effort estimé, mais l’engagement affiché était lui très généreux, reprenant l’effort estimé au sprint passé et non mis à jour!

Comme je vous le disais plus tôt la discussion autour de la notion de vélocité était intéressante. Pourquoi réestimer sans mettre le backlog à jour? Mystère! Un bon sujet pour un prochain billet. icon wink Faut il réestimer les stories non terminées ou celles refusées par le PO à la fin du sprint?

Afin de partager vos pratiques, je vous propose de répondre au sondage suivant. Et surtout n’hésitez pas à partager votre expérience en laissant un commentaire.

Comment gérez-vous les stories refusées par le PO lors de planification du sprint suivant?

  • Je réestime et réajuste le pointage au backlog et je m'engage par rapport à ma vélocité connue (57%, 27 Votes)
  • Je ne réestime pas les stories et je 'parie' sur l'engagement (15%, 7 Votes)
  • Je réestime "oralement" pour maîtriser l'engagement mais je garde le pointage inchangé au backlog (13%, 6 Votes)
  • J'utilise une autre méthode (15%, 4 Votes)

Total Voters: 47

loading Faut il réestimer les stories non terminées ou celles refusées par le PO à la fin du sprint? Loading ...
  1. La vélocité d’une équipe est le nombre story points du backlog brûlés pendant un sprint

Les points de visibilité en Scrum : comment choisir la longueur des itérations?

April 22nd, 2010 10 comments
point de visibilite 225x300 Les points de visibilité en Scrum : comment choisir la longueur des itérations?

Les points de visibilité en Scrum : comment choisir la longueur des itérations?

Choisir la longueur des itérations en Scrum est une décision délicate qui a son importance pour le bon fonctionnement de l’équipe et du projet. Il faut trouver le bon compromis entre un rythme soutenable pour l’équipe et la souplesse de pilotage des priorités par le propriétaire de produit.

Si la littérature originale de Scrum1 préconise des itérations d’une durée de un mois, la réalité est souvent différente. Depuis la publication du livre Agile Software Development with Scrum, les choses ont évolué et, dans la pratique, j’ai vu des équipes choisir des longueurs d’itérations allant de deux à six semaines, dans ce dernier cas peut-on encore parler de Scrum me direz-vous avec raison!

À chaque fois le choix est difficile, il demande un compromis entre la fréquence des points de visibilité2 offerte au propriétaire de produit (et aux parties prenantes du projet) et la capacité de l’équipe à livrer des incréments du logiciel en qualité production de façon récurrente. Ce choix peut aussi mettre en jeu bien d’autres facteurs, comme par exemple la capacité du propriétaire de produit ou des membres de l’organisation à suivre et ajuster l’horaire de plusieurs équipes.

Le choix de la longueur des itérations s’effectue souvent lors des rencontres de démarrage du projet, pendant la période de trois à cinq jours qui permet de bâtir l’équipe, de planifier et de lancer la première itération. De mon expérience, ce choix est souvent fait selon le schéma suivant :

  • Le propriétaire de produit propose la date de première livraison.
  • Le propriétaire de produit choisi un nombre de points de visibilité au cours de cette durée en fonction des différentes longueurs d’itérations possibles.
  • L’équipe et le propriétaire de produit négocie la durée la plus adaptée.

Par exemple, pour une livraison dans trois mois nous obtenons le tableau suivant :

Taille du sprint (en semaine) Nombre de points de visibilité
2 5
3 3
4 2
6 1

On se rend compte alors de l’importance de bien choisir la longueur des itérations pour un pilotage optimum du projet du point de vue du propriétaire de produit.

Cependant, la capacité de l’équipe à livrer des incréments du logiciel de qualité production doit être prise en compte. Et bien que livrer souvent puisse être difficile pour  les équipes, elles doivent aussi se rendre compte que c’est un avantage pour elles d’avoir l’occasion de s’ajuster en profitant des rétrospectives3, de négocier des engagements plus clairs et plus circonscrits avec le propriétaire de produit, de permettre l’entrée ou la sortie de personnes dans l’équipe, etc.

Pour ma part, mon choix va à des itérations de 2 semaines. Elles sont parfois difficiles à accepter pour des équipes débutantes en Scrum, mais je pense que c’est une durée intéressante pour ces équipes notamment. Cela leur permet de s’ajuster fréquemment, de comprendre ce qu’elles sont capables de livrer en peu de temps, de comprendre l’importance, par exemple, d’automatiser les tests ou bien le processus de déploiement. Cela permet aussi de créer une dynamique de construction d’équipe intéressante par le biais des rétrospectives qui reviennent vites et qui permettent ainsi de ne pas laisser ‘pourrir’ des problèmes tant que l’équipe n’est pas encore assez mature pour les traiter au fil de l’eau.

Et vous, vos itérations s’étalent-elles sur 1, 2, 3, 4 semaines? Plus encore?

Je suis curieux de connaître vos choix en matière de longueur d’itération ainsi que la logique qui y conduit, alors n’hésitez pas à laisser des commentaires icon smile Les points de visibilité en Scrum : comment choisir la longueur des itérations? .

  1. Agile Software Development with Scrum
  2. Un point de visibilité est la séquence des rencontres suivantes de Scrum : revue d’itération suivie de la planification d’itération. En effet, c’est le moment d’observer l’avancement de l’équipe et de réajuster les priorités en fonction des objectifs du projet.
  3. voir les billets suivants au sujet des rétrospectives :