Guide de mêlée | 23. Story Points et estimation dans Scrum

Dans l'article d'aujourd'hui, nous abordons le sujet de l'estimation et des points d'histoire dans Scrum. La création d'estimations dans Scrum aide à prévoir la complexité et le temps requis pour accomplir les tâches. En analysant le passé, toute l'équipe Scrum prévoit collectivement ce que l'avenir nous réserve.

Par conséquent, plus l'équipe Scrum est expérimentée, plus ses estimations sont précises. L'équipe collabore également à l'établissement du temps estimé pour terminer les tâches lors de la planification du sprint, en gardant à l'esprit qu'il ne s'agit pas d'un engagement final mais d'une prédiction. Sa précision dépend de nombreuses variables qui subissent constamment des changements imprévisibles et des circonstances inattendues. Heureusement, la méthodologie Scrum comprend des techniques et des outils pour faciliter un certain degré de certitude, et aujourd'hui nous en discuterons en détail afin que vous puissiez les comprendre et les appliquer immédiatement !

Points d'histoire et estimation dans Scrum - table des matières :

1. Introduction
2. L'importance des points d'histoire dans Scrum
3. Les Story Points sont des unités relatives. Cela signifie que:
4. Techniques d'estimation relative
5. Sommaire

Introduction

A chaque Sprint Planning, le Product Owner présente de nouvelles User Stories à l'équipe. Le Product Owner les sélectionne dans le Product Backlog pour les implémenter dans le Sprint suivant. Ensuite, les membres de l'équipe Scrum estiment conjointement la charge de travail nécessaire pour accomplir ce nouveau lot de tâches. Ce type d'affectation est une estimation, une estimation des besoins.

Il semblerait que la manière la plus simple soit de définir le temps nécessaire pour accomplir la tâche en heures ou en jours. Cependant, la pratique et les recherches menées depuis les années 1940 prouvent le contraire. Les humains sont incapables d'estimer avec précision le temps nécessaire pour accomplir des tâches, même très bien définies. De plus, le nombre d'heures nécessaires pour accomplir une tâche dépend de qui fait la tâche et de ce qui a - ou n'a pas - été fait auparavant. C'est pourquoi Scrum utilise généralement des unités appelées Story Points.

L'importance des points d'histoire dans Scrum

Chaque équipe de développement met en pratique la valeur d'un Story Point en s'appuyant sur l'expérience et la taille des tâches individuelles, c'est-à-dire en suivant le principe de l'empirisme. Le plus souvent, lors du Sprint Planning, le Scrum Master sélectionne un ou plusieurs échantillons de User Stories complétées, qui servent de point de référence pour déterminer la valeur des User Stories à développer.

C'est pourquoi vous ne pouvez pas attribuer de valeurs aux Story Points sans le contexte. Par exemple, si la première tâche est affectée d'une valeur de 10, les tâches suivantes seront évaluées par rapport à elle comme étant supérieures ou inférieures. Ainsi, au sein d'un projet Scrum Team, toutes les tâches du Product Backlog sont liées les unes aux autres. Cela signifie que des tâches similaires effectuées par une équipe de développement recevront un nombre similaire de points.

Les Story Points sont des unités relatives. Cela signifie que:

La valeur Story Point se rapporte uniquement aux tâches effectuées par une équipe Scrum particulière. Les Story Points décrivent la vitesse d'exécution des tâches d'une équipe. En d'autres termes, une User Story estimée à 10 Story Points par l'équipe A, peut en obtenir 50 par l'équipe B. En effet, comme nous l'avons mentionné, leur valeur est relativement calculée par rapport aux autres tâches effectuées par cette équipe, et leur expérience avec des tâches similaires. .

La valeur des Story Points complétés dans un Sprint ne peut pas servir de base pour comparer les performances de deux équipes Scrum. Afin d'éviter les erreurs dans la gestion des projets Scrum, il est important de rappeler que la Vitesse d'une Equipe de Développement exprimée en Story Points réalisés dans un Sprint ne peut pas être utilisée pour comparer les performances de deux Equipes. C'est parce qu'ils pourraient faire le même travail dans des Sprints parallèles, qu'une équipe a estimés à 10 et l'autre à 50 Story Points.

Il ne faut pas non plus oublier que l'estimation contient de nombreuses inconnues et est faite sur la base de données incomplètes. Pour cette raison, même les prédictions d'une équipe Scrum très expérimentée peuvent parfois être très différentes de l'effort réel nécessaire pour terminer une User Story.

