Histoire de référence
Une story de référence sert d'aide à une équipe dans le développement de produits agile pour estimer l'effort de travail d'une User Story à traiter. La story de référence est une User Story dont les exigences, la complexité et la mise en œuvre sont compréhensibles pour tous les membres de l'équipe. De cette façon, elle est utilisée pour l'estimation relative.
Comment les storys de référence sont-elles utilisées en Scrum ?
L'équipe examine d'abord l'effort de la story qui sert de référence, puis l'évalue avec les Story Points correspondants. Les nouvelles exigences sous forme de User Storys sont ensuite évaluées en relation ou en référence avec l'effort de cette story de référence. Si l'équipe Scrum estime que l'effort pour la mise en œuvre de la nouvelle User Story est plus élevé par exemple, celle-ci recevra plus de Story Points.
Pourquoi les storys de référence sont-elles utiles pour ton équipe ?
Scrum et d'autres méthodes agiles ne mesurent pas l'effort pour la réalisation des tâches en « jours-personnes » ou en temps de manière générale, mais en Story Points abstraits. La raison est que tous les membres de l'équipe et autres collaborateurs de l'entreprise doivent être conscients que les indications d'effort sont des estimations relatives et non des indications de temps concrètes. Les indications de temps précises et les estimations temporelles sont dans de nombreux cas bien trop imprécises pour obtenir des résultats pertinents. Grâce aux storys de référence et à la somme des points dans un Sprint, il est cependant possible, avec un peu d'expérience, de fournir une estimation adaptée de l'effort réalisable par équipe.
Comment se déroule l'estimation d'une User Story en relation avec la story de référence ?
Pour l'estimation d'une story en tant qu'élément du Product Backlog, on utilise en Scrum des cartes de poker spéciales pour ce qu'on appelle l'Estimation Poker (également appelé Scrum Poker ou Planning Poker). Cette estimation a lieu selon l'équipe généralement lors du Refinement ou du Sprint Planning.
Lors de l'Estimation Poker, chaque membre de l'équipe reçoit son propre jeu de cartes. Les membres tirent ensuite chacun pour soi simultanément la carte de poker avec le nombre de Story Points qu'ils estiment réaliste pour la mise en œuvre de la story. Pour cette estimation, ils s'orientent sur l'effort de la story de référence préalablement défini en groupe.
Après avoir révélé les cartes et discuté des éventuelles différences dans les estimations et des idées de mise en œuvre de la part des Developers, on voit si l'équipe souhaite encore consulter le Product Owner pour clarifier davantage les exigences de la story.
Conseil :
Des estimations d'effort très élevées de par exemple 40 ou 100 Story Points indiquent que la User Story peut être divisée en plusieurs storys.
Une fois l'estimation de la User Story terminée après un autre tour de Planning Poker, les Story Points estimés sont notés sur l'élément du Product Backlog en préparation du Sprint Planning.
Conclusion sur les storys de référence dans l'estimation agile
Lorsqu'une story bien estimable est utilisée comme référence, l'estimation des nouvelles storys par l'équipe se fait sur une base commune. C'est uniquement de cette manière que les membres peuvent s'approcher d'un effort estimé conjointement et s'engager plus tard dans le Sprint sur ces storys.
Les storys terminées dans un Sprint servent à leur tour au calcul de la Velocity (vitesse de travail de l'équipe), sur la base de laquelle les futurs Sprints peuvent être planifiés de manière pertinente.
