Série - Plan de release

Fil des billets - Fil des commentaires

Plan de release et incertitudes

Pour éviter qu'une prévision soit prise pour un engagement, il vaut mieux montrer qu'il y a des incertitudes dans le plan.

Un plan de release est souvent présenté en colonnes, comme on peut le voir dans ce schéma.

Le problème avec cette représentation, c'est qu'on ne voit pas l'incertitude. Et il y en a forcément. Qu'on ait fait des estimations ou pas, la prévision comporte une marge d'incertitude.

Une solution pour la montrer pourrait être de publier 2 plans : un optimiste et un pessimiste. Pas terrible : il faut regarder à deux endroits pour comprendre.

C'est mieux que la marge se voit au premier coup d’œil. Dans l'exemple où nos prévisions nous disent qu'on peut tabler sur 4 éléments finis dans un sprint dans le cas défavorable et sur 5 dans le cas favorable, voilà ce qu'on peut faire :

Plan de release avec incertitudes

L'idée est donc de mettre les éléments qui constituent la marge d'incertitude à cheval sur 2 colonnes (ou 2 bacs). Qu'en pensez-vous ?

C'est facile à faire avec des post-it. Par contre, avec iceScrum, Jira ou Trello…

Incertitudes et planification par vagues

Plan de release avec incertitudes

Suite à mon billet d'hier sur Plan de release et incertitudes, j'ai reçu un commentaire qui m'amène plusieurs réflexions.

Ça va être plus roll que rock.

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).

Planification par vagues qui roulent

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 (3mois), 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.

Backlog et plan de release fusionnés

Le plan de release peut être montré avec des incertitudes et des vagues. Les éléments qu'on y fait figurer sont tirés du backlog, on les trouve donc aussi dans les bacs.

Dans le cadre du management visuel, ces deux représentations sont utiles. Cependant il faut passer d'une l'une à l'autre, ne pourrait-on pas tout mettre dans une seule vue ?

Cela éviterait d'avoir à dupliquer les post-it…

On peut noter que le temps y est représenté différemment :

  • dans le plan de release, un élément A réalisé, ou prévu, après un élément B est à sa droite (ou en dessous si les 2 sont dans le même sprint)
  • dans les bacs, où on a une représentation de type Kanban (du flux), les éléments circulent de la gauche vers la droite. Un élément plus à droite est fini ou réalisé ou prévu avant un élément plus à gauche.

Dans une fusion, on inverse le temps dans le plan de relese : sprint 1 le plus à droite, dernier sprint le plus à gauche.

On garde les bacs et on colle les sprints du plan de release dessus :

plan de release dans les bacs

Dans cet exemple, nous sommes en train de finir le sprint 3. Pendant ce sprint, nous aurons fini 4 éléments. Nous en avions fini 3 dans le sprint 1 et 5 dans le sprint 2. Pour les prévisions des sprints suivants, nous utilisons la moyenne des sprints passés, soit 4 éléments par sprint. Il y a 5 éléments dans le bac de départ, nous ajoutons donc l'indication de fin de sprint 4 après le 4ème élément. Nous continuons dans le bac d'affinage pour le sprint 5. Dans ce bac, il y a aussi des plus gros éléments. Nous considérons qu'il sont deux fois plus gros. Sachant qu'il y a 8 sprints dans la release, le bac d'affinage est rempli avec la prévision de ce qu'on pense finir dans les 8 sprints.

L'objectif est de vider ce bac pour la fin de la release. Mais n'oublions pas qu'il y a des incertitudes dans les prévisions.

Bacs, prévisions et incertitudes

Après avoir unifié en une seule vue le backlog (et ses bacs) avec le plan de release, ajoutons-y les incertitudes.

Nous sommes dans le cadre d’une release dont la date de fin est fixée. Par exemple : elle se termine après 8 sprints, chacun de deux semaines. Nous sommes à la fin du 3ème sprint. On nous demande des prévisions sur ce qui sera fini pour cette release.

On pourrait faire des estimations et mesurer la vélocité. Mais nous allons suivre une approche de prévision sans estimations.

Du #NoEstimates.

Cette approche s'appuie du mesurage, du comptage et du découpage :

La mesure sur les sprints passés nous permet de prendre l’hypothèse suivante : nous allons réaliser 4 à 5 éléments par sprint. Nous avons des éléments prêts dans le bac de départ sur lesquels appliquer cette prévision.

Cependant, dans le bac d’affinage, nous avons des éléments de taille moins homogène. Dans le tableau ci-dessous nous faisons une hypothèse simple : les 6 gros éléments en fin de bac d’affinage sont de taille double des autres.

Voilà ce que donne cette vue avec incertitudes :

plan de release dans les bacs avec incertitudes

Dans un bac, l'élément en bas à droite est au premier rang, celui au dessus au deuxième, celui en haut à gauche au dernier. L'indication Release- constitue la prévision basse, le minimum de ce qui sera fini. L'indication Release+ représente la prévision haute, le maximum qu'on puisse finir.

Cette présentation avec incertitudes permet de :

  • s'assurer que tout ce qui est essentiel pour la release est bien inclus dans la prévision basse,
  • communiquer des prévisions facilement compréhensibles aux parties prenantes.

Bien sûr la pertinence de ces prévisions repose sur la capacité à décomposer les morceaux à la bonne granularité. Nous y reviendrons.