Un outil de suivi visuel utilisé en gestion de projet pour représenter l’évolution du travail réalisé par rapport au périmètre total des travaux à accomplir, ce dernier pouvant varier dans le temps. Contrairement à d’autres représentations plus statiques, il met en évidence de manière explicite les modifications de la portée, ce qui en fait un instrument précieux dans les environnements où le changement est fréquent. On le rencontre principalement dans les approches agiles, mais sa logique peut s’étendre à tout contexte où l’on souhaite piloter un projet avec une visibilité claire sur l’avancement réel et les ajustements de périmètre.
Si l’on devait le résumer en une phrase, ce graphique affiche deux courbes essentielles : une ligne qui monte au fur et à mesure que l’équipe termine du travail, et une ligne, souvent irrégulière, qui indique la quantité totale de travail identifiée. La distance verticale entre les deux donne à tout instant une lecture immédiate du reste à faire. Ceux qui n’ont jamais vu un tel graphique le confondent parfois avec un simple indicateur d’avancement, mais sa spécificité est de contenir la mémoire des décisions de changement de périmètre, ce qui le rend bien plus informatif qu’un pourcentage de complétion isolé.
Tableau récapitulatif du graphique de burnup
| Concept | Synthèse |
|---|---|
| Définition | Le graphique de burnup est un outil visuel qui représente l’accumulation du travail achevé au regard d’un périmètre total susceptible d’évoluer en continu. |
| Usage agile | Issu des méthodologies agiles, il s’étend à tout projet requérant une visibilité fiable sur la progression et la gestion des modifications de périmètre. |
| Deux courbes | Il affiche une courbe ascendante du travail terminé, couplée à une courbe souvent irrégulière qui matérialise la quantité totale de travail identifiée à un instant donné. |
| Mémoire des décisions | Sa force est d’enregistrer chaque modification de périmètre, offrant un aperçu bien plus complet qu’un pourcentage d’achèvement statique. |
| Unités de mesure | L’axe vertical s’appuie sur l’unité d’estimation propre à l’équipe : points d’effort, heures idéales ou décompte d’éléments de travail. |
| Échelle variable | À l’échelle d’un sprint, il révèle que le périmètre a souvent été affiné en cours d’exécution, pratique fréquente même dans un contexte agile mature. |
| Origines | Le burnup est apparu pour pallier les limites du burndown chart, incapable de traduire lisiblement une extension de périmètre. |
| Atout clé | La visualisation du déplacement de la barre de périmètre améliore significativement l’interprétation des parties prenantes, ce qui accélère l’adoption de cet outil. |
Qu’est-ce qu’un graphique de burnup ?
La définition du graphique de burnup repose sur une double visualisation : d’un côté, le cumul du travail terminé, de l’autre, le périmètre global qui peut être révisé à la hausse ou à la baisse. Sur l’axe horizontal, on trouve le temps, généralement exprimé en jours, en sprints ou en itérations. Sur l’axe vertical figure une unité de travail cohérente avec la façon dont l’équipe estime ses efforts : des points d’histoire, des heures idéales, parfois un simple décompte de tickets ou de lots. La courbe du travail accompli part de zéro et progresse au fil des réalisations. La courbe du périmètre, elle, peut démarrer à une valeur initiale puis fluctuer chaque fois qu’une demande est ajoutée, retirée ou modifiée.
Ce mécanisme paraît simple, mais il contient une information que peu d’autres graphiques offrent de manière aussi directe : l’impact immédiat des changements de scope sur le reste à faire. Quand un Product Owner décide d’ajouter une fonctionnalité, la ligne de portée monte, et l’écart avec la ligne de travail accompli s’accroît, signalant visuellement que le chemin restant s’est allongé. À l’inverse, si l’on retire des éléments du backlog, la ligne de portée redescend, et la projection peut devenir plus favorable. C’est une conversation permanente entre ce qui a été demandé et ce qui a été livré, sans perdre la trace des décisions passées.
Une idée reçue consiste à croire que le graphique de burnup est exclusivement réservé au niveau d’une release ou d’un projet. En réalité, il peut s’appliquer à une échelle plus fine, comme un sprint, surtout lorsque l’on souhaite montrer qu’un sprint a vu son périmètre ajusté en cours de route, ce qui est plus fréquent qu’on ne le pense dans les contextes agiles matures. La plupart des équipes qui l’utilisent à ce niveau le font pour éviter l’effet pervers d’un burndown qui devient ininterprétable après un ajout de tickets en milieu d’itération. Le caractère explicite du burnup lève toute ambiguïté.
L'essentiel du graphique de burnup
- Double visualisation du travail
- Le burnup affiche simultanément l’avancement réel cumulé et l’évolution du périmètre total, rendant visibles les ajustements de scope en cours de projet.
- Axes temps et unité de travail
- L’axe horizontal matérialise le temps écoulé (jours, sprints ou itérations) et l’axe vertical quantifie le travail (story points, heures idéales ou nombre de tickets), offrant une lecture immédiate de la progression.
- Visibilité sur les changements de scope
- La distance entre la courbe de périmètre et celle du travail réalisé traduit directement l’effet des ajouts ou retraits de fonctionnalités sur l’effort restant, fournissant une alerte précoce sur les dérives potentielles.
- Utile à l’échelle d’un sprint
- Lorsque le périmètre change en cours d’itération, le burnup conserve une lisibilité totale tandis que le burndown devient ininterprétable, ce qui en fait un indicateur de référence dans les contextes agiles matures.
Origines et contexte d’émergence
Retracer les origines du graphique de burnup revient à plonger dans l’histoire du pilotage visuel des projets, bien avant que les méthodes agiles ne formalisent leur boîte à outils. On trouve des ancêtres conceptuels dans les courbes en S de la gestion de la valeur acquise, où l’on superposait déjà une courbe de valeur planifiée et une courbe de valeur acquise pour suivre l’avancement. Mais le burnup agile a émergé précisément pour répondre à une limite des burndown charts, très populaires au début des années 2000 avec la montée de Scrum : ces graphiques descendants ne savaient pas exprimer proprement une augmentation du périmètre, car une remontée de la courbe pouvait être interprétée comme une perte de progression plutôt que comme un ajout légitime.
Les premières communautés agiles, notamment autour de l’Extreme Programming puis de Scrum, ont commencé à échanger sur l’intérêt des graphiques affichant à la fois la complétion et le périmètre total, sous des appellations variées comme « scope tracking chart » ou « feature burnup ». Petit à petit, l’idée s’est diffusée, portée par des praticiens qui constataient que les parties prenantes comprenaient bien mieux la situation lorsqu’elles voyaient la « barre » du périmètre se déplacer. En France, le terme « graphique de burnup » s’est installé naturellement, même si l’on entend parfois « diagramme de burnup » ou « courbe d’avancement avec périmètre variable ». L’essentiel est que l’outil est aujourd’hui intégré à la plupart des logiciels de gestion de projet agiles.
Composants clés d’un graphique de burnup
Les composants du graphique de burnup sont peu nombreux, mais chacun joue un rôle précis dans l’interprétation de la trajectoire du projet. L’axe horizontal représente toujours une dimension temporelle linéaire, que ce soit le numéro de sprint, la date calendaire ou le jour de l’itération. L’axe vertical porte l’unité de travail retenue, qui doit rester stable pour que la lecture reste cohérente dans le temps ; changer d’unité en cours de projet, par exemple passer des points d’histoire aux heures, rendrait les comparaisons illusoires. La première courbe, celle du travail accompli, est souvent appelée tout simplement « burnup ». Elle ne peut que croître, ou au pire stagner, mais jamais diminuer. La seconde courbe, celle du périmètre total, est parfois nommée « scope line » ou « ligne de portée ». Elle fluctue en fonction des ajouts et retraits validés par le responsable du produit ou le comité de pilotage.
À ces deux courbes de base s’ajoute souvent une ligne de tendance, qui prolonge la pente du travail accompli jusqu’à la ligne de portée, donnant une date de fin probable si les conditions actuelles se maintiennent. Cette projection est purement mécanique : elle repose sur l’hypothèse forte que la vélocité future sera identique à la vélocité passée et que la portée ne bougera plus. En pratique, c’est une hypothèse forte, mais elle a le mérite de lancer la discussion. Quand la ligne de tendance glisse vers la droite à cause d’une hausse de la portée, cela ne signifie pas encore que le projet dérape, mais que les choix de périmètre ont un coût temporel visible par tous.
Il est crucial de noter que la qualité d’un graphique de burnup dépend entièrement de la rigueur avec laquelle la ligne de portée est maintenue. Si l’on oublie d’y reporter les suppressions de fonctionnalités, on donne l’impression d’un gonflement incontrôlé. Si l’on n’y inscrit pas les ajouts validés, on entretient une illusion de stabilité. Dans les deux cas, le graphique perd sa valeur de pilotage et devient un simple élément de décoration. C’est pourquoi beaucoup d’équipes désignent explicitement un rôle, souvent le Product Owner ou le Scrum Master, pour mettre à jour la portée avant chaque revue de sprint.
Enfin, certains burnups intègrent une troisième courbe représentant les estimations initiales ou un périmètre contractuel de référence. Cela permet de montrer l’écart entre l’engagement de départ et la réalité mouvante du besoin, sans culpabiliser personne. Cette variante est particulièrement appréciée dans les relations client-fournisseur où la transparence sur les évolutions est un facteur de confiance.
Points essentiels sur les axes et courbes
- Axe horizontal temporel
- L'axe horizontal matérialise une progression temporelle linéaire, qu'il s'agisse du numéro de sprint, d'une date calendaire ou du jour d'itération.
- Axe vertical et unité de mesure stable
- L'axe vertical représente l'unité de mesure de l'effort, dont la stabilité garantit la comparabilité des données dans le temps.
- Courbe du travail accompli
- La courbe de travail accompli, souvent appelée « burnup », reflète les variations du périmètre validées par le Product Owner ou le comité de pilotage.
- Ligne de tendance prédictive
- La ligne de tendance extrapole la pente du travail accompli jusqu'à la ligne de portée, fournissant une prévision de date de fin sous l'hypothèse d'un rythme constant.
- Projection et mise à jour de la portée
- La projection postule une vélocité future égale à la vélocité passée, et la mise à jour du périmètre incombe à un rôle dédié comme le Product Owner ou le Scrum Master, qui doit l'actualiser avant chaque revue de sprint.
Le graphique de burnup dans les principaux référentiels de gestion de projet
Approche PMBOK
Le PMBOK du Project Management Institute ne mentionne pas le graphique de burnup en tant qu’artefact spécifique, mais son utilisation s’inscrit parfaitement dans les processus de surveillance et de maîtrise, en particulier dans la gestion de la portée et du calendrier. La façon dont le burnup en gestion de projet s’intègre dans le référentiel se comprend à travers le prisme des représentations graphiques de l’avancement. Le guide reconnaît l’utilité des diagrammes d’avancement et des courbes de tendance pour comparer le travail accompli au référentiel de mesure des performances. Un chef de projet évoluant dans un cadre prédictif pourrait utiliser un burnup pour suivre l’avancement des livrables par rapport à la structure de découpage du projet, à condition d’accepter que le périmètre total puisse être révisé via le processus de maîtrise intégrée des modifications.
Dans une approche hybride, le graphique sert de pont entre le vocabulaire des sponsors habitués aux courbes d’avancement classiques et la réalité itérative des équipes. On peut le présenter comme une évolution pragmatique des diagrammes de Gantt ou des courbes en S, sans bouleverser les attentes.
Approche PRINCE2
PRINCE2 met l’accent sur le contrôle par lots et le pilotage par exception. Le graphique de burnup n’y est pas un produit de management prescrit, mais il peut trouver sa place comme outil de suivi dans un rapport de point d’étape ou de fin de séquence. Le principe d’une ligne de portée variable entre en résonance avec la notion de tolérance sur le périmètre qui peut être accordée par le comité de pilotage. Plutôt que de figer une ligne de référence inatteignable, le burnup donne une image dynamique qui facilite les décisions d’escalade. Toutefois, son usage reste plus informel que dans les contextes agiles, car PRINCE2 préfère structurer les écarts par des rapports d’exception et des demandes de modification documentées.
Approche Agile et Scrum
C’est dans les environnements agiles, et singulièrement dans Scrum, que le graphique de burnup trouve son terrain de prédilection. Il y est utilisé comme une alternative ou un complément au burndown de release, souvent pour fournir une vision plus honnête des variations de backlog produit. Les équipes Scrum matures constatent que l’affichage de la portée totale lors des sprints reviews génère des discussions plus riches avec les parties prenantes : on ne parle plus seulement de ce qui a été fait, mais de ce que les nouveaux besoins impliquent pour la date de fin. Kanban, de son côté, peut tirer profit du burnup pour suivre l’épuisement d’une classe de service ou l’avancement d’un epic, en comptant le nombre d’éléments terminés par rapport à un total fluctuant.
Perspective BVOP
Dans la méthodologie Business Value-Oriented Project Management, le graphique de burnup s’intègre naturellement à la philosophie de transparence et d’acceptation du changement. BVOPM part du principe que les modifications de périmètre constituent un retour utilisateur et non une déviation malvenue par rapport à un plan initial. Visualiser ces modifications sur la ligne de portée permet de les traiter comme une information de pilotage et non comme une source de tension. La pratique des points d’effort relationnels, préconisée par BVOPM, se couple bien avec la logique du burnup pour ajuster les projections sans dégrader la confiance entre l’équipe et les décideurs.
Différences entre graphique de burnup et graphique de burndown
Comprendre la différence entre burnup et burndown est probablement l’étape la plus importante pour qui découvre ces outils. Un burndown chart représente le travail restant sous forme d’une courbe descendante qui doit idéalement atteindre zéro à la fin de la période. C’est un compte à rebours visuel. Le problème surgit lorsque l’on ajoute du travail en cours de route : la courbe remonte, ce qui donne l’impression que l’équipe a « perdu » du terrain, alors qu’elle a simplement vu sa cible augmenter. Le burndown mélange donc dans une seule ligne la progression réelle et les changements de périmètre, rendant l’interprétation délicate quand le backlog n’est pas parfaitement stable.
Le burnup sépare ces deux dimensions. La ligne de travail accompli ne redescend jamais, ce qui évacue toute frustration visuelle liée aux ajouts. Un chef de projet peut ainsi montrer à son sponsor : « Nous avons livré 80 points d’histoire, c’est notre production réelle. Si la date cible vous semble s’éloigner, c’est parce que vous avez demandé 20 points supplémentaires, comme vous pouvez le constater sur la ligne de portée. » La conversation se déplace du blâme vers l’arbitrage. En ce sens, le burnup est un outil de négociation et de transparence, là où le burndown peut devenir un outil de pression mal calibré.
Il ne faut pas en conclure que le burndown est obsolète. Pour un sprint court dont le périmètre est verrouillé, le burndown reste parfaitement lisible et très simple à interpréter au quotidien. Mais dès que l’horizon s’allonge et que la stabilité du périmètre n’est plus garantie, le burnup prend l’avantage. Beaucoup d’équipes utilisent d’ailleurs les deux : un burndown pour le sprint, un burnup pour la release. Cette complémentarité reflète une maturité dans le choix des indicateurs plutôt qu’un dogmatisme.
Synthèse des différences essentielles
- Burndown, un compte à rebours visuel
- Le burndown chart figure le travail restant sous forme d’une courbe décroissante destinée à atteindre zéro en fin de période, mais sa ligne unique confond les progrès réels et les variations de périmètre, ce qui complique l’interprétation dès que le backlog évolue.
- Burnup, un outil de transparence
- Le burnup distingue la courbe du travail accompli, qui croît sans jamais régresser, de la courbe d’étendue des travaux, offrant ainsi au chef de projet un moyen de démontrer au sponsor que le report de la date cible découle directement des points ajoutés.
- Choix selon la stabilité du périmètre
- Pour un sprint court au périmètre strictement verrouillé, le burndown assure une lecture quotidienne limpide et fiable ; en revanche, face à un backlog instable, le burnup devient l’outil de choix pour étayer les négociations et préserver la dynamique de l’équipe.
Applications pratiques et scénarios d’utilisation
L’utilisation du graphique de burnup se décline d’abord au niveau de la release, où il devient un tableau de bord de pilotage pour le Product Owner et les parties prenantes. Imaginons une équipe qui a estimé son backlog initial à 200 points d’histoire et qui maintient une vélocité moyenne de 20 points par sprint. Après cinq sprints, elle a livré 100 points. Si la portée totale n’a pas bougé, le reste à faire est de 100 points, soit une projection de cinq sprints supplémentaires. Si, au même moment, le Product Owner a validé 40 points de nouvelles demandes, la ligne de périmètre passe à 240, et la projection monte à sept sprints. Le graphique affiche clairement le déplacement de la ligne de portée, ce qui ancre la discussion sur les arbitrages.
Au niveau d’un sprint, le burnup peut être utilisé lorsque l’équipe accepte des ajustements de dernière minute pour maximiser la valeur livrée. Certaines équipes en sprints souples, notamment en Kanban ou en Scrum avec une tolérance sur le périmètre de sprint, remplacent le burndown par un burnup pour éviter toute confusion lors du daily stand-up. L’effet psychologique n’est pas neutre : voir une courbe de travail accompli qui grimpe chaque jour est souvent plus motivant que de regarder une ligne qui stagne ou remonte.
Dans les programmes agiles à grande échelle, le burnup peut être agrégé pour plusieurs équipes, à condition d’harmoniser les unités de mesure. On obtient alors une vue consolidée de l’avancement par rapport à un périmètre global, où chaque ajout ou retrait au niveau d’une feature team est répercuté. C’est un exercice délicat, qui demande une gouvernance de la mesure rigoureuse, mais il offre aux responsables de programme une lecture instantanée des tensions entre la demande et la capacité de production.
Enfin, dans un contexte de relation contractuelle agile, le burnup sert d’outil de communication contractuel. Plutôt que de figer un périmètre ferme dans un avenant, le client et le fournisseur peuvent suivre ensemble l’évolution du besoin et ses conséquences sur la trajectoire, ce qui facilite la renégociation continue prônée par les approches agiles. Cela n’empêche pas la dérive, mais rend la dérive visible et assumée.
Avantages et limites du graphique de burnup
Parmi les avantages du graphique de burnup, le premier est sans doute sa capacité à désamorcer les conflits liés aux changements de périmètre. En montrant que la productivité de l’équipe n’est pas en cause, il recentre le dialogue sur les choix stratégiques. Il apporte aussi une transparence rare dans les projets où le scope creep est une source d’irritation majeure. Les parties prenantes peuvent visualiser en un coup d’œil si la hausse du périmètre est le fait de décisions assumées ou d’une dérive incontrôlée. Il constitue enfin un excellent support pour les revues de sprint et les comités de pilotage, car il ne nécessite pas de compétences techniques particulières pour être lu.
Mais le graphique de burnup a aussi des limites qu’il serait imprudent d’ignorer. La principale tient à la mise à jour de la ligne de périmètre, qui exige une discipline de backlog grooming constante. Si le carnet de produit n’est pas affiné régulièrement, la ligne de portée devient obsolète et le graphique inspire une fausse confiance. Une autre limite concerne la nature du travail mesuré : le burnup additionne des points d’effort ou des tickets sans distinguer leur valeur métier réelle. Terminer beaucoup de petits éléments peu valorisés donne une courbe ascendante rassurante, alors que la valeur livrée peut rester modeste. Cet effet de « volume sans valeur » doit être compensé par d’autres indicateurs.
Il existe également un risque de surinterprétation de la ligne de tendance. Comme toute extrapolation linéaire, elle suppose un avenir stable, ce que les projets agiles contredisent par nature. Les équipes doivent donc l’utiliser comme une hypothèse de travail, et non comme un engagement. Enfin, dans des environnements très réglementés ou prédictifs purs, le burnup peut sembler trop informel et peiner à se faire accepter par des instances de gouvernance habituées aux diagrammes de Gantt et aux courbes d’avancement avec ligne de base fixe.
Synthèse des avantages et limites
- Désamorçage des conflits de périmètre
- En démontrant que la productivité de l’équipe n’est pas remise en cause, le burnup replace les débats sur les décisions stratégiques qui motivent les évolutions du périmètre.
- Transparence sur le scope creep
- Les parties prenantes discernent immédiatement si l’élargissement du périmètre provient de choix volontaires et documentés ou d’une dérive incontrôlée du scope.
- Support accessible pour les revues
- D’une lisibilité immédiate, le graphique constitue un support privilégié pour les revues de sprint et les comités de pilotage, sans aucune exigence de compétence technique.
- Discipline de backlog grooming indispensable
- Sans un affinage régulier et rigoureux du backlog, la courbe de périmètre devient vite obsolète et le graphique peut instaurer une confiance illusoire dans l’avancement.
- Valeur métier non distinguée
- Le burnup additionne des points d’effort ou des tickets sans les corréler à la valeur métier réelle, si bien qu’une progression visible de la courbe peut dissimuler une valeur livrée très limitée.
Relations avec d’autres outils de suivi de projet
Le burnup et la valeur acquise entretiennent une parenté conceptuelle évidente. Dans un projet traditionnel, la courbe de valeur acquise représente le travail réalisé, tandis que la courbe de valeur planifiée représente le travail prévu. Le burnup transpose cette idée en remplaçant le planifié par une ligne de portée qui peut bouger. Là où la gestion de la valeur acquise s’appuie sur des lignes de base figées, le burnup assume le caractère mouvant du besoin. Croiser les deux approches peut aider un chef de projet hybride à dialoguer avec un PMO classique, en traduisant la flexibilité agile dans le langage des courbes en S.
Avec le graphique de burndown, le lien est un lien de complémentarité déjà évoqué. Avec le diagramme de flux cumulatif, la connexion est moins directe mais tout aussi instructive. Le cumulative flow diagram montre l’évolution du travail dans différents états (à faire, en cours, terminé) et permet de détecter des goulets d’étranglement, tandis que le burnup se concentre sur le rapport entre terminé et périmètre total. Utiliser les deux en parallèle donne une vision à la fois de la fluidité du flux et de la couverture du besoin.
Enfin, le graphique de vélocité, qui présente la quantité de travail terminée sprint après sprint, constitue la matière première qui alimente la projection du burnup. Une vélocité erratique rendra la ligne de tendance peu crédible. C’est pourquoi les équipes qui exploitent sérieusement le burnup portent une attention particulière à la stabilisation de leur vélocité, sans pour autant la sanctuariser comme un objectif en soi. La combinaison de ces trois indicateurs (burnup, vélocité, cumulatif) forme un tableau de bord équilibré pour un pilotage empirique.
Évolution et perspectives actuelles
L’évolution du graphique de burnup suit celle des pratiques de gestion de projet, qui ne cessent de chercher un équilibre entre prédictibilité et adaptabilité. Les premiers burnups étaient souvent dessinés à la main sur un tableau blanc lors des réunions de release planning. Aujourd’hui, ils sont intégrés nativement dans des outils comme Jira, Azure DevOps, Linear ou GitLab, avec des options de raffraîchissement automatique et des projections paramétrables. Cette industrialisation a considérablement abaissé le coût d’entretien, rendant l’outil accessible même aux petites équipes peu outillées.
Une tendance récente consiste à coupler le burnup avec des approches probabilistes, comme les simulations de Monte Carlo appliquées à la vélocité et à la variation de périmètre. Au lieu de tracer une simple droite de tendance, on obtient un cône de probabilité qui indique, par exemple, une date de fin avec un niveau de confiance de 85 %. Cette sophistication statistique permet de répondre aux questions de plus en plus pressantes des sponsors sur les délais, sans retomber dans le piège des estimations ponctuelles irréalistes. Le burnup devient alors une couche de visualisation pour des modèles prédictifs plus robustes.
On observe aussi une forme de retour d’expérience qui tempère l’enthousiasme des débuts. Des praticiens soulignent qu’un burnup n’a de sens que si le backlog est véritablement représentatif du besoin à date. Dans un contexte où le carnet de produit n’est qu’un réceptacle désordonné, le graphique ne fera que projeter une illusion de maîtrise. Cela a conduit à une exigence accrue de rigueur dans l’affinage, et à encourager les organisations à ne pas multiplier les artefacts agiles sans en comprendre les présupposés. Le graphique de burnup n’est pas une baguette magique, mais un miroir. Et comme tout miroir, il ne montre que ce qu’on accepte d’y mettre.
L'essentiel sur l'évolution du burnup
- Outils modernes et coûts réduits
- Le burnup a migré des tableaux blancs vers les plateformes intégrées comme Jira, Azure DevOps ou GitLab, réduisant radicalement les coûts de mise à jour et ouvrant son usage aux petites équipes.
- Simulations probabilistes et cônes de confiance
- L'intégration de simulations de Monte Carlo substitue au simple tracé linéaire un cône de probabilité, qui fournit une date de fin assortie d'un niveau de confiance et évite les estimations ponctuelles irréalistes.
- Backlog représentatif indispensable
- Un burnup ne produit une projection fiable que si le backlog reflète précisément le besoin actualisé, sans quoi il entretient une illusion de maîtrise et impose une rigueur accrue dans l'affinage du carnet de produit.
