Burnup in burndown graf sta vizualni orodji za prikaz opravljenega dela in dela, ki še čaka v Product Backlogu.
Nekateri teami uporabljajo oba. Po mojem mnenju je to nepotrebno, saj je burndown graf manj fleksibilen in ga burnup lahko v celoti nadomesti. Poglejmo si zakaj.
Tipičen burndown izgleda tako:
Za isti velocity bi burnup izgledal takole:
Da lahko ocenimo količino preostalega dela, smo v burnup morali dodati črto, ki predstavlja velikost backloga. V burndown temu služi abscisa.
Količina dela v product backlogu skozi iteracije redko ostaja enaka. Kako takšno spremembo scopea prikažemo na grafu?
Na burnup grafu je to preprosto. Prilagodimo backlog linijo:
Na burndown grafu pa dodatni scope prikažemo malo težje. Nekateri teami dodani scope odštejejo od že opravljenega dela (slika). Takšna reprezentacija je za moralo teama precej slaba. Člani hitro dobijo občutek da kljub vsemu trudu nazadujejo.
Drugi način vizualizacije dodatnega obsega dela na burndown grafu je, da scope linijo pomaknemo v negativo. To se običajno prikazuje na enega od spodnjih načinov (linija ali stolpci).
Noben od zgornjih načinov prilagajanja burndown grafa ni praktičen. Burnup graf se zaradi svoje zasnove tem težavam izogne. Dodatni bonus je, da lahko burnup brez posebnih komplikacij razvijemo naprej v Cumulative Flow Diagram (CFD), ki smo si ga natančneje ogledali v tem prispevku.
CFD diagrami so koristno Lean orodje, ki razvojnikom in Scrum Mastru nudijo vpogled v pretok funkcionalnosti skozi razvojni proces.
Scenariji in napovedovanje
Burnup graf lahko uporabimo tudi za napovedovanje trajanja projekta z različnimi scenariji. Na osnovi teamskega velocity lahko izrišemo projekcije, ki pokažejo možne scenarije razvoja:
realistična napoved temelji na povprečni hitrosti iz preteklih iteracij in je ekvivalentna linearnemu trendu velocity dosedanjih iteracij,
optimistična napoved predpostavlja, da bo team v naslednjem obdobju delal hitreje (faktor 1,15 na grafu),
pesimistična napoved pa pokaže, kaj se zgodi, če bo napredek počasnejši (faktor 0,85 na grafu).
V spodnjem grafu se nahajamo na začetku 6. iteracije in želimo pripraviti projekcije glede na pozitivne oz. negativne faktorje, ki jih predvidevamo v prihodnosti.
Na ta način ne dobimo enega “točnega” datuma zaključka, ampak razpon možnih datumov. To je za Product Ownerja in deležnike veliko bolj uporabno, saj lahko realno ocenijo tveganja in se odločajo na podlagi več scenarijev.
Faktorji, ki lahko vplivajo na vrednost modifikatorja za optimistično oz. pesimistično varianto so lahko na primer:
- planirani dopusti in izobraževanja
- predvidene bolniške odsotnosti (glede na pretekli trend) v času viroz
- zaključek uvajanja novih članov teama in njihova polna angažiranost na projektu
- prihod novih članov v team
- planiran začetek uporabe TDD
- cepitev teama na dva manjša, ki bosta delala na istem produktu
- zaposlitev Scrum Mastra
- planirane optimizacije dela identificirane na Sprint Retrospektivi
- ipd.
Zaključek
Burnup graf ni le alternativni prikaz burndowna, ampak prinaša nekaj pomembnih prednosti. Največja je, da jasno loči med hitrostjo teama in spremembami obsega. Če se obseg povečuje, to vidimo kot premik zgornje črte, če pa team dela počasneje, to pokaže naklon spodnje črte. Poleg tega burnup omogoča preprosto komunikacijo z deležniki, saj je že na prvi pogled razvidno, koliko dela je bilo opravljenega in kako se spreminja cilj. Tak prikaz je pogosto tudi psihološko bolj spodbuden, ker napredek vidimo kot rast in dosežene cilje, ne kot odštevanje preostalega dela.
