Hoe waarden in een Burn Down Chart in Scrum worden berekend
In dit artikel wordt uitgelegd hoe de parameters in Burn Down Charts in Scrum worden berekend. Persoonlijk blog.
Deze afbeelding kon niet worden geladen.Na publicatie onder vrienden het eerste artikel over Burn Down Chart, was de tweede vraag die in de reacties werd gesteld: "Het is niet duidelijk hoe al deze waarden worden berekend". Daarom zal ik in dit artikel proberen uit te leggen hoe wij de dagelijkse waarden op de Burn Down Chart berekenen. Zoals gewoonlijk ben ik blij met alle opmerkingen van collega's als ik iets verkeerd zeg, maar toch wil ik geloven dat het onderwerp voldoende duidelijk voor me is.
Laten we ons nog eens herinneren hoe dit diagram eruitziet.
In dit voorbeeld wordt een sprint van 10 dagen bekeken. We zien dat er 2 dagen verstreken zijn (aangezien alleen de eerste 2 segmenten met de groene grafiek zijn ingevuld).
We zien ook het totale sprintvolume - dit is de stippellijn die laat zien dat het totale sprintvolume op maandag om 10:00, dinsdag om 10:00 en woensdag om 10:00 niet veranderd is en gelijk is aan 17 SP (Story Points).
Volgens de Scrum-methodologie verandert het totale werkvolume binnen de sprint niet gedurende de sprint, daarom wordt deze lijn vaak meteen voor de hele sprint getekend (alle 10 dagen). Ook helpt het om in te schatten hoeveel er nog gedaan moet worden, duidelijker dan wanneer deze in de huidige variant op de derde dag zou eindigen.
Reëel burndown (groene grafiek) toont het feitelijk resterende werk. Dat wil zeggen, op dit moment is door het team 1 Story Point van de 17 voltooid, die nodig zijn om de sprint succesvol af te ronden. Als voltooid wordt meestal een taak in de status "Done" beschouwd (wat Done voor elk team is, bepaalt het team zelf. Er is zelfs een speciaal artefact dat DOD heet - Definition Of Done - het is voor elk team anders en daarin staat heel precies beschreven wat betekent dat een taak is voltooid en naar de status "Done" kan worden verplaatst. Meestal is dat "Naar productie uitgerold", maar er kunnen nuances zijn. Kortom, op basis van de huidige grafiek begrijpen we dat alleen de DOD van één verhaal is voltooid, dat het team op 1 SP heeft geschat.
Ideale burndown laat zien op welk punt de grafiek van de reële burndown zich zou moeten bevinden bij volkomen gelijkmatig werk. Dat wil zeggen, op dit moment zouden 3 SP voltooid moeten zijn bij volkomen gelijkmatig werk.
Ik vermoed dat het interessant kan zijn om te begrijpen wat Story Pointis. In wezen kunnen 1 SP bij het ene team en 1 SP bij het andere team een verschillend werkvolume verbergen. Bij ons zijn er bijvoorbeeld teams met hetzelfde aantal mensen, maar het ene heeft een capaciteit per sprint van 17 SP en het andere 35 SP. En dat is normaal. Het punt is dat het team zelf een referentietaak kiest ten opzichte waarvan het alle taken tijdens groomings schat (de verouderde naam - dit is de wekelijkse bijeenkomst waarop de PO User Stories ter schatting meebrengt en het team ze schat via planning poker) (In SAFe is dit PBR - Product Backlog Refinement).
Zo kunnen we een referentie-User Story hebben: "Ik, als autobestuurder, wil na het tanken van de auto indien nodig een op papier afgedrukte bon kunnen krijgen". Afspreken dat deze voor ons team 8 SP is. En wanneer de PO een nieuwe User Story vertelt die we moeten schatten, schatten we die al ten opzichte van de referentietaak. Dienovereenkomstig kan de nieuwe door het team bijvoorbeeld op 5 SP worden geschat, enzovoort; alle verhalen in de backlog krijgen hun schattingen.
De capaciteit van het team wordt berekend op basis van statistieken. In de eerste 1-2 sprints wordt het aantal SP gemeten dat het team afsluit en wordt de gemiddelde waarde berekend; op deze waarde wordt de planning gebaseerd (wanneer de PO taken uit de backlog in de sprint selecteert voor een bepaalde capaciteit).
Ik hoop dat ik voldoende duidelijk heb beschreven hoe de waarden op de Burn Down Chart tot stand komen.
