Estimering og planlægning episode 3

Serien

Episode 1 – Den med forudsætningerne
Episode 2 – Den med opsplitningen
Episode 3 – Den med den grove nedbrydning (du er her)

Strategisk estimering. Vores projekt har nu rammerne, vi har en prioriteret liste af opgaver - hvor forretningen har valgt hvilke funktionaliteter, der giver mest forretningsmæssig værdi. Nu skal det kobles med hvad hver del koster at lave. En dygtig udvikler har prøvet lidt af hvert - de ved hvor diverse dyr er begravet rundt omkring i systemlandskabet, og de bør have en god fornemmelse af teamet. Læg mærke til at jeg intet skrev om lead-/senior- og andre titler for udvikleren. Ofte er det faktisk en fordel, at have en blanding af erfarne udviklere og forholdsvis nye udviklere med i den her proces. En virkelig dårlig ide er at samle alle de største egoer i et lokale, hvor der skal gives forholdsvis hurtige estimater.

Kompleksitet

Vi skal bruge estimater, der siger noget om a) kompleksiteten i den enkelte opgave og b) usikkerheden. Nogen bruger T-shirt størrelser (tænk Large, Medium og Small) andre bruger udvikleruger – detaljerne er ligegyldige, tidsforbruget er ligegyldigt (på nuværende tidspunkt). De estimateter vi laver her, har en række andre formål – de er relative til hinanden. Det første og vigtigste formål er at danne et overblik over om det overhovedet er et godt projekt. Hvis alt er mere komplekst og tungt end forventet, så er en valid beslutning her at nedlægge projektet. Alternativt kan projektet skæres til – det skal virke sandsynligt at de tilbageværende opgaver kan løses inden for tidsrammen.

Næste formål med den her grovestimering er at finde ud af om udviklergruppen indeholder alle de kompetencer vi skal bruge – eller om vi skal bruge nogle ekstra resourcer. Dernæst bør den her estimering resultere i at prioriteringen af opgaverne genovervejes. En afvejning mellem hvor dyr (målt i kompleksitet) den enkelte funktionalitet er i forhold til forretningsværdien. Igen, jo hurtigere vi kan vise fremdrift i et projekt – jo større engagement og positivitet vil der være om projektet. Hvis vi med kun en moderat indsats kan levere værdifuld funktionalitet i uge 3 af projektet? Så har vi fået en flyvende start.

Hvad der sker her, bliver her

En absolut dødssynd er at bruge de her estimater til senere at følge op på om udviklergruppen så nåede den enkelte feature på den tid, de ’lovede’. Det er gift for næste projekt, fordi den enkelte udvikler så vil begynde at gange alle estimater med to. Eller tre. Al erfaring siger, at vi gætter vildt forkert i det her stadie – jo flere features, jo mere forkert gætter vi. Til gengæld gætter vi forkert i begge retninger, pointen er, at det her er en del af den lærende proces. Jo flere projekter vi laver, jo bedre en fornemmelse vil vi få for de hurdler, der er i organisationen.

Det vigtige her er at det er intuitionsbaserede estimater (også kendt som WAG’s – wild-ass guesses) – ingen detaljer er tilladt. Hvis det hjælper, så brug et spænd til at beskrive kompleksiteten. 2-12 udvikleruger er et validt gæt – det signalerer også at det er en opgave, vi skal være særligt opmærksom på, når vi kommer tættere på udførelsen. Hvis spændet er 20-250? Så skal opgaven brydes mere ned; den er for uhåndterlig og for usikker til at en god projektleder vil røre den med en ildtang.. i en asbestdragt.. på fyrre meters afstand..

Konklusion

Denne her indledende fægteduel mellem udviklingen og forretningen er i høj grad en forventningsafstemning. Er det business-as-usual, nu i rød… eller er det alle-mand-til-pumperne-det-kommer-til-at-gøre-ondt, vi taler om. Den forståelse mellem afdelingerne er guld værd – ikke bare til det her projekt men til den endeløse række, der ligger i fremtiden.