Scrum organiserer arbejde i iterationer eller cyklusser af op til en kalendermåned kaldet Sprints. I dette indlæg vil jeg give en mere detaljeret beskrivelser af hvad sprints er. Derefter går jeg mere i dybden med flere karakteristikker af sprints; de er timeboxed, har en kort og konsekvent tidslængde, har et mål som ikke bør ændres når man er gået i gang og skal det færdige stadie, som er specificeret af projektgruppens definition of done.
Overblik
Sprints er det vigtigste element af et Scrum Framework.
Sprint execution er ofte forstået med at være en Sprint i sig selv, men det er rent faktisk bare en aktivitet, som foregår under en sprint, sammen med sprint planlægning, sprint reviews og sprint retrospective.
Alle sprints er timeboxed, hvilket betyder at de har fastsatte start- og slutdatoer. Sprints skal også være korte, et sted mellem en til seks uger i længde. Sprints bør være konsekvente i længde, men nogle undtagelser er tilladt, under specielle omstændigheder.
Som en regel, så er ingen mål-ændrende ændringer i sigte eller personaleændringer tilladt under en sprint. Endelig, under en sprint, er et potentielt markedsklar produkt inkrement færdiggjort i overensstemmelse med Scrum projektgruppens aftalte definition of done.
Selvom hver organisation vil have sin egen unikke implementering af done, så bør disse karakteristikker, med nogle få undvigelser, som vi vil gå i dybden med, fungere hos alle sprints og alle projektgrupper. Lad os gå lidt i detaljerne med dette, så vi bedre kan forstå hvorfor det er sådan.
Sprints er timeboxed
Sprints har rødder i konceptet timeboxing, som er en teknik til at tidshåndtering, som hjælper med at organisere ydeevnen af arbejde og håndtere scope. Hver sprint finder sted inden for en tidsramme med specifikke start- og slutdatoer, kaldet en timebox.
Inde i denne timebox forventes det, at projektgruppen arbejder på et holdbart tempo for at færdiggøre et valgt sæt af arbejde, som stemmer overens med sprintens mål.
Etablering af et WIP begrænsning
Timeboxing er en teknik for at begrænse mængden af WIP (work in process). WIP repræsenterer det arbejde, som er startet men endnu ikke færdigt. Kan projektgruppen ikke håndtere dette kan det have seriøse økonomiske konsekvenser for projektet som en helhed.
Men sprints kan hjælpe med dette, da projektgruppen vil planlægge kun at arbejde på de items, som gruppen mener den kan starte og færdiggøre inden for en sprint, så vil timeboxing etablerer en WIP begrænsning for hver sprint. På den måde bliver det meget synligt, tidligt i projektet, hvis der er problemer med projektet.
Fremtvinger prioriteringer
Timeboxing tvinger os til at prioritere og arbejde på den lille mængde arbejde, som har den største betydning. Dette styrker vores fokus på at få noget værdifuldt gjort færdigt hurtigt. På den måde sikrer man sig også at de opgaver som giver mest værdi bliver løst hurtigt i projektet. Dette er også med til at bevirke det næste punkt.
Demonstrerer fremskridt
Timeboxing hjælper os også med at demonstrere relevant fremskridt ved at færdiggøre og validere vigtige dele af arbejde ved hjælp af en kendt dato (slutningen af en sprint).
Denne type af fremskridt reducerer organisationelle risiko ved at skifte fokus væk fra upålidelige former af fremskridt rapportering, som f.eks. overensstemmelse med planlægning.
Timeboxing hjælper os også med at demonstrere fremskridt imod store features, som kræver mere end en timebox for at blive færdiggjort. Det at færdiggøre noget arbejde imod disse features sikrer, at værdifuld og målbar fremskridt laves hver sprint.
Det hjælper også interessenter og projektgruppen med at lære præcist hvad der mangler at blive gjort færdig for at levere en hel feature.
Undgå unødvendig perfektionisme
Timeboxing hjælper med at undgå unødvendig perfektionisme. På et eller andet tidspunkt har vi alle sammen brugt for meget tid på at få noget til at bliver “perfekt”, når “godt nok” faktisk ville være fint. Timeboxing tvinger at man får færdiggjort potentielt ubegrænset arbejde ved at etablere en fastsat slutdato for sprinten, hvor en god løsning skal være færdig.
Motiverer afslutning
Timeboxing motiverer også afslutning. Min erfaring er, at ting har større sandsynlighed for at blive gjort færdige, når projektgrupper har en fastsat slutdato. Det faktum at slutningen af en sprint medbringer en hård deadline motiverer projektgruppens medlemmer til flittigt at sørge for at arbejde færdiggøres til tiden. Uden en fastsat slutdato vil der være en meget mindre føles af at det haster at færdiggøre arbejdet.
Forbedrer forudsigelighed
Timeboxing forbedrer forudsigelighed. Selvom vi ikke kan forudsige med stor sikkerhed præcist hvor meget arbejde vi vil have færdiggjort om et år fra nu, så er det helt fornuftigt, at forvente at vi kan forudsige hvor meget arbejde vi kan færdiggøre i den næste korte sprint.
Sprints er af kort tidslængde
Sprints af korte tidslængder giver mange fordele. Herunder kan du læse omkring to af dem.
Nemt at planlægge
Sprints af kort tidslængde gør det nemmere at planlægge. Det er nemmere at planlægge et par ugers arbejde end at planlægge seks måneders arbejde. Derudover, så kræver planlægning af korte tidshorisonter en meget mindre indsats og det er meget mere præcist end planlægning af lange tidshorisonter.
Hurtig Feedback
Sprints af korte tidslængder generer også hurtig feedback fra brugerne. Under hver sprint skaber vi nemlig et lille produkt der virker og så har vi muligheden for at inspicere og tilpasse hvad vi har bygget og hvordan vi har bygget det.
Denne hurtige feedback gør det muligt for os hurtigt at fjerne ugunstige produktudviklinger eller udviklingstilgange før vi har en akkumulativ mængde af dårlige beslutninger med mange følgende beslutninger der er forbundet til denne dårlige beslutning.
Hurtig feedback tillader os også at være hurtigere til at opdage og udnytte pludselige muligheder som opstår ud af det blå, men som kræver en hurtig reaktion.
Sprints giver forbedret Return on Investment
Sprints af korte tidslængder forbedre ikke bare økonomien via hurtig feedback; de gør det også muligt at have tidligere og mere hyppige leveringsklare produkter. Som resultat har vi muligheden for at skabe omsætning hurtigere, hvilket forbedrer vores overordnede return on investment.
Begrænset fejl
Sprints af kort tidslængde begrænser også fejl. Hvor galt kan man komme på den i en to-ugers sprint? Selv hvis hele denne sprint går helt galt, så er der trods alt kun mistet to uger. Vi insisterer på korte sprints fordi de giver hyppig koordination og feedback. På den måde, hvis vi er galt på den, så er vi det kun på en lille måde.
Fornyet spænding
Korte sprints kan også være med til at fornye spændingen. Det er menneskelig natur for interesse og spænding at falde jo længere vi skal vente for tilfredsstillelse. Hvis vi arbejder på et projekt med en meget lang tidslængde, så er der ikke kun større sandsynlighed for at vi fejler, men der er også større sandsynlighed for at vi mister entusiasme for vores indsats.
Hos IBM kalder de ofte denne type projekter for “boil the ocean” projekter, fordi de er så lange og kræver så meget arbejde, at det kan føles som om man forsøger på at koge havet.
Med ingen tydelige fremskridt og ingen slutdato i sigte, så begynder folk at miste interessen. Når der er gået nok tid kan det sagtens være, at de ligefrem har mere lyst til at betale nogen for at få lov til at arbejde på et andet produkt.
Hyppige Checkpoints
Korte sprints giver også mange, værdifulde checkpoints.
Et værdifuldt aspekt af traditionelle projekter er et veldefineret sæt af milepæle. Disse milepæle giver ledere med kendte projekt-livscyklus checkpoints, som typisk er bundet til go/no-go funding beslutninger for næste fase. Selvom det potentielt set er brugbart fra et ledelsesperspektiv, så kan disse milepæle give en upålidelig indikation af den sande status af kunde leveringsværdi.
Scrum leverer ledere, interessenter, product owners og andre med mange flere checkpoints end de ville få med traditionelle projekter. I slutningen af hver korte sprint er der et vigtigt checkpoint (også kendt som the sprint review) som gør det muligt for alle at basere beslutninger på påviselige, fungerende features.
Mennesker er bedre til at håndtere et komplekst miljø, når de har handlingsegnet checkpoint muligheder, som du kan inspicerer og tilpasse sig til.
Konsekvent Tidslængde
Som en regel, så bør en projektgruppe vælge en konsekvent tidslængde for sine sprints, og ikke ændre på det medmindre der er en åbenlys årsag til det. En åbenlys årsag kunne f.eks. være:
- Du overvejer at bevæge dig fra fire-ugers til to-ugers sprints for at opnå hyppigere feedback, men vil gerne prøve et par to-ugers sprints inden du tager den endelige beslutning.
- De årlige ferier eller slutningen af et regnskabsår gør det mere praktisk at holde en tre-ugers sprint i stedet for den typiske to-ugers.
- Product release er om en uge, så en to-ugers sprint ville være spild.
Det faktum at projektgruppen ikke kan få alt sit arbejde gjort færdigt i den nuværende sprint bør ikke være en årsag til at forlænge længden på sine sprints. Det bør heller ikke være tilladt, hvis man når til den sidste dag i en sprint og opdager, at man ikke bliver færdig, at prøve på at få en ekstra dag eller uge. Dette er symptomer for problemer i projektet og muligheder for forbedringer; de er ikke gode grunde til at ændre på længden af en sprint.
Som en regel, af denne grund, hvis en projektgruppe vælger at gå efter to-ugers sprints, så bør alle sprints være i to-ugers længder. Praktisk set, så vil de fleste projektgrupper definere to-ugers sprints som ti kalender ugedage. Hvis der er en en-dags ferie eller trænings-event under en sprint, så reducerer det projektgruppens kapacitet for denne sprint, men gør det ikke nødvendigt at lave en ændring på længden af sprinten.
Brugen af konsekvente tidslængder på sprints giver også fordelene af kadence og simplificerer planlægning.
Kadence Fordele
Sprints af den samme længde giver os kadence – en regulær, forudsigelig rytme til en Scrum udviklingsindsats. En stabil, sund rytme tillader Scrum projektgruppen og hele organisationen af opnå vigtig rytmisk fortrolighed til hvad ting skal ske for at opnå et hurtigt, fleksibelt flow af forretningsværdi.
Efter min erfaring, så skaber en stabil kadence mulighed for folk til at “komme ind i zonen”, “be on a roll” eller “get into a groove”. Jeg mener at dette sker, fordi stabil kadence gør kedelige, men nødvendige aktiviteter til vaner, hvilket frigør mental kapacitet til at forblive fokuseret på det sjove, værdiskabende arbejde.
Kort sprint kadence har også en tendens til at fjerne intensiteten af arbejdet, I modsætning til et traditionelt projekt, hvor vi ser en stejl stigning af intensitet i de senere faser, hver sprint har en intensitet, som minder om den i andre sprints.
Sprints med en stabil kadence nedsætter også koordination og overhead betydeligt. Med fastsatte længder på vores sprints kan vi forudsigeligt lave en tidsplan over vores sprint planlægning, sprint review og sprint retrospective aktiviteter for mange sprints på en gang.
Fordi alle ved hvornår disse aktiviteter skal finde sted, så er det overhead der er krævet for at planlægge dem for en stor mængde af sprints betydeligt nedsat.
Som eksempel, hvis vi laver en to-ugers sprint på en udviklingsindsats der tager et år, så kan vi lave en gentagende event på alles kalendere for de næste 26 sprint reviews. Hvis vi tillader, at sprint tidslængder varierer fa sprint til sprint, så forestil dig den ekstra indsats til vil tage at koordinere alle tidsplanerne for interessenterne på hvad der altid kun vil komme med en til to-ugers varsel for det næste sprint review.
Det antager endda, at vi overhovedet kan finde et tidspunkt, som passer til de vigtigste interessenter, hvis kalendere sikkert allerede er fyldt op mange uger ud i fremtiden.
Sidst men ikke mindst, hvis i har flere projektgrupper på det samme projekt, så vil det at have alle grupperne med en lignende sprint kadence gør synkronisering muligt af arbejde på tværs af alle projektgrupperne.
Simplificerer Planlægning
At bruge en konsekvent tidslængde simplificerer også planlægningsaktiviteter. Når alle sprints er samme længde (selv når de måske har en dag mere eller mindre kapacitet per sprint, på grund af f.eks. ferie), så bliver projektgruppen komfortable med den mængde arbejde de kan nå i en typisk sprint, som vi refererer til som velocity).
Velocity er typisk normaliseret til en sprint. Hvis længden af en sprint kan variere, så har vi ikke en normaliseret sprint enhed. Det ville ikke give mening at sige ting som “Projektgruppen har en gennemsnitlig velocity på 20 points per sprint.”
Mens det uden tvivl er muligt at beregne en projektgruppes velocity selv hvis den bruger variable længder på sine sprints, så er det mere kompliceret. Ved at holde sig til konsekvente sprint tidslængder simplificeres beregningerne vi skal lave på projektgruppens historiske velocity data.
Konsekvente sprint tidslængder simplificerer også resten af planlægnings-matematikken. For eksempel, hvis vi arbejder på en fastsat release dato, og vi har konsekvente længder på vores sprints, så er beregningen af antallet af sprints i denne release simpelthen bare en øvelse i kalender-matematik. (Vi kender jo allerede datoen i dag, vores release dato, samt længden på alle sprints). Hvis tidslinjerne på vores sprints kan variere, så vil beregningen af antallet af sprints i denne release være betydeligt mere kompliceret, da vi så skal lave betydelig tidlig planlægning, involvere unødvendig overhead og det vil højst sandsynligt være mindre pålideligt end med sprints af konsekvente længder.
Ingen Goal-Altering Ændringer
En vigtig Scrum regel er, at når et sprint mål er blevet etableret og sprint eksekvering er begyndt, så må man ikke lave ændringer, som kan ændre sprintens Goal.
Hvad er et Sprint Goal?
Hver sprint kan opsummeres af et sprint goal der beskriver forretningens formål og værdien af denne sprint. Typisk har et sprint goal et klart, enkelt fokus, som f.eks.:
- Støtte brugeren i hans købsproces
- Indlæse vigtige dokumenter i systemet
- Demonstrere evnen til at sende en tekstbesked gennem et integreret software, firmware, og hardware setup.
Under sprint planlægning, så bør udviklingsgruppen hjælpe med at forfine og blive enige om et sprint goal og bruge det til at vurdere hvilke product backlog items den kan færdiggøre i slutningen af en sprint. Disse product backlog items virker til yderligere at uddybe et sprint goal.
Gensidigt Engagement
Et sprint goal er fundamentet af gensidig engagement lavet af projektgruppen og en product owner. Gruppen forpligter sig til at møde dette goal i slutningen af en sprint og deres product owner forpligter sig til ikke at ændre på målet under sprinten.
Dette gensidige engagement demonstrerer vigtighed af sprints i at balancere behovene af virksomheden for at kunne tilpasse sig til ændringer, samtidigt med at projektgruppen kan koncentrere sig og effektivt udnytte dens talent til at skabe værdi under en kort, fast tidslængde. Ved at definere og overholde et sprint goal kan Scrum projektgruppen forblive fokuseret på et veldefineret, værdifuldt mål.
Ændring vs Afklaring
Selvom et sprint goal ikke bør blive materialistisk ændret, så er det tilladt at afklare målet. Lad mig forklare forskellen på disse to.
Hvad konstituere en ændring? En ændring er en hvilken som helst ændring i arbejdet eller ressourcerne, som har potentialet til at generere økonomisk betydeligt spil, at skade projektgruppens flow of word, eller betydeligt ændrer deres scope of work inde midt i en sprint.
At tilføje eller fjerne en product backlog item fra en sprint eller betydeligt ændre på gruppens scope af en product backlog items der allerede er i en sprint konstituere typisk en ændring. Det følgende eksempel illustrerer en ændring:
Product owner: “Da jeg sagde, at vi har behov for at kunne søge i politi databasen for
en ungdomsforbryder mener jeg ikke bare via fornavn og efternavn. Jeg mente også,
at vi skal kunne søge i databasen baseret på et billede af den eftersøgtes
tatoveringer.”
Det at tilføje evnen til at kunne søge baseret på et billedet repræsenterer en betydeligt større indsats og vil næsten uden tvivl påvirke projektgruppens evne til at møde deres forpligtelse om at levere søgninger baseret på det fornavn og efternavn. I dette tilfælde bør deres product owner overveje at i stedet lavet en ny product backlog item, som dækker over “søg-efter-billede” featuren og tilføje det til det product backlog, som der skal arbejdes på i næste sprint.
Hvad konstituere så en afklaring? En afklaring er yderligere detaljer, som er givet under en sprint, som hjælper projektgruppen med at nå deres sprint goal. Eftersom at det ikke er sikkert, at man kender til alle detaljer der er associeret med en product backlog item på forhånd, så kan det naturligvis godt blive nødvendigt for projektgruppen, at stille afklarende spørgsmål og for deres product owner at besvare disse. Det følgende er et eksempel på en afklaring:
Udviklingsgruppen: “Når du sagde søgninger for ungdomsforbrydere skulle vises på
en liste, havde du så en præference for hvordan denne liste skulle rangeres?”
Product owner: “Ja, sorter dem i alfabetisk rækkefølge efter deres efternavn.”
Udviklingsgruppen: “Okay, det gør vi.”
I dette tilfælde kan og bør deres product owner give afklaring under en sprint.
Konsekvenser af Ændringer
Det kan måske godt virke som om, at denne no-goal-altering-change regel er i direkte konflikt med et af vores primære Scrum principper, nemlig at vi bør omfavne ændringer. Vi omfavner også ændringer, men vi vil gerne omfavne dem på en balanceret, økonomisk fornuftig måde.
De økonomiske konsekvenser af ændringer øges i takt med niveauet af vores investering i arbejdet øges.
Vi investerer i product backlog items for at gøre dem klar til at blive arbejdet på i en sprint. Men, når en sprint starter, så øges vores investering i disse product backlog items, fordi vi har brugt tid på sprint planlægning til at diskutere og planlægge dem på opgave-niveau. Hvis vi gerne vil lave en ændring efter sprint planlægning har fundet sted, så risikere vi ikke bare vores investering i planlægning, men også at få yderligere omkostninger ved at skulle planlægge nye ændringer der kan opstå under denne sprint.
Derudover, når vi begynder på sprint eksekvering, så øges vores investering i arbejdet endnu mere, når product backlog items bevæger sig igennem stadierne to-do, doing og done.
Lad os sige, at vi vil bytte feature x ud, som på nuværende tidspunkt er en del af vores sprint, med feature y, som ikke er en del af den nuværende sprint. Udover, at feature x måske har afhængigheder med andre features i denne sprint, så en ændring der påvirker feature x muligvis også påvirke en eller flere andre features, hvilket forøger effekten det har på sprint målet.
Hvis arbejde på feature x allerede er begyndt, så vil vi udover alt dette spild muligvis også have andre former for spild. For eksempel, så skal alt det arbejde der allerede er lavet på feature x muligvis smides ud. Og vi har måske yderligere spild af at fjerne dette arbejde der er lavet på feature x, som vi måske aldrig kommer til at bruge i fremtiden.
Og, naturligvis, hvis feature x allerede er færdig, så har vi måske spildt hele investeringen vi har lavet i feature x. Alt dette spild bliver akkumuleret.
Som tilføjelse til de direkte økonomiske konsekvenser af spildet, så kan økonomien også blive indirekte påvirket af den potentielle skade på projektgruppens motivation og tillid, som kan komme med en ændring. Når en product owner laver en forpligtelse til ikke at ændre målet og så bryder denne forpligtelse, så vil projektgruppen naturligvis blive demotiveret, hvilket højst sandsynligt vil påvirke gruppens lyst til at arbejde flittigt for at færdiggøre andre product backlog items. Derudover, så kan det også påvirke tilliden i Scrum projektgruppen, fordi udviklingsholdet ikke kan stole på at deres product owner vil leve op til sine forpligtelser.
At være pragmatisk
Denne no-goal-altering-change regel er bare det – en regel, ikke en lov. Scrum projektgruppen skal være pragmatisk.
Hvad hvis forretningsforhold ændrer sig på sådan en måde, at det at lave ændringer på det nuværende sprint goal virker nødvendigt? Det kan være, hvis en konkurrent lancerer et nyt produkt midt under vores sprint. Efter at have gennemgået produktet konkluderer vi at vi bliver nødt til at ændre målet vi har etableret for vores nuværende sprint, fordi det vi laver nu økonomisk set giver betydeligt mindre værdi end det vores konkurrent har lavet. Skal vi så bare blindt følge reglen om no-goal-altering-changes og ikke ændre på vores sprint? Sikkert ikke.
Hvad hvis et kritisk produktionssystem har fejlet betydeligt og nogle eller alle af personerne i vores projektgruppe er de eneste som kan fikse det? Bør vi så ikke bryde ind i denne sprint for at fikse det? Fortæller vi bare virksomheden, at vi vil klare det i næste sprint? Sikkert ikke.
Det at være pragmatisk er vigtigere end vores no-goal-altering-change regel. Vi bliver nødt til at agere på en økonomisk fornuftig måde. Alle i Scrum projektgruppen kan værdsætte det. Hvis vi ændrer vores nuværende sprint, så vil vi opleve negative økonomiske konsekvenser. Men, hvis de økonomiske konsekvenser er meget mindre end ændringen, så er det en klog forretningsbeslutning. Hvis økonomien af ændringen ikke er betydelig, så bør der ikke laves nogen ændring på vores sprint goal.
Hvad angår projektgruppens motivation og tillid, så vil de fleste projektgrupper forstå behovet for ændringen, hvis deres product owner har en klar, tydelig og økonomisk fokuseret diskussion med projektgruppen, som forklarer behovet for denne ændring.
Unormal afslutning
Hvis et sprint goal bliver fuldstændigt ugyldigt, så kan Scrum projektgruppen vælge at det at fortsætte med den nuværende sprint ikke giver nogen mening og anbefale deres product owner om at unormalt afslutte deres sprint. Når en sprint er unormalt afsluttet, så afsluttes den nuværende sprint med det samme og sprint projektgruppen samles for at udføre en sprint retrospective. Projektgruppen mødes så med deres product owner for at planlægge den næste sprint med et andet goal og et andet sæt af product backlog items.
Sprint afslutning er brugt, når betydelige økonomiske events opstår, som f.eks. en konkurrents handlinger som kan ugyldiggøre den nuværende sprint eller produkt funding der betydeligt ændres.
Selvom en product owner har muligheden for at afslutte hver og enkelt sprint, så er det sjældent en product owner rent faktisk bruger den. Ofte er der mindre drastiske tiltag, som en Scrum projektgruppe kan tage for at tilpasse sig situationen.
Husk på at sprints er korte og i gennemsnit vil en projektgruppe allerede være halvvejs færdige når en dette sker, så det kan have en stor betydning. Fordi der måske kun er en uge tilbage når den ændring finder sted, så kan det være at ændringen ikke er økonomisk gunstig. Og mange gange er det muligt, at lave ændringer, som er mindre dramatiske, som f.eks. at droppe en feature for at give tid til at fikse den kritiske produktionsfejl i stedet for at annullere den nuværende sprint.
Det er vigtigt at indse, at annulleringen af en sprint tidligt, udover at have en negativ effekt på moralen og påvirker det hurtige, fleksible flow af features og fjerner mange af de gode fordele af sprints af konsekvente tidslængder. Annulleringen af en sprint skal være den sidste udvej. Hvis en sprint annulleres, så skal Scrum projektgruppen vurdere længden af den næste sprint.
Der er tre gode muligheder:
- Behold den originale sprint længde. Det har fordelene af at man beholder den samme længde gennem hele udviklingen bortset fra den annulleret sprint, naturligvis. Hvis flere Scrum projektgrupper arbejder sammen på den samme udviklingsindsats, så vil det at bruge den originale sprint længde gøre, at Scrum projektgruppen som har annulleret deres sprint ryger ud af sync i forhold til alle de andre projektgrupper.
- Lav den næste sprint lang nok til lige at nå til slutdatoen af den annulleret sprint. For eksempel, hvis Scrum projektgruppen annullerede en to-ugers sprint i slutningen af første uge, så vil en uges sprint gøre, at de bliver resynkroniseret med den originale sprint kadence.
- Gør den næste sprint større end en normal sprint, så den dækker over tiden der er tilbage af den annullerede sprint plus den næste fulde sprint. Det vil sige, hvis vi følger det sidste eksempel, at den skal være tre uger, så gruppen også her bliver resynkroniseret med den originale sprint kadence.
I en multi-gruppe udviklingsindsats, så vil mulighed 2 eller 3 typisk være den bedste. I alle tilfælde skal du dog overveje din specifikke kontekst for at finde ud af hvilken der er bedst.
Definition of Done
Resultatet af hver sprint bør være et potentielt markedsklart product inkrement. Potentielt markedsklar betyder ikke, at det rent faktisk skal gives til kunderne. Det er en forretningsbeslutning om hvornår du vil lancere det for kunderne, og det vil typisk ske på en anden kadence; i nogle organisationer giver det måske ikke mening at levere det til kunderne i slutningen af hver sprint.
Potentielt markedsklar er bedre at tænke på som et stadie af tiltro til, at det der blev bygget i en sprint rent faktisk er done, hvilket betyder at der ikke er mere materialistisk vigtig ufærdigt arbejde, som skal gøres før vi kan levere resultaterne fra vores sprint, hvis levering af produktet er målet med sprinten. For at vurdere om hvad der blev produceret er potentielt markedsklare, så skal Scrum projektgruppen have en veldefineret, aftalt definition of done.
Hvad er en Definition of Done?
Konceptuelt er definition of done en tjekliste af den type arbejde, som projektgruppen forventes at færdiggøre for den kan sige at deres arbejde er potentielt markedsklart.
Naturligvis så vil de specifikke ting på en tjekliste afhænge af en række variabler:
- Naturen af det produkt der bygges
- Teknologierne der bruges til at bygge det
- Organisationen der bygger det
- De nuværender hindringer der påvirker hvad der er muligt
For det meste, så vil en minimums definition of done give en komplet del af produkts funktionalitet, en som er blevet designet, bygget, integreret, testet og dokumenteret, og som vil levere valideret kundeværdi.
For at have en brugbar tjekliste så skal disse højere-niveau opgave items forfines. For eksempel, hvad betyder testet? Enhed tests? Integration test? System test? Platform test? Internationalisering test? Du kan endda sikkert komme i tanke om mange flere muligheder, som er specifikke til dit produkt. Er alle disse typer af tests inkluderet i definition of done?
Huske på, at hvis du ikke foretager en vigtig type af tests hver eneste sprint, så skal du gøre det på et eller andet tidspunkt. Vil du f.eks. have en specialiseret sprint i fremtiden, hvor du udelukkende fokuserer på performance test? Hvis ja, og performance tests er essentiel til at være “done”, så har du faktisk ikke et potentielt markedsklart produkt inkrement hver eneste sprint.
Og endnu værre, når du så laver performance tests senere hen og det ikke går helt ligesom planlagt, så vil du ikke bare opdage et kritisk problem meget sent, men du vil også skulle bruge meget mere tid og flere penge på at fikse problemet, end hvis du havde lavet performance tests tidligere.
Nogle gange vil tests måske tage længere tid end tidslængden af en sprint. Hvis dette sker på grund af at udviklingsholdet har opnået en stor manual test-gæld, så skal projektgruppen automatisere sine tests, så testene kan blive færdiggjort i en sprint. Hvis dette sker på grund af naturen af test, så skal vi acceptere at starte testen i en sprint og færdiggøre den i en fremtidig sprint.
Scrum projektgrupper skal have en robust definition of done, en som giver et højt niveau af tiltro til at hvad der er bygget er af høj kvalitet og kan blive shippet. Alt mindre vil stjæle forretningsmuligheden for organisationen til shipping efter dens skøn og kan føre til akkumulativ teknisk gæld.
Definition of done kan udvikle sig over tid
Du kan tænke på en definition of done som at definere stadiet af arbejdet i slutningen af en sprint. For mange high-performance projektgrupper vil det målsatte stadie i slutningen af arbejdet gøre det til potentielt markedsklar. Og det slutstadie forbliver konstant over hele udviklings livscyklussen.
Det kan f.eks. være hvis man har en definition of done der hedder “live on production servers”. Mange projektgrupper starter dog med en definition of done, som ikke slutter i et stadie, hvor alle features er klar til det niveau, at de kunne gå live eller blive leveret. For nogle er der måske hindringer, som forhindrer dem i at nå dette stadie i starten af udviklingen, selvom det er det ultimative mål. Som resultat, så kan det være nødvendigt at starte ud med et mindre stadie og lade deres definition of done udvikle sig over tid i takt med at organisatoriske forhindringer bliver fjernet.
Eksempel:
En organisation, som bygger kliniske informationssystemer har det problem, at de kun har adgang til et klinisk laboratorium en sjælden gang imellem. Derfor har de ikke “klinisk tests”, som skal foretages i et klinisk laboratorium, med i deres definition of done. De har dog i stedet en sprint i slutningen af hver release, som er fokuseret på at lave kliniske tests. Deres direktør tager en snak med projektgruppen og kommer frem til, at det er bedre med fast adgang til at klinisk laboratorium hos det nærliggende universitet og så til gengæld levere færre features hver sprint, men klare en fuldendt definition of done.
Andre projektgrupper har muligvis hindringer, som de ved de ikke kan fjerne med det samme. Som resultat, så ved de også, at deres definition of done under produktudvikling vil udvikle sig. Et typisk eksempel er et produkt som indeholder hardware og software. Jeg har set Scrum blive brugt til udviklingen af sådanne produkter, og ofte kan man høre software folkene sige; “Hardwaren ankommer altid sent!”
I tilfælde som dette, hvis projektgruppen bygger software og ikke har den aktuelle hardware til at teste softwaren på, så kan den ikke sige, at slutresultatet rent faktisk er potentielt markedsklare. Det bedste den kan gøre er, at sige den er “emulator done”, fordi tests under tidlige sprints typisk er lavet imod en software emulator af det aktuelle hardware. Senere, når den rigtige hardware ankommer, så vil deres definition of done udvikle sig til at betyde potentielt markedsklar eller i det mindste tættere på at være det.
Definition of done vs Accepteringskriteria
Definition of done bruges på det produkt inkrement, som der udvikles under en sprint. Dette produkt inkrement er sammensat af et sæt af product backlog items, så hver backlog item skal færdiggøres i overensstemmelse med det arbejde der er specificeret af gruppens definition-of-done tjekliste.
Hver product backlog item der er bragt ind i en sprint bør have et sæt af “conditions of satisfaction”, som er specificeret af en product owner. Disse acceptkriterier vil på et tidspunkt blive verificeret som acceptance tests, som en product owner skal bekræfte for at vurdere om en backlog items features er ønsket.
For eksempel, så kan en product backlog item være “Tillad en kunde at købe med kreditkort” og så kan conditions of satisfaction være “Virker med Visa og MasterCard.” Så hver product backlog item vil have sit eget passende sæt af acceptkriterier. Disse item-specifikke kriterier er i tilføjelse til, og ikke i stedet for, gruppens “done” kriterier, som er specificeret af deres definition-of-done tjekliste, som tilhører alle product backlog items.
En product backlog item er først done, når både de item-specifik acceptkriterier og sprint-level definition-of-done items er mødt.
Derfor kan det være forvirrende at referere til product backlog items, som har bestået deres acceptkriterier som “done”, kald dem for “completed” eller “accepted”.
Done vs Done-Done
Nogle projektgrupper har adopteret konceptet af “done” vs “done-done”. Det vil sige, at på en eller anden måde, så er done-done mere done end done. Projektgrupper bør ikke have to forskellige koncepter, men der er nogle tilfælde, hvor man måske kan komme til at bruge dette begreb.
F.eks. hvis man spørger sin søn om han er “done” med sine lektier og han svarer ja. Når man så tager til skolen til forældremøde og spørger læreren om han er done, når han afleverer denne lektie og hun svarer “Ikke rigtigt”. Her vil man muligvis opdage, at sønnens definition-of-done var “Jeg lavede så meget arbejde, som jeg var forberedt på at lave”. Her kan man bruge konceptet done-done, som betyder “Done til det punkt, hvor din lærer også mener du er done.”
Konklusion
I dette indlæg har jeg gået igennem den altafgørende rolle af sprints i et Scrum framework. Sprints giver det essentielle Scrum framework, hvorpå de fleste andre aktiviteter og artifacts kan blive placeret. Sprints er korte, timeboxed og konsekvente i længden. De er typisk defineret af et sprint goal, et mål som ikke bør ændres uden en god grund. Sprints bør producere et potentielt markedsklart produkt inkrement, som er færdiggjort i overensstemmelse med en aftalt definition-of-done.
