Comment limiter les dérives de délais et budget dans un projet Scrum

Dans cette vidéo, nous allons voir quels mécanismes on peut mettre en place, dans le cadre d’un projet Scrum, pour résister au maximum aux dérives de budget et de délais que l’on peut être amené à vivre sur un projet. Et vous allez découvrir que dans ce cas précis, les méthodes Agiles sont très efficaces.

Extrait de la formation « S’initier à Scrum et découvrir les méthodes Agiles »

Fonctionnalités et product backlog

Ce mécanisme repose sur un simple principe de troc. Au niveau du product backlog, dans lequel se trouvent des fonctionnalités triées et ordonnancées. En haut on place des fonctionnalités qui ont une forte valeur ajoutée et en bas, celles qui ont une faible valeur ajoutée et qui coûtent potentiellement chères. Elles sont symbolisées par des pouces représentant le ROI ou retour sur investissement, qui ne se chiffre pas forcément en euros. Il s’agit d’un rapport de la valeur ajoutée de chaque fonctionnalité sur son coût d’implémentation. Ce coût d’implémentation a été estimé par des séances de planning poker. La fonction A vaut 3 points, la fonction Y un point, la fonction C vaut 2 points, etc… On tire de toutes ces estimations une somme totale qui va nous permettre d’estimer le coût global de la release par exemple. C’est ce qui est illustré dans ce schéma.

Faire face à l’arrivée de nouvelles idées

Que se passe-t-il quand une nouvelle idée arrive en cours de route ? Et c’est ce qui arrive souvent au moment des revues de Sprint, puisque c’est le moment où les utilisateurs ou leurs représentants se projettent dans l’usage de l’application. Et bizarrement, c’est là que les idées viennent. Souvent de meilleures idées d’ailleurs, que celles qui étaient préalablement identifiées au démarrage du projet. Dans ce cas de figure là, ce qu’il se passe, c’est que l’équipe de développement accepte que de nouvelles idées arrivent en cours de route. Le product owner va alors expliquer son idée et l’équipe de développement va l’estimer. On voit ici que la nouvelle idée correspond à la fonction K et l’équipe de développement l’a estimée, elle vaut 3 points.

Un simple principe de troc

C’est le product owner lui-même qui va réaliser le principe de troc. C’est à dire qu’il va aller chercher dans son product backlog, et il va surtout regarder en bas de celui-ci, quelle est la fonctionnalité ou les fonctionnalités de faible valeur ajoutée, dont la somme fait au moins 3 points, et va retirer cette fonctionnalité là. C’est comme cela que l’on est résistant aux dérives de budget et de délais que l’on peut vivre sur un projet. C’est comme cela aussi que l’on peut maintenir l’équipe stable, puisque vous le savez peut-être, mais rajouter des développeurs dans une équipe est rarement une bonne solution. En effet, il va falloir faire monter en compétence ces personnes, cela va sans doute même réduire la vélocité des équipes à court terme. Et peut-être même la réduire à long terme si la personne a fait un mauvais casting. Et du coup, la ou les personnes recrutées ne conviennent pas au fonctionnement de l’équipe ou à la situation et au contexte. Voilà comment on peut mettre en place un mécanisme simple qui permet de résister au maximum aux dérives de délais et de budget sur un projet.