0

REX : Évaluer chaque sous tâche d’un sprint, bonne idée?

REX. Dernièrement j’ai observé dans mon entreprise une pratique qui ne se faisait pas avant sur les produits : estimer chaque sous tâche d’un sprint en point d’efforts. Auparavant les User Stories et les Bugs étaient estimés. Bonne pratique? On va voir, cela dépend vraiment de la demande initiale.

D’où vient cette nouvelle pratique?

C’est la première question à se poser. En effet, Scrum est basé sur l’empirisme et les événements Scrum ne sont pas là par hasard. A chaque sprint l’équipe va potentiellement s’améliorer en vivant des succès et des moments plus compliqués favorables à l’amélioration.

C’est notamment en rétrospective de sprint que des pistes d’amélioration vont être identifiées.

La où je veux en venir, c’est que toute modification dans les pratiques est bonne à prendre si elle vient de l’équipe elle même. Pour revenir à l’estimation des sous tâches d’un sprint, bien pourquoi pas si c’est l’équipe qui en éprouve le besoin? Après tout, cela fait partie de l’amélioration continue.

Là où les choses se compliquent et deviennent inappropriées c’est quand le changement vient de l’extérieur de la Dev Team (pour un sprint). Un manager, un Team leader, même un Scrum Master, qui impose cela sort de l’essence même de Scrum.

Les répercussions d’une telle pratique peuvent amener à une lourdeur dans le déroulé du sprint, une estimation faussée ou faite à la va-vite par l’équipe de réalisation (Dev Team), un déresponsabilisation de la Dev Team et un désengagement potentiel.

En pensant ainsi bien faire (estimations plus précise –> Meilleure atteinte d’objectif?), on produit potentiellement le résultat opposé : un manque d’implication de la Dev Team et un ralentissement dans le déroulé du sprint.

Et les effets?

Bien si l’équipe le demande, cela peut potentiellement les aider à mieux évaluer l’effort à fournir sur les tâches techniques.

Mais un bon découpage de tâches, sans estimation, suffit amplement suffisant. Par exemple tenir le principe qu’une tâche ne doit pas dépasser la journée de travail. Cela permet de partager une échelle et surtout d’avoir une belle dynamique d’avancement lors du Daily Stand up (le sprint “bouge”).

Jérôme CLET

Product Owner, Proxy PO au grès des projets, je travaille au service IT d'une grande Ecole de Commerce. J'ai grandement participé à l’émancipation des méthodes dites Agile dans mon contexte de travail. Plutôt que d'Agilité, je préfère amplement parler de "bon sens", tellement chaque cadre proposé répond à des évidences.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.