Scrum ordliste

Begreber og forklaringer

• Artefakter. Artefakter har til formål at visualisere status og fremdrift. Der arbejdes med tre overordnede artefakter i Scrum: Product Backlog, Sprint Backlog, Burndown Chart.
• Backlog. Se Product Backlog eller Sprint Backlog, alt efter kontekst.
• Backlog Refinement. Arbejde med at videreudvikle og finpudse Product Backlog. Arbejdet kan omfatte omrokeringer i rækkefølge, fjernelse eller tilføjelse af elementer, omskrivninger, estimeringer og re-estimeringer eller opdeling af eksisterende elementer. Backlog Refinement møder sikrer, at Product Backlog holdes opdateret og aktuel i forhold til kundens behov. Den skal indeholde nok opgaver, beskrevet i det rette format, til teamets næste sprints. Læs mere om Backlog Refinement her.
• Burndown Chart. En visuel præsentation af hvor meget arbejde, der mangler at blive gjort (vertikal akse), holdt op imod den forbrugte tid i projektet (horisontal akse). Det kan både være Sprint Burndown Chart og Product Burndown Chart.
• Daily Scrum. Daily Scrum er det daglige standup møde – man står bogstaveligt op til mødet, som skal holdes kort (15 minutter). Mødet går ud på, at hvert enkelt medlem af udviklingsteamet fortæller: 1. Hvad lavede jeg i går, som bidrog til opnåelse af vores fælles mål for sprintet? 2. Hvad skal jeg lave i dag, for at bidrage til opnåelsen af målene? 3. Kan jeg se nogen forhindringer, der gør, at teamet ikke kan nå vores mål? (Det er herefter Scrum Masters opgave at fjerne disse forhindringer). Mødet kan godt resultere i, at Sprint Backlog bliver opdateret. Mødet kaldes også ‘daily stand-up’, ‘daily meeting’, ‘huddle’ og ‘roll-call’.
• DoD. Definition of Done. En liste over de kriterier, som skal opfyldes af hvert enkelt element, før det kan betragtes som ’Done’ (færdigt) og klart til implementering. DoD er således en liste over kvalitetskrav for alt det, der udvikles. Udviklingsteamet ejer listen og sikrer transparens og en fælles forståelse for, hvordan et færdigt element ser ud – det er vigtigt, at alle interessenter: Product Owner, Scrummaster, Scrum Team og kunder alle er enige om, hvornår noget er færdigt.
• DoR. Definition of Ready: Det sæt af betingelser, som skal være opfyldt, før et element er klart til at blive lagt ind i et sprint i forbindelse med sprint planlægning. Et eksempel kan være, at elementet skal være beskrevet grundigt via en detaljeret User Story.
• Epic. En Epic er en stor User Story, som er for stor til at kunne udvikles i et enkelt sprint. Epics må brydes ned i mindre User Stories, før de kan lægges ind i et sprint.
• Estimering. En kvantitativ angivelse af hvor meget arbejde, der kræves for at færdiggøre et konkret element fra backloggen. Der er mange måder at estimere på, for eksempel standard-arbejdstimer eller Story Points. Estimering sker i teamet for at sikre ansvarstagen og man kan for eksempel gøre det ved at spille Planning Poker. Læs mere i vores artikel om ’Estimering’.
• ETC. Estimate to Complete: Et estimat af, hvor mange timer, der kræves for at færdiggøre en konkret opgave.
• Fail-fast (fail-small). En tilgang til udvikling, hvor man udfører små eksperimenter for at få hurtigt feedback, som man kan vurdere og indarbejde med det samme. Hvis man står overfor store usikkerheder, er det ofte bedre at afprøve en idé med et minimum af risiko og omkostninger, så man kan afvise den, før man har brugt for meget tid og penge på den. Tilgangen kaldes også fast-feedback eller learn-fast.
• INVEST. Et akronym, som bruges til at vurdere kvaliteten af en User Story: Independent, Negotiable, Valuable, Estimatable, Small or appropriately sized, Testable.
• LeSS. Large Scale Scrum er en metode til at skalere Scrum, så tilgangen kan benyttes i forbindelse med udvikling i stor skala. Metoden, som blev skabt i 2013 af Craig Larman og Bas Vodde består af principper, regler, retningslinjer og eksperimenter. LeSS fokuserer på at forstå et enkelt Scrum team og dernæst skalere op. Opskaleringen kan ske, så det samlede udviklingsteam består af 8 Scrum teams (LeSS basic) og op til tusinder (LeSS Huge) – som alle arbejder på et enkelt produkt. Tag et kig på LeSS’ hjemmeside, hvis du vil vide mere.
• MVP. Minimum Viable Product: Et produkt, som har lige præcis (hverken mere eller mindre) funktionalitet, som tillader teamet at implementere det. MPV er typisk det, der kommer ud af det første sprint og er selve målet med sprintet.
• Planning Poker. Et værktøj, som kan bruges til estimering. Product Owner præsenterer et element (et stykke funktionalitet), med henblik på at teamet skal estimere, hvor meget arbejde, det kræver at udvikle det beskrevne. Hvert enkelt teammedlem har en række Planning Poker kort, hvert med et antal timer eller point påskrevet. Hvert enkelt medlem kommer med sit bud på et estimat ved at vælge det kort, som vedkommende mener angiver det bedste estimat. Alle medlemmer viser deres bud på samme tid. Herefter forklarer teammedlemmerne med henholdsvis det højeste og det laveste bud deres bevæggrunde for at vælge netop de estimater og teamet diskuterer kort. Processen med bud fra alle teammedlemmer gentager sig indtil hele teamet er nået til enighed om et estimat, som alle kan stå inde for. Man kan foretage estimeringer på mange måder, men det er centralt, at hele teamet deltager for at sikre, at alle kan godtage estimaterne og har sat sig grundigt ind i, hvad der ligger til grund.
• Prioritering. Product Owner prioriterer, fra sprint til sprint, Product Backloggen, for at bestemme hvad der er vigtigst at få lavet. Denne prioritering kommer til at afgøre hovedindholdet på kommende sprints.
• Product Backlog. En liste af al den funktionalitet, som produktet som helhed skal indeholde. Product Owner ejer Product Backloggen. Elementerne i listen kan have form af User Stories (brugerhistorier), behovsbeskrivelser eller beskrives i andre formater.
• Product Burndown Chart. En grafisk oversigt, der viser, hvor meget der resterer i produktionen af det samlede produkt/service. Der fokuseres på, hvor meget der resterer, inden produktet er klar til fuld leverance.
• Product Owner. Fungerer som kundens og brugernes talerør til teamet. Product Owner definerer, hvad der skal gøres og i hvilken rækkefølge. Rollen har også ansvaret for at få mest mulig værdi ud af produktet og sikre, at det er en rentabel investering for virksomheden. Det er Product Owner, der skaber Product Vision og ejer Product Backloggen.
• Product Vision. En beskrivelse af den fremtidige tilstand, der nås ved at udvikle og implementere produktet. En god Product Vision er enkel, let at forstå og skaber et samlende fokus for de personer, som skal arbejde med udviklingen af produktet.
• SAFe. Scaled Agile Framework er en skaleret Lean-Agil metode, udviklet af Dean Leffingwell i 2011. Læs vores artikel om SAFe her eller Læs mere på den officielle side om SAFe her.
• Scrum Master. Scrum Master faciliterer Scrum arbejdsprocesserne og er ansvarlig for at fjerne forhindringer for teamet, når det skal leve op til kravene om leverancer i hvert sprint. Scrum Master er også ansvarlig for at hjælpe teamet med at arbejde i de agile rammer, sørger for afholdelse af de fastlagte møder (for eksempel Sprint Planning og Sprint Review) og skal også sikre, at relationerne i teamet fungerer.
• Scrum Team. Scrum Teamet består af en Product Owner, Scrum Master, og et udviklingsteam. Sammen er de ansvarlige for levering af den funktionalitet, der er lovet i de enkelte sprints, at kvaliteten er som aftalt og at leverancerne er klar til tiden.
• Scrum workspace. For at understøtte de agile arbejdsprocesser er det nødvendigt med overblik, der sikrer, at alle kan orientere sig og har fokus rettet mod de samme mål. Overblikket skabes ofte ved brug af en stor tavle eller væg, hvor hver enkelt opgave i det enkelte sprint er synlig. Det skal fremgå, hvem der arbejder med opgaven og hvilken fase opgaven befinder sig i, for eksempel design, udvikling, unit test, system test, brugertest eller dokumentation. Man kan også vælge en mere enkel version, hvor opgaverne placeres i kolonner, der viser ’ikke startet’, ’i gang’ og ’færdig’. Tavlen kan også indeholde Sprint Burndown chart for at vise den samlede fremdrift – og plads til uventede behov, problemer eller overraskelser, der kan dukke op…
• Sprint. En tidsperiode, typisk 2-4 uger, der definerer hvor meget arbejde, der kan lægges i produktet.
• Sprint Backlog. En liste med den funktionalitet, som er aftalt til at blive produceret i sprintet. Listen baserer sig på teamets estimater på, hvor meget tid, der skal bruges for at færdiggøre de enkelte elementer. Udviklingsteamet ejer Sprint Backloggen og opdateres gennem hele sprintet, så den altid giver et tydeligt og synligt billede af det igangværende arbejde. Teamet kan vælge at bryde elementerne i backloggen op i mindre opgaver, som udføres i sprintet.
• Sprint budget. Den mængde Story Points (eller lignende), der kan produceres i et sprint.
• Sprint Burndown Chart. En grafisk oversigt, som viser hvor meget der resterer af opgaverne i det igangværende sprint. Scrum fokuserer ikke på, hvad der er nået, men hvad der resterer, når der afrapporteres i sprintet.
• Sprint Planning. Sprint Planning mødet finder sted ved starten af hvert enkelt sprint. Formålet med mødet er at fastlægge målene og opgaverne for sprintet.
• Sprint Retrospective. Sprint Retrospective er et møde. Her tager teamet et samlet blik tilbage på sprintet og indeholder således informationerne fra Sprint Review. Sprint Retrospective har til formål at forbedre teamets indsats og ydeevne og samtidig indføre bedre måder at gøre tingene på. Det kan handle om både arbejdsprocesser, kommunikation, indbyrdes relationer, metoder, værktøjer mm.
• Sprint Review. Sprint Review mødet finder sted efter hvert enkelt sprint. Teamet viser hvad de har opnået i sprintet og i samarbejde med de andre interessenter (Product Owner og kunden) vurderes produkterne og feedback er med til at forbedre processerne og arbejdet i det næste sprint. Product Owner fremviser også Product Backlog og eventuelle justeringer i planer i forhold til den fremdrift, man har opnået i det foregående sprint.
• Sprint Task. En yderligere nedbrydning af User Stories fra Sprint Backloggen til en beskrivelse af de reelle opgaver, som udviklingsteamet skal igangsætte. Sprint Tasken beskriver, hvordan man skaber det, som Use Story’en dækker.
• Story Point. Det arbejde, der kræves for at udvikle og implementere hver enkelt User Story kan estimeres ved at benytte Story Point-metoden. Man estimerer hver enkelt User Story til et antal point, alt efter hvor kompleks, funktionaliteten er at udvikle. Det er derved muligt at vurdere, hvor arbejdskrævende de forskellige User Stories er i forhold til hinanden.
• Stretch tasks. Ekstraopgaver, som ligger udenfor et sprint, men som teamet kan tage fat på, hvis man når at blive færdig med de opgaver, som er indeholdt i sprintet.
• User Stories. Brugerhistorier, der fortæller om, hvordan funktionaliteten i det kommende produkt får betydning i brugerens verden. Læseren får en forståelse for, hvordan funktionaliteten skaber værdi for brugeren.
• Velocity. Den, over tid, målte produktionsevne pr sprint, målt i f.eks. Story Points.