Débutant

[Agile France 2016] Démarrer un projet avec un Burnup incertain

logoCette année, au Chalet de la Porte Jaune, 280 personnes de tous les horizons se sont retrouvées dans ce cadre idyllique (et un peu trempé !), pour parler agilité et sujets connexes tels que le bien-être au travail, la motivation, la créativité… Un marathon de conférences toutes aussi intéressantes les unes que les autres, du partage et des échanges d’une richesse infinie.
Je vais tâcher, dans ce post, de vous retranscrire le BurnUp incertain présenté par Xavier Galleri.

Bon, et ce plan de production ?

Un client pressé, un budget réduit, une transition agile en cours… Tous les ingrédients réunis sont annonciateurs d’un début de projet assez sportif. Et évidemment, il faut prédire la date d’atterrissage. Car le sponsor réclame un PLAN DE PRODUCTION !
Un QUOI ? Une roadmap, dans le jargon.

Qui ne s’est pas déjà retrouvé dans cette situation ?

Attention, on ne va pas parler ici de la formule magique qui va permettre de donner, à la seconde près, la date de mise en production du projet. En revanche, Xavier propose des outils simples afin de concilier les habitudes avec les contraintes et l’Agilité.

Démarche incertaine en sprint 0

Imaginons que le périmètre de l’application, bien qu’incertain, permette déjà d’enrichir un backlog de features :

  1. On va faire une estimation approximative du backlog en Feature Points (FP).
  2. Admettons que l’on prenne les 3 premières features (qui vallent 5, 8, 8) pour en faire des User Stories. On les fait estimer par l’équipe, en Story Points (SP).
  3. Le delta entre le Feature Point et le Story Point va faire émerger des coefficients multiplicateurs par feature. Dans l’exemple, pour la Feature qui vaut 5 FP, les Users Stories associées sont estimées à 16 SP. On en déduit un coefficient de 3 (arrondi). On répète l’opération pour chaque autre feature du backlog.
  4. L’estimation incertaine des features va donc se tenir entre la somme des FP x coeff.min et la somme des FP x coeff.max. Ici, on a 114 FP au total, le coefficient minimum est 3 et le coefficient maximum est 5. Notre estimation incertaine sera donc comprise entre 114 x 3 pour la borne minimale et 114 x 5 pour la borne maximale.
  5. L’équipe doit ensuite établir 2 sprints planning fictifs avec les US (préalablement estimées), ce qui va permettre d’établir 2 vélocités.

schéma

Avec toutes les données estimées, voici à quoi ressemble un burnup chart incertain :

burnupIncertain

Les vélocités vont permettre de déterminer la date optimale de fin (croisement entre la plus grande vélocité et la plus petite borne) et une date pessimiste d’atterrissage (croisement entre la vélocité la plus petite et la borne la plus haute).
Cela va donc permettre d’avoir une première approximation sur la date de fin de réalisation.

Avantages et questions

Cet outil présente plusieurs avantages :

  • On échange sur la direction envisagée pour le projet avant le démarrage et on co-construit le burnup chart avec l’équipe. Je pense que c’est un premier pied à l’étrier de la collaboration qui peut avoir un impact positif. De plus, cela apporte de la transparence dès le démarrage du projet (on va préférer faire un burnup chart plutôt à la phase de cadrage).
  • On casse le mythe de la prédictibilité, on ne s’attache pas à une date, on observe une tendance.
  • On donne de la visibilité au plus tôt. Par exemple, si le projet doit aboutir dans 2 mois et que la date optimale de fin est à 4 mois, on est capable de dire que les 2 mois ne seront pas respectés avec ce périmètre initial.
  • On rapproche les parties prenantes, à savoir les clients, qui ont besoin de savoir quand le projet sera disponible, et l’équipe qui découvre le contenu du projet à venir.

Certaines questions émergent :

  • Peut-on s’engager sur un burnup chart incertain ?
    • ” On ne s’engage pas sur de l’incertain en Agilité “
  • Que faire si les résultats ne conviennent pas au client ?
    • ” On ne fait pas un burnup chart pour faire plaisir au client, mais pour lui fournir une estimation de date d’atterrissage “
  • Et si l’équipe n’y arrive pas ?
    • ” Le chemin est plus important que la fin, l’équipe aura un premier panorama du projet et c’est déjà bien. “
  • Faut-il maintenir le burnup chart incertain ?
    • ” Non! Il s’agit d’un outil préliminaire qui sera remplacé par l’outil de votre choix au sprint 0 “

Je suis repartie de la conférence avec un bel outil en poche, clair et efficace. Globalement, je pense qu’il permet de se rassurer, de donner de la visibilité à l’équipe sur le périmètre, et de la visibilité sur la date d’atterrissage au client. Il n’y a plus qu’à l’essayer !

Nombre de vue : 982

COMMENTAIRES 4 commentaires

  1. Adrien Piquot dit :

    Merci beaucoup à Xavier et à toi Lydie pour cet article.

    J’ai utilisé cet outil la semaine dernière avec une équipe, et ils ont été convaincus. C’était ça ou estimer tout le projet en jh après avoir demandé au PO d’écrire une EDB de 80 pages :).

    Bref, simple et efficace. Merci

  2. Med dit :

    SAlut,
    Merci beaucoup pour toutes les informations et les explications présentées par cet article.
    J’ai eu l’occasion à être un chef de projet de développement d’un logiciel et je veux adapter la méthode Scrum. Avec la lecture des articles publiés sur ce blog, j’ai pu avancer et vivre l’expérience, mais j’ai quelques questions si vous pouvez m’aider.
    comment faire pour la documentation du projet ?
    qui rédige les documents fonctionnels et techniques ?
    est ce que nous avons besoin d’un cahier des charges classique ?
    Merci.

  3. Pascal Poussard dit :

    Bonjour Med,

    Malheureusement il n’y a pas de réponse unique à cette question.
    En tant que coach Agile chez SOAT, j’ai tendance à recommandé le plus souvent de construire deux documents séparés :
    – Une documentation produit technique mise à jour par l’équipe de réalisation au fil des Sprints
    – Une documentation produit fonctionnelle mise à jour par le Product Owner après chaque livraison en Production.

    Cependant, cela dépend fortement des contraintes et du contexte de chaque projet.

    En ce qui concerne le cahier des charges, il s’agit simplement d’une forme d’expression de besoins qui peut très bien être remplacée entièrement par les User Stories.

    Encore une fois le contexte est très structurant dans l’expression des besoins. Pour aller plus loin, le mieux est d’échanger avec la communauté Agile parisienne ou de se faire accompagner par un coach Agile pour bien appréhender votre contexte précis.

  4. Med dit :

    Bonjour Pascal,
    je vous remercie pour la réponse.
    Oui je confirme votre avis pour l’accompagnement par un coach ou la réalisation d’une formation Agile Scrum, mais le problème que je suis installé en Tunisie.
    Y a-t-il la possibilité d’une formation à distance ou bien autres solutions ?
    Merci.

AJOUTER UN COMMENTAIRE