3 flexibele burndown-rapporten en hoe je ze kunt gebruiken

Agile-praktijken, voor niet-ingewijden en ondergeïnformeerden, kunnen soms verschijnen als ad-hoc methoden voor softwareontwikkeling en projectmanagement. De waarheid is heel anders.

Een van de 12 principes van agile software luidt: "De beste architecturen, vereisten en ontwerp komen voort uit zelforganiserende teams", maar de meeste organisaties die agile praktijken toepassen, waaronder scrum en Kanban, dwingen een aantal belangrijke processtrengheid en rituelen af. Veel organisaties implementeren bijvoorbeeld agile planningspraktijken, waaronder het schatten van verhaalpunten, architectuurstandaarden en releasebeheerdisciplines om de zakelijke impact, kwaliteit en betrouwbaarheid van applicatiereleases te verbeteren.

De meeste teams kiezen ervoor om een ​​agile tool zoals Jira Software of Azure DevOps te gebruiken om de achterstanden, sprints en samenwerking tussen agile teams te beheren. Het primaire doel van deze tools is het centraal beheren van de vereisten, sprintstatus, workflow en samenwerking tussen agile teamleden en meerdere agile teams. Hoe rigoureuzer organisaties deze tools gebruiken, hoe meer deze tools leiders en teams kunnen helpen problemen te identificeren, aan belanghebbenden over de status te rapporteren en hun uitvoering te verbeteren.

Een van de meest voorkomende out-of-the-box-rapporten is het burndown-rapport. Omdat agile-praktijken producteigenaren in staat stellen de achterstand opnieuw te prioriteren op basis van feedback van klanten, slagen traditionele rapporten zoals Gantt-grafieken er niet in om de vloeiende aard van agile-uitvoering weer te geven. Fundamenteel voor het burndown-diagram is dat het rekening houdt met voltooid werk, nieuw werk dat aan de scope is toegevoegd en andere scope-wijzigingen. De burndown-grafiek kan een snel beeld geven van hoe teams naar hun doelen marcheren.

Een basissprint-burndown-grafiek lezen

Burndown-grafieken hebben meestal tijd over de x-as en schattingen op de y-as. Veel teams schatten in verhaalpunten, maar veel agile tools kunnen burndowns in kaart brengen op basis van het aantal verhalen of schattingen in uren. Voor dit artikel ga ik ervan uit dat verhaalpunten worden gebruikt.

Het sprint-burndown-rapport zet het aantal verhaalpunten uit dat binnen het tijdsinterval valt. Terwijl het team verhalen voltooit, laat de grafiek zien hoe ze de lijst met verhalen en andere soorten werk (problemen in Jira, typen werkitems in Azure DevOps) 'afbranden' totdat het werk is voltooid of de sprint is afgelopen. Wanneer teams het werk van de sprint voltooien, snijdt de geplotte lijn de x-as om aan te geven dat alles is gedaan.

De burndown van de sprint is het gemakkelijkst te conceptualiseren. Op de eerste dag van de sprint committeert het team zich aan enkele verhalen en het totale aantal verhaalpunten. Als je de burndown-grafiek op die dag bekijkt, zou je een enkel punt op de y-as moeten zien dat het aantal punten aangeeft waaraan het team zich heeft verbonden op de nul van de sprint.

Terwijl de verhalen gemarkeerd zijn als voltooid, toont de burndown van de sprint het resterende aantal punten dat moet worden voltooid.

Hoe wordt een sprint-burndown in de praktijk gebruikt? Een gezonde burndown vertoont een lineaire en idealiter exponentiële curve tot nul. Als de bocht in het begin van een sprint een vlakke helling heeft, kan dit duiden op blokken of veel werk in uitvoering en dat de sprint mogelijk gevaar loopt. Een vlakke of langzaam aflopende burndown kan erg problematisch zijn als er veel wordt getest op code-complete stories en als het testwerk pas in de laatste paar dagen van de sprint kan beginnen.  

Een snel dalende burndown van de sprint is over het algemeen een goede zaak, maar het kan erop duiden dat het team te weinig inzet of ervoor heeft gekozen om alleen kleinere verhalen in de sprint aan te pakken.

Epische burndowns houden de voortgang bij met zakelijke en technische stuurprogramma's

Sprint-burndowns zijn zeer nuttig voor het volgen van de uitvoering op korte termijn en helpen teams om sprintverplichtingen succesvol na te komen. Om de voortgang ten opzichte van langetermijndoelen beter bij te houden, bieden epische en release-burndowns de nodige zichtbaarheid.

