Parfois, un travail inachevé n’est qu’une malchance ou un mauvais timing, mais certaines fois vous pourriez découvrir une chose qui est en train de tourner en mauvaise habitude.

#1 – Si vous voulez une garantie, achetez un grille-pain.

Mon premier conseil sur la façon de manager le travail inachevé est : Rappelez-vous  que même les meilleures équipes agiles ratent parfois leurs objectifs. C’est OK et même souhaitable dans une certaine mesure.

Les objectifs de sprint ne sont pas garantis. (Comme le dit le personnage de Clint Eastwood, Nick Pulovski, dans The Rookie, « Si vous voulez une garantie, achetez un grille-pain ! »). Les dirigeants, les parties prenantes et même l’équipe elle-même peuvent avoir besoin d’un rappel occasionnel à ce sujet.

L’engagement d’une équipe envers un objectif de sprint est une promesse de faire de son mieux pour atteindre cet objectif. Si les membres de l’équipe sont perpétuellement contraints de donner une garantie, ils garantiront moins pour être en sécurité.

Parfois, une équipe a besoin de donner une garantie. Il peut arriver qu’un client ait besoin d’une fonctionnalité à une certaine date. Le groupe financier peut avoir besoin d’exécuter des rapports de fin d’année au début du mois de janvier, par exemple.

En général, cependant, nous ne voulons pas forcer une équipe à donner une garantie. Nous demandons à une équipe de s’engager dans quelque chose de raisonnable, puis nous comprenons si elle n’y parvient pas. Ne pas réussir occasionnellement n’est pas un échec, c’est généralement un signe de malchance ou d’une équipe qui s’efforce d’en faire trop.

#2 – Ne reportez pas le travail au prochain sprint automatiquement.

Mon deuxième conseil est : Résistez à l’envie de reporter automatiquement le travail inachevé au prochain sprint. Mettez-le plutôt dans le backlog du produit.

L’item peut être de retour dans le backlog du produit pendant une milliseconde, mais le product owner doit décider consciemment de continuer à travailler dessus.

(D’un point de vue logistique, je me fiche qu’il soit plus facile dans l’outil de votre choix de déplacer l’élément vers le sprint suivant plutôt que vers le backlog du produit en premier. L’essentiel est qu’il y ait une vraie décision de poursuivre le travail.)

Si le Product Owner décide que l’équipe doit travailler sur l’élément partiellement fini immédiatement lors du prochain sprint, importez l’élément du backlog de produit tel quel. Ne le réestimez pas. Ne le renommez pas. Ne prenez pas de crédit de vélocité partielle. Il suffit de mettre l’élément dans le sprint suivant et de prendre le crédit complet lorsqu’il est terminé.

Mais si l’article est reporté à plus tard, allez-y et divisez l’histoire en ce qui a du sens. Prenez un crédit partiel de vélocité pour le travail que vous avez effectué lors du dernier sprint, puis rédigez une nouvelle histoire qui décrit uniquement les fonctionnalités manquantes et estimez cette histoire.

#3 – Documentez la cause.

Mon dernier conseil pour manager le travail inachevé est le suivant : A chaque fois qu’un travail est inachevé à la fin d’un sprint, l’équipe doit prendre le temps de la rétrospective pour déterminer si ceci était évitable.

Parfois, un travail inachevé n’est qu’une malchance ou un mauvais timing, comme un membre de l’équipe malade ou un problème découvert tard dans le sprint qui n’aurait pas pu être détecté plus tôt. Parfois, c’est juste le résultat d’une cible trop élevée pour un sprint.

Mais vous pourriez découvrir quelque chose qui devient une mauvaise habitude.

Quelle qu’en soit la cause, il est toujours utile de se demander si quelque chose peut être fait pour éviter que cela n’affecte les sprints futurs afin que votre équipe puisse réussir avec l’agilité.

Rejoignez 120 000+ autres personnes et recevez un petit conseil par semaine pour améliorer votre utilisation d’agile ou de Scrum directement dans votre boîte de réception chaque jeudi.