Dans l’article d’aujourd’hui, nous abordons le sujet de l’Estimation et des Points d’Histoire dans Scrum. Créer des estimations dans Scrum aide à prédire la complexité et le temps nécessaire pour accomplir des tâches. En analysant le passé, l’ensemble de l’équipe Scrum prévoit collectivement ce que l’avenir réserve.

Par conséquent, plus l’équipe Scrum est expérimentée, plus ses estimations sont précises. L’équipe collabore également pour établir le temps estimé nécessaire à l’accomplissement des tâches lors de la Planification de 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 inclut des techniques et des outils pour faciliter un certain degré de certitude, et aujourd’hui nous les 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. Techniques d’estimation relative
  4. Résumé

Introduction

À chaque Planification de Sprint, le Product Owner présente de nouvelles User Stories à l’équipe. Le Product Owner les sélectionne dans le Product Backlog pour mise en œuvre dans le prochain Sprint. 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, estimation des exigences.

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 même des tâches très bien définies. De plus, le nombre d’heures nécessaires pour accomplir une tâche dépend de qui effectue la tâche, et de ce qui a été – ou n’a pas été – fait auparavant. C’est pourquoi Scrum utilise généralement des unités appelées Points d’Histoire.

L’Importance des Points d’Histoire dans Scrum

Chaque Équipe de Développement met en pratique la valeur d’un Point d’Histoire 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 de la Planification de Sprint, 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 en Points d’Histoire sans le contexte. Par exemple, si la première tâche se voit attribuer une valeur de 10, les tâches suivantes seront évaluées par rapport à celle-ci comme étant soit supérieures, soit inférieures. De cette manière, au sein d’un projet d’équipe Scrum, 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 même Équipe de Développement recevront un nombre similaire de points.

points d'histoire

Les Points d’Histoire sont des unités relatives. Cela signifie que :

  1. La valeur d’un Point d’Histoire ne concerne que les tâches effectuées par une équipe Scrum particulière. Les Points d’Histoire décrivent la vitesse d’accomplissement des tâches d’une équipe. En d’autres termes, une User Story estimée à 10 Points d’Histoire par l’Équipe A peut obtenir 50 par l’Équipe B. Cela est dû au fait que, comme nous l’avons mentionné, leur valeur est calculée relativement aux autres tâches effectuées par cette équipe et à leur expérience avec des tâches similaires.
  2. La valeur des Points d’Histoire complétés dans un Sprint ne peut pas servir de base pour comparer la performance de deux équipes Scrum. Afin d’éviter des erreurs dans la gestion des projets Scrum, il est important de se rappeler que la Vitesse d’une Équipe de Développement exprimée en Points d’Histoire réalisés dans un Sprint ne peut pas être utilisée pour comparer la performance de deux Équipes. Cela est dû au fait qu’elles pourraient réaliser le même travail dans des Sprints parallèles, que l’une des Équipes a estimé à 10 et l’autre à 50 Points d’Histoire.

Il ne faut également pas oublier que l’estimation contient de nombreux éléments inconnus et est faite sur la base de données incomplètes. Pour cette raison, les prévisions d’une Équipe Scrum très expérimentée peuvent parfois être très différentes de l’effort réel nécessaire pour accomplir une User Story.

Techniques d’estimation relative

Quelles sont les techniques d’estimation les plus efficaces dans Scrum ? Il n’existe 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 :

  • Planning Poker. Cette méthode relative la plus populaire prend un jeu de cartes pour calculer la quantité de travail nécessaire pour accomplir une tâche. Nous aborderons ses règles détaillées et son processus dans un article séparé.
  • Jeu d’Estimation d’Équipe. Celui-ci consiste à attribuer l’exécution de User Stories dans un Sprint donné avec des valeurs numériques appropriées sélectionnées dans la séquence de Fibonacci. Nous avons également consacré un article séparé à ce sujet.

Scrum, en revanche, rejette la méthode classique d’Estimation Absolue de la méthodologie traditionnelle de gestion de projet. La manière dont elle estime les tâches est de définir à l’avance les mois-homme, la durée et le coût de l’ensemble du projet. C’est un processus long, difficile à mettre en œuvre, et nécessite la participation d’experts qui ont tendance à établir la justification et le code de conduite, mais n’agissent pas nécessairement sur les tâches dont ils ont estimé la valeur. En d’autres termes, c’est non seulement fastidieux mais aussi très inefficace.

Estimation et Points d'Histoire dans Scrum

Points d’Histoire et Estimation – Résumé

L’estimation est une compétence très importante qui caractérise toutes les équipes Scrum matures. Estimer la quantité de temps et d’effort nécessaire pour accomplir des tâches individuelles est devenu le principal objectif de nombreuses techniques d’estimation relative telles que le Planning Poker ou le Jeu d’Estimation d’Équipe.

Les User Stories avec Points d’Histoire constituent une autre technique de mesure efficace que nous avons décrite, espérant fournir à nos lecteurs quelques 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 Points d’Histoire ne peut pas devenir la base pour comparer la vitesse de différentes Équipes de Développement.

Si vous aimez notre contenu, rejoignez notre communauté de travailleurs acharnés sur Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Caroline Becker

En tant que chef de projet, Caroline est une 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 pression font d'elle la meilleure personne pour transformer des projets compliqués en réalité.

View all posts →

Scrum Guide:

  1. Glossaire des termes, rôles et notions de base
  2. Qu'est-ce que Scrum ?
  3. Valeurs Scrum
  4. Comment mettre en œuvre Scrum dans votre entreprise ?
  5. Équipe Scrum - qu'est-ce que c'est et comment ça fonctionne ?
  6. Qui est un Product Owner ?
  7. Les erreurs les plus courantes du Product Owner
  8. Qui est le Scrum Master ?
  9. Les erreurs les plus courantes des Scrum Masters
  10. Quelles statistiques et métriques le Scrum Master devrait-il suivre ?
  11. Équipe de développement en Scrum
  12. Les erreurs les plus courantes des développeurs
  13. Artifacts Scrum
  14. Élargir Scrum
  15. Backlog de sprint
  16. Qu'est-ce que le Product Backlog ?
  17. Qu'est-ce que les User Stories ?
  18. Créer la meilleure User Story avec INVEST
  19. Les erreurs les plus courantes dans les User Stories
  20. Critères d'acceptation de l'histoire utilisateur
  21. Estimation et Points d'Histoire dans Scrum
  22. Planning Poker
  23. Jeu d'estimation d'équipe
  24. Définir l'incrément
  25. Événements Scrum
  26. Qu'est-ce qu'un graphique d'avancement ?
  27. Avantages et inconvénients du graphique de burndown
  28. Tableaux Kanban dans Scrum et Scrumban
  29. Vélocité en Scrum - Vitesse de l'équipe de développement
  30. Scrum quotidien
  31. Planification de Sprint
  32. Revue de Sprint
  33. Qu'est-ce qu'une rétrospective de sprint ?
  34. Erreurs courantes lors d'une rétrospective de Sprint
  35. Nourrir le backlog produit
  36. Comment créer et interpréter un graphique de burndown ?
  37. Qu'est-ce qu'un Sprint dans Scrum ?
  38. Coopération entre le Product Owner et le Scrum Master
  39. Engagements de l'équipe Scrum - Objectif produit, objectif de sprint et définition de la complétion
  40. Caractéristiques d'un bon Scrum Master