Hvad kan forhindre teamet i at komme videre i dag?
Hvordan ser Scrum processen ud?
- Product Owner formulerer sin Product Vision, så den bliver tydelig gennem et antal funktionalitetsbeskrivelser. Beskrivelserne tager udgangspunkt i de brugssituationer, som det kommende produkt vil skabe og de kaldes User Stories.
- Product Owner opretter en prioriteret liste med de ønskede User Stories i forhold til, hvad der giver mest værdi for produktejeren at få lavet først. Listen kaldes Product Backlog.
- De prioriterede User Stories fra Product Backlog bliver konverteret til en ’To-do liste’ for det team, som skal udvikle funktionaliteten. Denne liste er en Sprint Backlog og indeholder de opgaver, som Scrum Teamet har forpligtet sig til at udføre indenfor en given tidsramme, som kaldes et Sprint. Planlægningen af listen og arbejdets udførsel er et team samarbejde mellem Product Owner, Scrum Master samt Scrum Teamet. Selve planlægningen kaldes for Sprint Planning.
- Scrum Teamet, ledet af Scrum Master, arbejder nu målrettet i et sprint. Sprintenes længde fastlægges ved projektstart og er typisk en til fire uger. Teamet arbejder på at udvikle den ønskede funktionalitet til et færdigt brugbart produkt, som principielt er klar til at blive taget i brug (Minimum Viable Product (MVP) eller Potentially Shippable Product).
- Hver dag initierer Scrum Masteren et standup møde: Daily Scrum, hvor Scrum Teamet fokuserer på tre ting – både på team- og individniveau:
* Hvad blev lavet i går?
* Hvad skal laves i dag?
* Hvad kan forhindre teamet i at komme videre i dag? - I slutningen af hvert sprint afholdes et Sprint Review møde, som indeholder en gennemgang/demonstration af den udviklede funktionalitet for de personer (produkt interessenter), som skal give accept af den udviklede funktionalitet. Fokus i dette møde er på selve produktet.
- Ved afslutningen af hvert sprint afholdes et Sprint Retrospective møde. De centrale spørgsmål er: Hvordan gik sprintet og hvad kan gøres bedre næste gang? Fokus i dette møde er på processen.
- Cyklussen med punkterne 3-7 er en iterativ proces, som gentages, hvor der igen og igen prioriteres og udvælges emner (User Stories), fra Product Backlog. Dette fortsætter indtil projektets totale leverance er gennemført til et niveau, hvor Product Backloggen ikke længere tilfører værdi for Product Owner. En Product Backlog lukkes principielt ikke så længe produktet lever.
Ovenstående er en meget forenklet oversigt med et meget lidt komplekst produkt. Hvis kompleksiteten stiger, vil Scrum modellen skulle udbygges med et roadmap for produktet, som fortæller Scrum Teamet og andre interessenter om visionen for produktets levetid m.m.
Videre med Scrum
Ligeledes kan der være behov for at udbygge Scrum modellen med en plan for, hvornår de opnåede leverancer skal ’releases’ (frigives og sættes i drift). En releaseplan kan også være med til at lette prioriteringen af emnerne i Product Backloggen: Man laver de ting, som giver mest værdi først.
Hvis man bruger Scrum til meget store projekter, kan man med fordel se nærmere på det agile rammeværktøj, der kaldes SAFe (Scaled Agile Framework).
Der ligger en del projektmæssig håndværkskunnen bag flere af elementerne. For eksempel kræver arbejdet med Product Backloggen, at man er i stand til at optimere og raffinere den, samtidig med at man sikrer, at beskrivelserne (Use cases) er forståelige og giver mening for udviklingsteamet. Rollen som Product Owner er en disciplin for sig. Man kan i dag blive internationalt certificeret som Product Owner.