Top 7 des méthodes d’estimation agiles les plus populaires pour les user stories

Lorsqu’il s’agit d’estimation agile, vous ne pouvez pas vous empêcher de mentionner ses principes de base : utilisez des unités d’estimation relatives (telles que des points d’histoire), encouragez une discussion détaillée du contenu des histoires d’utilisateurs, formez un consensus et un engagement envers la solution, et améliorez l’équipe grâce à une collaboration cohérente.

De nombreuses équipes agiles autour de moi utilisent le « planning poker » pour estimer les points d’histoire. Bien que cette méthode soit populaire, elle a aussi ses limites.

Par exemple:

1. La fonction à estimer est trop grande, et il n’est pas facile d’estimer avec le « planning poker » ;
2. 300 histoires sortent;
3. La user story à estimer ne contient pas suffisamment d’informations pour référence ;
4. Le temps est compté, il n’y a pas de temps pour estimer la liste complète des demandes de produits.

Ainsi, cet article présente non seulement les méthodes d’estimation agiles les plus populaires « planning poker », mais également 6 autres méthodes d’estimation agiles pour répondre à tous vos besoins d’estimation de user story

1. Planification du poker

Tous les participants utilisent des cartes à jouer numérotées pour estimer l’histoire de l’utilisateur, votent anonymement lors de l’estimation, discutent s’il y a un gros désaccord, puis votent à nouveau, jusqu’à ce que toute l’équipe parvienne à un consensus sur l’exactitude de l’estimation. L’utilisation du poker planifié a des limites et convient mieux aux petites équipes (5 à 8 personnes) et à un petit nombre d’histoires d’utilisateurs (jusqu’à 10).

Astuce :  bien que ce ne soit pas une règle, il est fortement conseillé de décomposer les user stories dans le backlog produit en 13 points maximum ; afin que votre équipe puisse clairement comprendre les histoires d’utilisateurs au niveau de détails qui peuvent être facilement estimés.

2. Taille du tee-shirt

Utilisez la taille du T-shirt pour estimer la taille de la story de l’utilisateur : XS, S, M, L, XL. La taille de chaque taille représente la nécessité d’une discussion ouverte et honnête. Cette méthode est simple et rapide, et vous pouvez estimer la taille de la liste de demandes de produits de manière audacieuse.

Conseil : Cette méthode convient pour estimer la liste massive de demandes de grandes user stories, en particulier lorsque plusieurs équipes Scrum travaillent autour d’un produit.

3. Vote par points

Cette méthode convient à l’estimation de petites histoires d’utilisateurs, et la méthode elle-même est très simple et efficace. Le « vote par points » est un moyen de prendre des décisions, mais vous pouvez également l’utiliser pour estimer les user stories. La méthode est la suivante : chaque personne se voit attribuer quelques post-it, libre de choisir pour quelles user stories voter. Plus une user story reçoit de points, plus elle représente de volume.

Conseil : Cette méthode peut être utilisée dans les grandes comme dans les petites équipes, mais vous devez limiter le nombre de user stories estimées.

4. Le système de seau

Supposons que vous ayez un grand nombre de user stories à estimer et que vous souhaitiez accélérer l’ensemble du processus. En fait, vous recherchez une estimation plus efficace que le planning poker, alors le « système de seau pourrait être un choix souhaitable ».

Tout d’abord, configurez quelques « buckets » dans l’ordre séquentiel de « carte de poker de planification ». Ensuite, l’équipe écrit la user story à estimer sur le post-it et la place dans l’estimation du « bucket ».

3. Méthode en trois points

L’estimation en 3 points appartient au domaine de connaissance de la gestion du temps. Il peut également être utilisé lors de l’estimation des coûts. Le problème avec les estimations ponctuelles est qu’elles sont rarement correctes. Une estimation à trois points est une meilleure estimation qu’une estimation à un seul point.

L’estimation ponctuelle vous donne simplement un seul nombre – par exemple,

