Product Owner agile

Ce que c'est

Une trousse de Product Owner : rédaction de user stories, critères d'acceptation, planification de sprint à capacité réelle, priorisation de backlog et suivi de vélocité.

Le générateur de stories part d'un epic et le découpe, en validant chaque story contre les critères INVEST : indépendante, négociable, porteuse de valeur, estimable, petite, testable. Il produit les critères d'acceptation dans la foulée et propose une estimation en points.

Quand le sortir

Quand votre backlog est fait de titres plutôt que de stories. « Améliorer le tunnel d'achat » n'est pas une story, c'est une intention : personne ne sait par où commencer ni comment savoir que c'est fini.

Et au moment de la planification de sprint, quand vous êtes sur le point de promettre plus que ce que l'équipe absorbe. La planification à capacité oblige à confronter l'ambition à la vélocité mesurée, ce que la discussion à main levée ne fait jamais.

Ce qu'il vous faut avant

Python pour le générateur, et une vélocité observée si vous voulez planifier. La vélocité de votre équipe, pas une moyenne trouvée en ligne : c'est un chiffre qui n'a de sens que localement.

Comment s'en servir

Écrivez l'epic tel que vous le comprenez, sans le découper vous-même, et laissez le générateur proposer les stories. Vous corrigez ensuite. C'est plus rapide que de découper de zéro, et le découpage proposé attrape souvent une story oubliée.

Les critères d'acceptation sont la partie à relire ligne à ligne. Ce sont eux qui décident si une story est finie, et une formulation vague fait revenir la discussion en fin de sprint, au pire moment.

Un critère INVEST vaut d'être surveillé plus que les autres : testable. Si personne ne sait dire comment vérifier une story, elle n'est pas prête à entrer en sprint, quelle que soit sa clarté apparente.

Ce que contient l'archive

1 outil, prêt à déposer dans votre projet :

• agile-product-owner