Epische burndowns werken het beste wanneer teams verschillende langlopende inspanningen definiëren, zoals het implementeren van belangrijke mogelijkheden voor eindgebruikers, technische schuldstrategieën, prestatieverbeteringen of procesevoluties. Om te profiteren van epische burndowns, moet de achterstand het volgende hebben:

  • Tussen vijf en vijftien heldendichten die minstens enkele maanden zullen duren en zes of meer sprints nodig hebben om te voltooien.
  • Functies, verhalen en verhaallijnen die onder het epos oprollen en een plan op hoog niveau vertegenwoordigen om het epos uit te voeren.
  • Schattingen op hoog niveau, idealiter in verhaalpunten voor elk verhaal of verhaalstomp die onder de heldendichten oprolt.

Zodra deze op hun plaats zijn, brengt de epische burndown de wijzigingen in dit plan in kaart. De x-as vertegenwoordigt sprints en de y-as vertegenwoordigt de totale schatting van verhalen en verhaalstubs die aan het epos zijn toegewezen. In de epische burndown-grafiek van Jira Software zie je een staafdiagram met één kleur die de verhalen vertegenwoordigt die in de sprint zijn voltooid en een tweede die de toegevoegde verhaalpunten laat zien. Verhaalpunten nemen toe wanneer nieuwe verhalen of verhaallijnen aan het epos worden toegevoegd of wanneer schattingen veranderen.

Er zijn verschillende manieren om de epische burndown-grafiek te gebruiken:

  • Het illustreert de snelheid van het voltooien van functies en verhalen tegen het plan. Als de plannen nauwkeurig zijn en de snelheid van het team consistent is, kan het een indicatie zijn wanneer het werk van het epos is voltooid.
  • De meeste agile plannen zijn niet compleet en teams voegen verhalen toe, wijzigen en verwijderen verhalen op basis van feedback van eindgebruikers, de ontdekking van technische complexiteiten en om technische schulden aan te pakken die tijdens de reis zijn ontstaan. De epische burndown geeft vervolgens aan hoe ver van plan het epos is gebaseerd op hoeveel de achterstand groeit of sprint voor sprint wordt voltooid.
  • Epische burndowns helpen ook bij het benchmarken van inspanningen over meerdere sprints en om te meten hoeveel planning- en leveringswerk er wordt gedaan in het ene epos ten opzichte van andere.

Release-burndowns informeren teams of releases de datum en het bereik zullen bereiken

Geavanceerde teams die hun leveringspijplijnen volledig automatiseren met continue integratie, continu testen en continue levering, hebben mogelijk geen burndowns nodig. Teams die vaak inzetten, moeten bijhouden welke functies en verhalen aan de release zijn gekoppeld, maar de burndown van de release is niet erg handig omdat het de voortgang vaak per sprint volgt.

Voor andere teams die de releasebeheerpraktijken volgen en standaardiseren op multisprint-releases, is de release-burndown wellicht de belangrijkste tool van de producteigenaar en het team.

De release-burndown is vergelijkbaar met de epische burndown, behalve dat in plaats van het volgen van functies, verhalen en verhaalstubs die aan een epos zijn toegewezen, de release-burndown laat zien wat er aan een release is toegewezen. De as en de balken zijn dan identiek aan epische burndowns.

Teams die release-burndowns gebruiken, kunnen dus het bereik en de tijdlijn voor een release volgen. Teams die op schema liggen, zien een burndown-helling naar beneden naar de x-as met een helling die consistent is met de snelheid van het team. Releases die mogelijk van de baan afwijken, hebben een kleinere helling of tonen meer verhaalpunten die worden toegevoegd (wanneer er meer bereik aan de release wordt toegevoegd) dan wat er wordt voltooid.

Jira Software helpt je bij deze projecties. Ervan uitgaande dat het team ten minste drie sprints aan het project heeft gewerkt, berekent Jira Software een gemiddelde teamsnelheid en voorspelt de eindsprint voor een release op basis van deze snelheid.

De sprint-, epische en release-burndowns geven teams een aantal eenvoudig te gebruiken tools om af te stemmen op doelen. Wanneer teams een gedeeld begrip hebben van de reikwijdte, prioriteiten overeenkomen, verschillende sprints vooruit plannen en verhalen op de juiste manier taggen in hun achterstand, vertellen burndowns het verhaal of planning en uitvoering zijn afgestemd op de doelen. Als dat niet het geval is, zijn ze een datagestuurde tool die de discussie kan aanwakkeren over welke aanpassingen nodig kunnen zijn.