Développer :  Combien de temps faudra-t-il pour terminer la fonctionnalité de processus de commande ?

Quelle est la fiabilité de cette   estimation sur 5 jours ? Cela dépendra du développeur, et si cette tâche a déjà été effectuée ou non ? S’il s’agit d’une tâche de routine et qu’elle a été effectuée plusieurs fois, une estimation ponctuelle peut être la solution. Mais s’il s’agit de quelque chose qui n’a jamais été fait, ou s’il s’agit d’une nouvelle activité, ou si l’ingénieur est nouveau dans cette activité, ce nombre peut très bien être incorrect. Dans de tels cas, opter pour une estimation en trois points vous donnera plus de fiabilité.

L’estimation à trois points examine l’estimation la plus optimiste (O), une estimation la plus probable (M) et une estimation pessimiste (estimation la moins probable) ou (L).

6. Estimation d’affinité

L’estimation d’affinité consiste à trouver les similarités des user stories à estimer. La tâche de l’équipe est de regrouper les user stories similaires. La meilleure façon de « trouver une similarité » est de visualiser le processus et de combiner les sous-totaux en grands groupes.

Conseil : Cette méthode fonctionne mieux dans un petit groupe de personnes et un petit nombre de user stories, vous devez attribuer différentes estimations à différents groupes.

7 Méthode de tri

Cette approche vous permet d’avoir un jugement relativement précis de la taille relative de l’histoire de l’utilisateur. Si un petit groupe d’experts le fait, cela fonctionnera mieux.

Voici comment procéder : placez toutes les user stories sur une étiquette allant de bas en haut dans n’importe quel ordre, et chaque participant peut déplacer une user story sur l’échelle, en déplaçant une seule image vers le bas ou vers le haut pour chaque mouvement. Ou abandonner un tour. Répétez ce processus jusqu’à ce que tous les membres de l’équipe ne veuillent pas déplacer la user story ou abandonner un tour.

Conseil : Cette méthode de tri peut obtenir une estimation de la granulométrie fine, ce qui convient à de petits groupes de personnes et à un grand nombre de user stories.

Sommaire

Le but de cet article est de vous présenter l’existence de ces méthodes. Avant une utilisation quotidienne, vous devez essayer différentes méthodes en fonction de vos propres histoires d’utilisateurs et de la taille de votre personnel.

Si vous êtes intéressé par ces méthodes, veuillez laisser un message dans la section des commentaires. Je peux élaborer la ou les méthodes plus en détail dans un article séparé.

Autres articles dans Scrum Techniques et artefacts

• Que sont les artefacts Scrum ?
• Définition de Terminé vs Critères d’acceptation
• Qu’est-ce que la définition de Ready in Scrum ?
• Comment rédiger un objectif de sprint ?
• Qu’est-ce que le Product Backlog dans Scrum ? Qui en est responsable ?
• Comment affiner le backlog produit ?
• Qu’est-ce que le Sprint Backlog dans Scrum ?
• Comment hiérarchiser le backlog de produit à l’aide de la méthode MoSCoW
• Comment hiérarchiser le backlog produit en utilisant la méthode des 100 points ?
• Qu’est-ce qu’un objectif de sprint dans Scrum ?
• Qu’est-ce qu’un Burndown Chart dans Scrum ?
• Qu’est-ce que le modèle Rôle-Fonctionnalité-Raison ?
• Incrément de sprint vs produit potentiellement livrable vs MVP vs MMP
• Rédiger des objectifs SMART et INVESTIR pour les User Stories
• Qu’est-ce que DEEP dans le Product Backlog ?
• Comment rédiger une vision produit pour un projet Scrum ?
• Comment utiliser Scrum Board pour le développement Agile ?
• Qui crée des éléments de backlog produit ou des user stories dans Scrum ?
• Qu’est-ce que l’estimation agile ?
• Qu’est-ce que Story Point dans Agile ? Comment estimer une User Story ?