vendredi 21 décembre 2012

Story time

J'avoue, j'ai honte mais je n'ai découvert cette pratique que lors d'un cours avec Jeff McKenna à l'été 2012 et son utilité m'a frappé comme Mohamed Ali contre George Forman (c'est que ça ne nous rajeunit pas ma p'tit dame ...) 


Le Product Owner doit avoir une vision de son projet, une vue projetée loin dans l'avenir et il doit être capable de la partager avec l'équipe. C'est ce à quoi sert le Story time

L'idée de ce meeting d'une heure est de montrer à l'équipe les fonctionnalités qui arrivent. Pas celle qui arrivent pour le prochain sprint puisqu'elles seront présentées durant la première partie du poker planning, mais bien celle qui viendront plus tard

Qu'elle en est l'utilité ?




Motivation
Partager votre vision du produit avec l'équipe permet de la garder motivée car elle peut se projeter sur ce qui vient. Même si je n'aime pas l'idée, c'est une sorte de carotte, un teaser, le début d'effeuillage de la stripteaseuse.

Implication 
Cette notion rejoint la précédente, mais dans une équipe Scrum on ne veut pas de "pisseur de lignes". On veut des gens impliqués dans le projet, des experts qui se l'approprient. Or, on ne peut s'approprier un projet que si on en a une vue globale, pas une vue réduite.

Idées
Comme toujours, on est plus intelligent à 10 cerveaux qu'à 1. Donc présenter vos futurs fonctionnalités à l'équipe permet peut-être de faire émerger des idées que vous n'avez pas eu, aussi bien pour les futurs fonctionnalités que pour celles déjà développées. N'oubliez pas que l'équipe de développement connaît aussi bien que vous les fonctionnalités existantes et pas uniquement qu'en termes de code mais bien en termes fonctionnels.  

Planification d'une release
Le management veut toujours avoir une vision plus lointaine que celle des prochains sprint et c'est bien logique. C'est normal puisque le manager est responsable d'un portefeuille de projets et pas d'un seul projet. Ce story time est alors une excellente première présentation des fonctionnalités que nous demanderons à l'équipe d'estimer en terme de release et pas de sprint. Cette estimation ne se fait pas à cette occasion mais au moins ils ne découvriront pas ces besoins au dernier moment. 

Communication
C'est un peu mon cheval de bataille mais la communication reste la pierre angulaire d'un projet correctement mené. Sans elle c'est l'échec quasi assuré. Tout le monde travail pour construire le même objet. Il est donc le sujet principale et central des discussions projets. Il est dès lors normal que vous partagiez son avenir avec l'équipe.

Animer le PO
Une équipe PO qui doit présenter sa vision du produit doit d'abord réfléchir à cet avenir. Ceci permet donc de garder une partie de l'attention du PO sur autre chose que simplement le prochain sprint. Il lèvera peut-être un peu la tête du guidon et prendra de la hauteur. C'est toujours bénéfique. 

Quand  faire cette réunion ?
Jeff McKenna préconise d'en faire une par sprint. Attendez tout de même que cette fonctionnalité est assez mature pour ne pas être fondamentalement remise en question (une ou deux validation fonctionnel du concept par les stakholders). Cela évitera de refaire une présentation a chaque changement ou correction majeure. Rien n'est plus  usant pour l'équipe d'avoir 10 présentations différentes d'une même fonctionnalité.

Comment ça se déroule ?
A peu de choses prés cela se déroule comme lors de la présentation de nouvelles fonctionnalités durant un poker planning, à ceci près qu'aucune estimation n'est réalisée par la suite.
D'habitude nous limitons la durée de cette réunion à 1 heure. 
Un conseil : ne faites pas qu'une simple présentation, prévoyez une séance de questions-réponses avec l'équipe par la suite afin de déjà récupérer un peu de feedback.

Qui vient durant ce meeting ?
Dans notre projet c'est un meeting privilégier entre le Product Owner et la Team. L'idée est vraiment de partager la vision du produit entre eux.
Les stakeholder peuvent être éventuellement pour ajouter leur pierre à l'édifice de la communication, mais ils sont déjà au courant de l'avenir du produit puisque nous avons entrepris avec eux un ensemble d'atelier et d'études pour comprendre leur besoin.

Dans tous les cas je pense que c'est un bonne pratique a expérimenté. Si elle n'est pas primordiale pour le succès du projet, je pense qu'elle y contribue de manière significative en balisant le chemin loin devant l'équipe. 


Aucun commentaire:

Enregistrer un commentaire