Nous avons dans l’article «SCRUM | Comment faire une estimation et une répartition des tâches ?» décrit le planning poker et présenté en terme de planification et de communication les avantages pour l’équipe projet et le PO. Dans cet article pour vous aider à bien déterminer le contenu de vos sprints, nous allons vous proposer deux techniques pour estimer l’éligibilité de vos user stories au prochain sprint.
L’estimation par intuition collective
Comme son nom l’indique, cette technique repose sur l’intuition de l’ensemble de l’équipe pour embarquer ou pas des user stories au prochain sprint.
En effet, les risques d’erreur dans une estimation basée sur l’avis d’un seul membre sont bien plus élevés que lorsque l’estimation se fait avec toute l’équipe. En équipe, la précision de l’estimation est grandement améliorée. Par exemple, lorsqu’une user story, obtient l’approbation de tous les membres de l’équipe pour être traitée dans un sprint, cela voudrait dire qu’elle ne souffre d’aucune ambiguïté. Par contre, en cas de désaccord lors des échanges, cette user story pourrait être mise de côté et traitée ultérieurement. Si la même user story n’obtient toujours pas l’approbation de toute l’équipe, elle pourrait être reportée à un autre sprint le temps de trouver un consensus.
L’estimation selon la vélocité de l’équipe
L’estimation intuitive étant qualitative, vous pouvez opter pour une estimation beaucoup plus quantitative. Une telle estimation se fait généralement en fonction de la vélocité (productivité) de toute l’équipe. Pour le faire, vous devrez vous appuyer sur les stories point qui ici, représenteront la charge de travail totale en terme de jour-homme acceptable pour un sprint. Par exemple : une user storie ayant une valeur de story point estimée à 30 nécessitera une équipe de 6 personnes pour être traitée en une semaine, (6 * 5 jours = 30 jours-hommes ).
Ainsi, pour déterminer la vélocité de votre équipe SCRUM, vous devriez dans un premier temps considérer le degré d’investissement de l’équipe de développement mais vous devriez également vous baser sur les résultats du sprint 0 en terme de nombre total de stories point absorbé sur la durée du sprint.
Il est vrai que la méthode agile insiste sur le fait que chaque équipe a ses propres caractéristiques, mais la vélocité peut être également estimée en fonction d’une autre équipe similaire si vous évoluez bien évidement dans un environnement avec différentes « Value Team ».
Une fois que vous avez déterminé le contenu de votre sprint et validé votre sprint backlog (liste des user stories retenues pour le sprint), il n’est pas recommandé d’y apporter des modifications dès lors que le processus de développement a démarré. Par conséquent, après chaque sprint planning, nous recommandons d’organiser un Kickoff ou d’adresser à l’ensemble de toute l’équipe un mail de notification symbolisant le Kickoff. Dans ce mail, vous pourriez annoncer le début des travaux de développement et par la même occasion annoncer qu’aucun ajustement ne sera possible durant cette période.
Si vous avez aimé cet article, donnez l’occasion à d’autres personnes d’apprendre en le partageant.
