Hai assolutamente ragione. Un grafico di burndown tiene traccia del completamento di una quantità prevista di lavoro in un determinato periodo di tempo (quindi perché viene spesso utilizzato per gli sprint) e i grafici di burnup sono più aperti, quindi vengono spesso utilizzati nelle versioni e nei progetti. Non c'è nulla che impedisca a un progetto a cascata di usarne uno. Tuttavia incontrerai due problemi:
1) I progetti sulle cascate dichiarano di non essere aperti. Non voglio fare generalizzazioni eccessive, ma molti progetti a cascata di cui ho fatto parte affermano di sapere quando il lavoro verrà svolto attraverso il progetto. Il grafico di burnup è inutile se lo conosci perché è uno strumento aperto. Usare una tabella di burnup equivarrebbe ad ammettere che le tue proiezioni sono azzeccate nel migliore dei modi e mentre molti project manager sono d'accordo sul fatto che questo è vero da zero, metterlo giù sulla carta è più difficile.
2) Non è possibile masterizzare nulla (o giù) su questi grafici fino a quando non viene completato completamente. Questo significa tutto lo sviluppo, i test, l'audit, il rilascio, tutto fatto. Molti progetti di cascata sono progettati per riunire tutto alla fine, quindi non aggiorneresti mai il tuo grafico fino alla fine. Se stai semplicemente contrassegnando le attività (la codifica di una funzione è completa, la progettazione di un'architettura è completa), in realtà sovvertisci la meccanica del grafico.