Incertitudes et planification par vagues
Ça va être plus roll que rock, le rolling wave planning
Suite à mon billet d’hier sur Plan de release et incertitudes, j’ai reçu un commentaire qui m’amène plusieurs réflexions.
Mon lecteur commence à parler du schéma :
Le schéma est facile est 3 colonnes. L’incertitude cumulée sur 6-7 sprints (ex. release de 3 mois avec des sprints de 2 semaines) risque d’être très forte.
Avoir un plan de release comme ça, avec les incertitudes dans les prévisions, 3 sprints avant la fin de la release, c’est déjà pas mal. C’est à ce moment-là que c’est le plus intéressant pour prendre des décisions, pour déscoper ou reprioriser.
L’auteur du commentaire suggère que ce plan devrait aussi exister au début de la release, donc dans son cas, être fait au début du sprint 1 et montrer 6-7 sprints. Je pense qu’on peut souvent attendre pour élaborer ce type de plan. Mais bon, considérons que c’est nécessaire. Dans ce cas, l’incertitude sur le prochain sprint est à montrer, peut-être pour le suivant mais probablement pour tous les sprints.
Évidemment elle est à montrer à la fin de la release. Mais plutôt que de la représenter avec le type d’élément qu’on a utilisé sur le prochain sprint (par exemple la story), il est mieux de le faire avec des éléments plus gros (disons des epics, ou des features).
Pour l’horizon court du prochain sprint (2 semaines), on s’intéresse à des morceaux de petite taille, pour l’horizon plus lointain de la release (3 mois), les éléments sont plus gros. Cela reprend le principe de la planification par vagues qui roulent, en anglais rolling wave planning.
Mon lecteur dit aussi :
Mais ça pousse aussi à laisser un sprint de “stabilisation” comme tampon pour cette incertitude.
Dans le cas, suggéré par ce qu’il dit “release de 3 mois”, nous sommes dans la release à date de fin fixée (tous les 3 mois). Le plan avec sa marge d’incertitude ne pousse pas spécialement à allonger cette durée (en ajoutant un sprint). Il pousse à planifier selon la valeur en ajustant l’ordre des éléments et en réduisant la taille des gros éléments (lors de leur décomposition on élimine des parties qui ne sont pas essentielles).
Sprint de stabilisation, j’aurais pu l’ajouter à la liste des pratiques Scrum obsolètes… Mais je l’ai déjà fait en 2006.