Techniques d'estimation relative

Quelles sont les techniques d'estimation les plus efficaces dans Scrum ? Il n'y a pas de méthode unique qui fonctionne pour chaque équipe.

Parmi les techniques d'estimation au sein des méthodologies agiles, les plus courantes sont :

• Planification Poker. Cette méthode relative la plus populaire utilise un jeu de cartes pour calculer la quantité de travail nécessaire pour accomplir une tâche. Ce sont des règles et un processus détaillés que nous couvrirons dans un article séparé.
• Jeu d'estimation d'équipe. Celui-ci consiste à attribuer l'exécution des User Stories dans un Sprint donné avec des valeurs numériques appropriées sélectionnées dans la séquence de Fibonacci. Nous lui avons également consacré un article séparé.

Scrum, d'autre part, rejette la méthode classique d'estimation absolue de la méthodologie traditionnelle de gestion de projet. La façon dont il estime les tâches consiste à définir à l'avance les mois-personnes, la durée et le coût de l'ensemble du projet. Il s'agit d'un processus long, difficile à mettre en œuvre, et qui nécessite la participation d'experts qui tendent à établir la logique et le code de conduite, mais n'entreprennent aucune action qui ne réalisera pas nécessairement les tâches dont ils ont estimé la valeur. En d'autres termes, ce n'est pas seulement fastidieux mais aussi très inefficace.

Points d'histoire et estimation - Résumé

L'estimation est une compétence très importante qui caractérise toutes les équipes Scrum matures. L'estimation du temps et des efforts nécessaires pour accomplir des tâches individuelles est devenue l'objectif principal de nombreuses techniques d'estimation relative telles que Planning Poker ou Team Estimation Game.

Les histoires d'utilisateurs avec des points d'histoire sont une autre technique de mesure efficace que nous avons décrite, offrant, espérons-le, à nos lecteurs des outils pratiques. Cependant, il est important de garder à l'esprit que leurs chiffres ne concernent que les tâches particulières effectuées par l'équipe Scrum. Par conséquent, le nombre de Story Points ne peut pas servir de base pour comparer la vitesse des différentes équipes de développement.

Si vous aimez notre contenu, rejoignez notre communauté d'abeilles occupées sur Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Auteur : Caroline Becker

En tant que chef de projet, Caroline est experte dans la recherche de nouvelles méthodes pour concevoir les meilleurs flux de travail et optimiser les processus. Ses compétences organisationnelles et sa capacité à travailler sous la pression du temps font d'elle la meilleure personne pour concrétiser des projets complexes.

Afficher tous les articles

Guide de mêlée :

1. Glossaire des termes, rôles et notions de base
2. Qu'est-ce que Scrum ?
3. Valeurs Scrum
4. Comment implémenter Scrum dans votre entreprise ?
5. Scrum Team - qu'est-ce que c'est et comment ça marche ?
6. Qui est un Product Owner ?
7. Les erreurs les plus courantes du Product Owner
8. Qui est le Scrum Master ?
9. Caractéristiques d'un bon Scrum Master
10. Les erreurs les plus courantes du Scrum Master
11. Quelles statistiques et métriques le Scrum Master doit-il suivre ?
12. Coopération entre Product Owner et Scrum Master
13. Équipe de développement dans Scrum
14. Les erreurs les plus courantes des développeurs
15. Artefacts Scrum
16. Mise à l'échelle Scrum
17. Carnet de sprint
18. Qu'est-ce que le carnet de produit ?
19. Qu'est-ce qu'une User Story ?
20. Créer la meilleure User Story avec INVEST
21. Les erreurs les plus courantes de la User Story
22. Critères d'acceptation des user stories
23. Estimation et Story Points dans Scrum
24. Planification Poker
25. Jeu d'estimation d'équipe
26. Définition de l'incrément
27. Événements Scrum
28. Qu'est-ce que Sprint dans Scrum ?
29. Engagements de l'équipe Scrum - Objectif du produit, objectif du sprint et définition de l'achèvement
30. Qu'est-ce qu'un Burndown Chart ?
31. Comment créer et interpréter un burndown chart ?
32. Avantages et inconvénients du burndown chart
33. Tableaux Kanban dans Scrum et Scrumban
34. Velocity in Scrum - Vitesse de l'équipe de développement
35. Mêlée quotidienne
36. Planification des sprints
37. Revue de sprint
38. Qu'est-ce qu'une rétrospective Sprint ?
39. Erreurs courantes lors d'une rétrospective de sprint
40. Nourrir le backlog produit