Tout d’abord un grand merci à Guillaume, Bruno, Emmanuel et Christophe pour leur traduction du livre de Henrik Kniberg : « Scrum and XP from the Trenches ».
Même si je pratique l’anglais régulièrement la lecture d’un livre en Français est plus reposant qu’en anglais.
L’auteur parle plusieurs fois dans son livre de définir un « but » à l’itération comme un moyen pour :
- Garder l’équipe focalisée sur ce qui doit vraiment être délivré
- Communiquer simplement à l’extérieur de l’équipe sur ce qui va être réalisé durant l’itération
Je n’ai jamais essayé cette technique et je fais confiance à Henrik lorsqu’il dit qu’elle marche pour lui, mais je me demande s’il est vraiment réaliste de définir un but dès le début du planning de sprint. Cela ressemble à du PUSH et non du PULL – c’est à dire que l’on décide à priori ce qu’il faut faire sans se préoccuper de la capacité de production de l’équipe.
Par contre je ne remets pas en cause l’utilité de définir un but à l’itération comme outil de communication externe et de focus de l’équipe, mais il me semble plus agile de définir le but une fois le planning de sprint réalisé et l’estimation des tâches connues.
La différence vient surement du fait que chez Henrik, l’équipe utilise principalement le calcul des « user points » (qui me semble être parfaitement maîtrisé) comme un outil de définition du contenu de l’itération alors qu’ici nous découpons les stories en tâches estimée en heure et nous nous arrêtons lorsque le temps disponible de l’équipe est trop faible pour prendre une story supplémentaire. Cela permet donc à Henrik de définir un but « à priori » ce que nous sommes ici incapable de faire car nous n’avons pas encore mis suffisamment de focus sur ces aspects … toujours et encore quelque chose à améliorer.
Bref la lecture de ce livre m’a fait réfléchir et progresser … encore merci aux traducteurs 🙂
Bonjour Alexandre,
Histoire de prolonger un peu la discussion/réflexion :
Ça me semble être un héritage de la grande époque de l’itératif…
Tu trouveras la description de cette idée dans le « livre noir » (celui de Ken Schwaber et Mike Beedle), à partir de la page 50.
En gros : l’équipe va faire son possible pour atteindre un objectif fonctionnel, qu’elle va démontrer à la fin du sprint. Mais ça veut dire que les aspects non-fonctionnels (performances, ergonomie, …) eux sont plus variables (d’où la définition du « done » en terme de qualité).
Et c’est à ça que sert la démonstration à la fin du sprint : à permettre au Product Owner de décider s’il faut raffiner encore le produit, ou si ça fait plus de sens de le mettre maintenant aux mains des utilisateurs…
Bonjour Alex,
J’ai longtemps demandé à mes équipes de suivre la recommandation Scrum en définissant le but a priori. Ma conclusion est que souvent c’est une perte de temps, surtout si on a un planning de release.
Dans ton approche, tu comptes les heures au fur et à mesure de la découverte des tâches ? J’espère que tu leur laisses un peu de mou par rapport à leur temps disponible !
Oui, oui, nous laissons du « mou », mais fidèle à mes anglicismes, j’appelle cela un « buffer » 🙂
Nous pratiquons également le but d’itération.
En début de planification de sprint, le product owner donne un but à l’itération pour expliquer les priorités actuelles du haut du product backlog. En cours de planification, la confrontant des estimations à la capacité de l’équipe amène le product owner à reformuler le but de l’itération pour le rendre plus réaliste.
Ce but nous sert à prendre du recul sur les tâches à mener et à recentrer l’effort en cours d’itération pour maximiser le retour sur investissement.