Vi sprinter alt hvad vi kan…

… men vi når stadig ikke i mål!

Dette er en situation jeg møder hos mange teams. Det giver frustration, for SCRUM skulle jo netop hjælpe med at vi nåede det vi satte os for i sprintet. Så hvorfor går det alligevel galt sprint efter sprint?

Det første oplagte spørgsmål at stille er – “Hvad var målet?”. Svaret er ofte – i hvert fald implicit – at levere de user stories der var planlagt i sprintet. Her opstår typisk den første udfordring, fordi vi også gerne vil sikre at alle har noget at lave, og derfor har fyldt kapaciteten i sprintet helt op. Det efterlader meget lidt plads til at navigere hvis der opstår udfordringer undervejs.

Så hvad kan teamet gøre for at forbedre situationen?:

For det første skal vi være bedre til at tænke i flow, og dermed hvordan vi som team kan levere størst mulig værdi for vores forretning, uagtet at vi måske ikke udnytter alle ressourcer i teamet optimalt. Jeg ved godt at det er en tanke som er svært at få ind under huden, men hvis vi som team kan levere mere værdi ved at en person ikke er booket fuldt ud med opgave fra sprintets start, så giver det god mening. Denne person kan så hjælpe andre med at løse opgaver, og tage fra hvis der opstår noget uventet. Tro mig! – der skal nok bliver noget at lave til alle 🙂

For det andet kan vi med fordel arbejde med et sprint mål, hvad er det vi som team levere til vores forretning i dette sprint? Sprintmålet er fomuleret som en vision for sprintet, så det bliver en guide for teamet til hvad der skal leveres. Scrum Guiden beskriver det således: “As the Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements functionality and technology. If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.”

Det betyder altså at hvis vi som team bliver klogere undervejs, er det okay at genforhandle scopet af sprint backloggen med vores Product Owner (PO), så længe det ikke sætter sprint målet over styr. Scrum Guiden beskriver nemlig også “During the Sprint: No changes are made that would endanger the Sprint Goal…”.

Hvis vi som team gerne vil hjælpe os selv og vores PO til selv at kunne foretage sådanne justeringer løbende, frem for at skulle gøre dem i sidste øjeblik, er der nogle ting vi kan gøre allerede når vi planlægger sprintet.

1. Vi kan prioritere de user stories vi tager med i sprintet, så vi er sikre på at vi arbejder på det vigtigste først. Sammen med punkt 2, øger det sandsynligheden for at vi opfylder vores sprint mål. Derudover giver det transparens i hvad det så er vi ikke når, hvis det vigtigste er sværere end vi forventede. Så allerede fra start ved PO og evt. andre interessenter, hvad der er i fare for at ryge ud af sprintet.
2. Vi kan sørge for at opfyldelsen af sprintmålet kun er bundet op på de vigtigste ca. 75% af indholdet i sprintet. Så selvom noget skulle ryge ud af sprintet, bringer vi ikke sprintmålet i fare.
3. Vi kan måle vores fremdrift, så vi kan sige noget objektivt om hvorvidt vi er på planen eller ej. F.eks. via burn down, eller cumulativt flow diagrammer. Dermed bliver vi også i stand til at reagerer tidligere i sprintet, og kommunikerer omkring evt. ændringer.
4. Hvis vi vil være bedre til at kommunikere ovenstående, kan vi lade os inspirere af PI planning fra SAFe (www.scaledagileframework.com), hvor man adskiller scope i “Comitted Objectives” og “Strech Objectives”, altså det vi skal levere og så det vi regner med at kunne levere, hvis der ikke opstår problemer.

Som skrevet i starten; det handler om at kunne skabe flow i opgaverne og flow er svært hvis alle er booket 100% fra starten af, og dermed allerede fastlåst.

Kom endelig med kommentarer og egne erfaringer!

P.S: Hvis du søger inspiration til at sætte et sprint mål kan meget af det jeg har skrevet om i tidligere indlæg omkring produktvision også oversættes til sprint mål, se indlæggene. Produktvision og MVP del 1 og Produktvision og MVP del 2