Man kan lave en plan eller opstille en mål for sine sprints af mange grunde. Formålet — hvad planen skal bruges til — er vigtigt, for det har betydning for, hvad en god sprintplan[^1] er.
Forskellige teams, jeg har arbejdet med, har haft forskellige måder at lave planer og opstille mål, og mange af de klassiske agile metoder har også afgørende forskelle her. Skal man have en detaljeret plan for sprintet med alle opgaver kendt på forhånd, estimerede og klar, som i Scrum? Eller skal man slet ikke have en sprintplan, men hele tiden vide hvilken opgave, der skal tages som den næste, som i Kanban?
Jeg oplever, at diskussionerne om detaljeringsgraden af planen for den næste periode — eller behovet for overhovedet at have en plan — oftest kommer til at handle om kultur og personlige præferencer, men jeg tror, det er mere frugtbart at overveje, hvad man skal bruge planen til, og derefter overveje, hvordan den så skal se ud.
En sprintplan kan fx være
- En liste over fokusområder: "Vi arbejder med brugerregistrering i denne sprint"
- Fokusområder plus mål: "Vi arbejder med brugerregistrering, og når sprintet er omme kan man oprette en bruger, logge ind, og nulstille sit password"
- Timebokse: "Ane og Bo bruger juni på at lave den bedst mulige brugerregistrering"
- En række userstories med klar beskrivelse af de enkelte opgaver: "Der skal være en 'jeg har glemt mit password'-knap", måske med klare acceptans-kriterier.
- Userstories, prioriteret.
- Userstories, estimeret og prioriteret.
- Userstories, estimeret og udvalgt: Sprintplanen er at lave disse 14 stories.
- Userstories, estimeret og udvalgt og med stretch goal: Sprintplanen er disse 13 stories, plus disse 5 hvis vi er hurtige.
Hvad kan vi håbe at opnå med sprint-planen?
Prioritering
Vi vil gerne sikre os, at vi arbejder på det rigtige; på det, der giver mest værdi. Sprintplanen prøver at opnå dette ved at man under planlægningen vejer for og imod og omhyggeligt prioriterer det, man mener er vigtigst. Når sprintet så afvikles kan alle så med god samvittighed arbejde med det, der står på planen, og vide, at det er (omhyggeligt) prioriteret.
Effektivitet
Vi vil gerne have at vores udviklingshold kan arbejde så effektivt som muligt, og "producere maksimalt".
Maksimering af produktivitet
Vi vil gerne have det maksimale udbytte af vores udviklingshold: at vi producerer så meget værdi som overhovedet muligt (prioritering plus effektivitet).[^2]
Forudsigelighed
Vi vil gerne muliggøre, at andre rundt om projektet med rimelig tryghed kan planlægge ud fra planen. Jo længere ud i fremtiden planen rækker, og jo flere detaljer, den indholder, des mere kan andre planlægge videre ud fra vores plan — hvis altså vi formår at holde planen.
Arbejdsro og autonomi
Hvis sprintplanen er kendt og rimeligt fast, så kan projektdeltagerne tilrettelægge deres arbejdstid med stor frihed — så længe at sprintmålet er nået, når sprintet er omme.[^3]
Skalering
Jo mere autonomi, de enkelte projektdeltagere har, des større kan teamet være og stadig være funktionelt. Del og hersk, men på den gode måde.
All of the above, please!
Det lyder jo sikkert alt sammen godt, så måske tænker du "ja tak til det hele (men jeg behøver ikke noget brød til)". Men der er et par problemer.
Usikkerhed
Forudsigelighed står ofte højt på ønskelisten, men det er svært, for der er altid store usikkerheder og ukendte parametre. Vi kan gøre usikkerhederne mindre ved at undersøge afhængigheder og så videre på forhånd (lav en spike i dette sprint, så vi kan planlægge en mindre usikker opgave i næste sprint), men der er grænser for, hvor lille usikkerheden kan blive (indtil opgaven er løst).
Usikkerhed kan minimeres, men ikke fjernes. Derfor får man ofte illusionen af forudsigelighed snarere end egentlig forudsigelighed. I hvert fald indtil man i bagklogskabens lys kigger tilbage på udbyttet af sin omhyggelige plan. Skuffede forventninger er kilde til mange frustrationer, så pas på med at oversælge den forudsigelighed, jeres fine plan giver.
Modstridende mål
Nogle af målene er delvist modstridende, fx:
Forudsigelighed kontra Effektivitet
Hvis man vil have meget forudsigelighed skal man forberede sprintet godt og bruge tid på det. Det koster på effektiviteten.
Forudsigelighed kontra Prioritering
Forudsigelighed koster også på evnen til at prioritere pludseligt opståede, men meget værdifulde, opgaver. Eller omvendt.
Skalering kontra Prioritering
Hvis man skalerer ved at lave klare afgrænsninger af arbejdsområder, så arbejder alle måske ikke på det, der giver maksimal værdi?
Hvad er vigtigt for jer? I denne fase af projektet?
Jeg foreslår derfor, at I gør jer overvejelser over, hvad der er vigtigst for jer, inden I lægger jer fast på, hvordan jeres sprintplaner skal se ud. Det kan ændre sig i løbet af projektet: er I meget eksplorative og opportunistiske? Er andre afhængige af jeres stabilitet og oppetid, venter på jeres næste features, eller skal de planlægge på en længere bane?
I min liste over indbyggede udfordringer er forudsigelighed meget med, både på grund af udfordringerne med usikkerhed, og fordi forudsigelighed konkurrerer med så mange af de andre mulige formål. Jeg oplever ofte at forudsigeligheden vægtes højt, indtil vi har netop denne snak og de erkendelser, som denne blogpost handler om.
Når forudsigeligheden ikke er "gratis" vil vi ofte hellere have nogle af de andre mål: maksimal produktivitet, autonomi, evnen til at skalere. Og ender oftere med en mere løs sprintplan, der giver tilstrækkelig forudsigelighed.
Hvor meget vil du betale for mere forudsigelighed?
[^1] Meget af dette gælder også andre planer end lige sprintplaner — ja, endnu mere for længere planer som halvårsplaner og endnu længere planer. Jeg har skrevet i kontekst af helt korte planer, for hvis jeg kan overbevise dig om problemerne med de korte planer, så ved jeg, at du kan se problemerne med de længere planer.
[^2] Kanban fokuserer på maksimering af produceret værdi, og kan anbefales som en dejlig let, men fokuseret model.
[^3] Som jeg forstår det, maksimerer Basecamps forslag til remote work på autonomi og skalering.
