Artefakter og Informationsformidling
Artefakter er ”vidnesbyrd om menneskelige aktiviteter” og bruges som begreb i arkæologien. I mangel af et bedre ord bruges dette også i Scrum som betegnelse for de lister, tavler, systemer, grafer og andet, der anvendes til at styre og synliggøre hele Scrum processen med.
Empirisk proceskontrol, som er hjertet i Scrum, hviler på tre søjler: Gennemsigtighed, inspektion og tilpasning. Gennemsigtighed opnås ved at lade flere møder være offentligt tilgængelige og ved at bruge offentlig tilgængelige Artefakter til at ”udstråle” information. Disse Artefakter skal være nemme at forstå og selvdokumenterende, så selv den, der kun ser på dem engang imellem, kan uddrage meningen. De skal naturligvis altid være korrekt opdaterede, så det er virkeligheden, de afspejler.
I Scrum findes der flere forskellige artefakter.
Product Backlog
Product Backloggen (ofte kaldes den bare Backloggen) er nævnt tidligere, den er en sorteret og velordnet liste af Product Backlog Items (PBI’er) – individuelle småleverancer, som ønskes, men som ikke er skabt endnu. De PBI’er, der er tæt på toppen, er mere ønskværdige at få begyndt på, end de, der er længere nede, set fra Product Ownerens synspunkt. Alle må gerne bidrage med PBI’er til Product Backloggen, men Product Owneren er den eneste, der flytter rundt på dem på Backloggen. Ordningen af Backloggen udtrykker Product Ownerens aktuelle plan.
Backloggen afbildes ofte med sektioner, der viser, hvornår forskellige releases eller faser finder sted samt de planlagte Sprints, der ligger inden for hver af disse releases. Der er typisk også en sektion til u-prioriterede PBI’er (de ting, som Product Owneren ikke tror Teamet klarer inden for den afsatte tids- og omkostningsramme for initiativet) samt en sektion til nye idéer eller krav. Det er god praksis at toppen af backloggen (de næste to-tre Sprints) er rimeligt afklarede og PBI’erne klar til at blive arbejdet på. PBI’er der ligger længere ude i fremtiden har ofte færre detaljer og er større, da de ikke er raffinerede endnu.
Product Owneren arbejder konstant på at forbedre og prioritere Backloggen. Han får hjælp fra Teamet til dette gennem aktiviteten Product Backlog Refinement. Nogle gange får han desuden også andre i organisationen til at hjælpe sig med det.
Sprint Backlog
Når Teamet har detailplanlagt Sprintet under Sprint Planning 2, så bliver dette præsenteret på Sprint Backloggen. Den viser de udvalgte PBI’er og typisk de opgaver (Tasks), som PBI’erne er nedbrudt i. Sprint Backloggen viser løbende en status for hver opgave, så alle kan se fremdriften. Teamet forholder sig løbende til, om de kan nå at færdiggøre alt det, de forpligtede sig på ved Sprintets opstart.
Sprint Backloggen er typisk delt op i forskellige kolonner, som arbejdsopgaverne kan flyttes rundt i. Typisk har man som minimum en kategori, der hedder ”Ventende”, en der hedder ”Igangværende” og en ”Færdig”. Det er også meget almindeligt at have en kategori, der hedder ”Blokeret”, som betyder at Teamet venter på noget udenfor Teamet, før opgaven kan gøres færdig. Arbejdet er typisk brudt ned til en sådan størrelse, at hver opgave (Task) kun forventes at være ”Igangværende” én dag.
Det er god praksis også at registrere enhver ”Uplanlagt” aktivitet, da disse aktiviteter ofte er den største forhindring for Teamets fremdrift og desuden indeholder en mulighed for at skabe konstant forbedring. Blot det at gøre dem synlige, får ofte organisationen til at reagere på dem. De uplanlagte aktiviteter bliver også ofte diskuteret under Sprint Retrospective.
Sprint Backloggen kan være en fysisk tavle i Teamets lokale eller et regneark, en liste eller en applikation i et IT system til formålet. Det sidste kan være nødvendigt, hvis Teamet ikke sidder sammen, men en simpel fysisk tavle foretrækkes af langt de fleste Teams, da den giver konstant og øjeblikkelig synlighed.
Sprint Backloggen ejes og vedligeholdes af Teamet. Det er ved hjælp af den sammen med Daily Scrum, at Teamet viser den omgivende organisation deres fremdrift og derigennem skaber tillid til Teamet og projektet. Teamet opdaterer status på Sprint Backloggen mindst en gang om dagen, således at status ved afslutningen af Daily Scrum er korrekt.
Improvement Backlog
Det er god praksis, men ikke et krav, at have en Improvement Backlog I, der viser de tiltag Scrum Masteren har gang i for at forbedre vilkårene for initiativet, den viser også de forhindringer Scrum Teamet har at kæmpe med. Den minder om Sprint Backloggen i form, men i stedet for at vise det arbejde, der har med produktet at gøre, viser den de ting, Scrum Masteren arbejder på for at forbedre arbejdsbetingelserne for Teamet og Product Owneren, så de kan opnå deres fulde potentiale.
Impediment Backloggen er et følsomt redskab. Alene det, at den er offentlig, provokerer til handling: Det at gøre forhindringer tydelige får ofte startet processen omkring at få dem fjernet. Ingen ønsker at se deres navn som et problem på listen. Det kan dog også fremprovokere modstand og konflikt. Scrum Masteren er nødt til at have fingeren på pulsen med hensyn til, hvordan situationerne håndteres på den bedste måde.
Ledelsen og Product Owneren vil ofte gerne have et overblik over fremdriften for de forskellige releases og faser eller for hele projektet for at kunne forudsige, hvornår det er færdigt, eller alternativt for at kunne se, hvor meget der kan nås indenfor en given tidsmæssig ramme.
Product Burndown
I Scrum bruger man ofte (men det er ikke et krav) en graf, kaldet Product Burndown. Den viser hvor meget arbejde, der er tilbage efter hvert Sprint ud fra estimaterne på Product Backloggen.
Ud fra disse registreringer kan Teamets arbejdshastighed også udledes – hvor meget Teamet i gennemsnit kan gennemføre på et Sprint. Hvis vi indfører ændringer til Teamets arbejdsmiljø, er det vigtigt også at have et overblik over, om dette egentlig medfører en forøget arbejdshastighed, eller om det ikke gør. Ud fra et kvalificeret estimat af Teamets Velocity (arbejdshastighed) kan der laves forudsigelser om, hvornår produktet er færdigt. Det bliver ofte angivet som et interval.
Det er også muligt på Product Burndown at registrere, hvor meget Værdi (Business Value) der er høstet, samt hvor høj en risiko eller hvor høj usikkerhed estimaterne indeholder.
Hvis der bliver fjernet PBI’er eller lagt nye PBI’er på Product Backloggen, er det meget almindeligt, at dette også bliver vist på Product Burndown. På samme måde er det også vigtigt at notere på Product Burndown, hvis der bliver lavet større ændringer på estimeringerne, der kan ændre på perspektivet for hele projektet. På den måde bliver ændringerne ikke blandet sammen med Teamets Velocity.
Sommetider viser denne graf kun et enkelt release eller en enkelt fase. I de tilfælde kaldes den en Release eller Fase Burndown.
Lær mere på et at vores Scrum Master aller Scrum Product Owner kurser
