Slik får du mer ut av hver sprintdemo
Sprintdemoen er det viktigste kontrollpunktet ditt som kunde, men bare hvis du bruker den aktivt. Sjekk at det som vises, virkelig er ferdig og ikke nesten ferdig, ved å be om å få se det faktisk kjøre. Følg opp mot sprintmålet og budsjettet, ikke bare enkeltfunksjoner. Gi konkrete tilbakemeldinger som teamet kan omsette i handling med en gang.
Sprintdemoen er det faste punktet der du som kunde faktisk ser hva du betaler for. Likevel brukes den ofte passivt: Teamet viser, kunden nikker, alle går videre. Det er sløsing med det beste kontrollpunktet du har. Med de riktige spørsmålene og riktig fokus blir demoen i stedet et reelt styringsverktøy. Her er det du bør sjekke, følge opp og si.
Skill ferdig fra nesten ferdig
Den vanligste måten en demo villeder på, er at «ferdig» vises som en ideell flyt der alt går bra. Funksjonen fungerer akkurat så lenge alt legges inn perfekt, men grensetilfellene mangler. Oppgaven din er å skille det som virkelig er ferdig, fra det som er nesten ferdig.
Slik gjør du det:
- Be om å se funksjonen faktisk kjøre, ikke bli beskrevet eller vist i en forberedt flyt der alt går bra.
- Spør hva som skjer når noe går galt: tomme felt, feil inndata, brutt tilkobling.
- Test selv hvis du får tilgang. Når du selv sitter ved tastaturet, finner du det teamets forberedte demo går utenom.
Kan ikke teamet vise at funksjonen virkelig fungerer, også når det butter imot, er den ikke ferdig. Det er en vennlig, men bestemt holdning: «Nesten ferdig» er ikke ferdig, og det er billigere å vite det nå enn ved lansering.
Følg opp mot sprintmål og budsjett
En demo som ser bra ut funksjon for funksjon, kan likevel skjule to større problemer: at dere bommet på sprintens egentlige mål, eller at pengene tar slutt raskere enn arbeidet blir gjort. Løft derfor blikket fra de enkelte funksjonene.
| Spørsmål du bør stille | Hva det avdekker |
|---|---|
| Nådde vi sprintmålet? | Om helheten beveget seg fremover, ikke bare deler av den |
| Hvor mye av budsjettet er brukt? | Om tempoet holder, sett opp mot det som gjenstår |
| Hva ble ikke ferdig, og hvorfor? | Tidlige tegn på hindringer eller feilestimater |
Sjekk spesielt budsjettforbruket mot gjenstående arbeid. Har dere brukt halve budsjettet, men bare gjort en tredjedel av arbeidet, er det et varseltegn dere bør reagere på med en gang. Det er langt bedre å oppdage det i en demo midt i prosjektet enn på sluttfakturaen.
Gi tilbakemeldinger teamet kan gjøre noe med
Tilbakemeldingene dine er bare verdt noe hvis teamet kan omsette dem i praksis. Vage tilbakemeldinger skaper en ny runde med gjetting; konkrete tilbakemeldinger blir en oppgave som kan bygges. Forskjellen ligger i å peke på det som kan observeres.
- Svakt: «Den der føles litt feil.»
- Sterkt: «Når jeg sender skjemaet uten e-postadresse, skjer det ingenting. Jeg vil se en tydelig feilmelding.»
Beskriv hva du så, hva du forventet i stedet, og gjerne hvorfor det betyr noe. Da kan teamet gå rett fra kommentaren din til et tiltak, uten først å måtte tolke hva du mente.
Et konkret scenario
Si at teamet viser en ny bookingfunksjon, og den ser feilfri ut når de booker en time. Du ber om å få teste selv, forsøker å booke en time som allerede er tatt, og ingenting skjer: ingen advarsel, ingen forklaring. Du noterer det konkret: «Ved dobbeltbooking vil jeg at kunden skal få vite at timen er opptatt.» Så spør du om sprintmålet, som var «kunden kan booke og avbestille», og det viser seg at avbestilling ikke rakk å bli ferdig. Til slutt sjekker du budsjettet og ser at det ligger i rute.
På tjue minutter har demoen gitt deg tre ting: en reell feil som ble fanget opp, innsikt i at målet bare delvis ble nådd, og en budsjettsjekk. Det er forskjellen på å se på og å styre.
Forbered deg: Det er der verdien skapes
Den aktive demoen begynner ikke når møtet begynner, men før. Les gjennom på forhånd hva sprinten skulle levere slik at du kan sjekke mot det i stedet for bare å reagere på det som tilfeldigvis vises. Ha spørsmålene dine klare. Får du tilgang til det som er bygget, prøv det gjerne selv før møtet. Da kan demoen brukes på de interessante spørsmålene i stedet for på en første gjennomgang.
En forberedt kunde stiller bedre spørsmål, fanger opp mer og signaliserer dessuten til teamet at demoen tas på alvor. Det hever også kvaliteten på det som vises neste gang: Et team som vet at kunden tester grensetilfellene, slurver mindre med dem. Det motsatte gjelder like sterkt: En kunde som alltid bare nikker, lærer teamet at en pen hovedflyt er nok.
Å forberede deg med sprintens mål i hånden er det som skiller det å se på fra det å styre, og det henger sammen med hvordan du tar rollen som kunde generelt. Vil du vite hvordan vi legger opp demoene våre, ta kontakt.
Ofte stilte spørsmål
Hva er en sprintdemo?
En sprintdemo er møtet på slutten av hver sprint der teamet viser hva de har bygget. For deg som kunde er det anledningen til å se faktisk fremdrift, gi tilbakemeldinger og godkjenne eller be om endringer før arbeidet går videre. Det er det faste kontrollpunktet ditt. Brukt riktig er det der du styrer prosjektet, ikke bare får en rapport om det.
Hvordan skiller jeg ferdig fra nesten ferdig?
Be om å se funksjonen faktisk kjøre, ikke bare bli beskrevet eller vist i en ideell flyt der alt går bra. Spør hva som skjer når noe går galt, med tomme felt eller uvanlige inndata. «Nesten ferdig» betyr gjerne at hovedflyten fungerer, men at grensetilfellene mangler. Kan ikke teamet vise at funksjonen virkelig fungerer, er den ikke ferdig, uansett hvordan den beskrives.
Hva skal jeg følge opp i tillegg til funksjonene?
To ting: sprintmålet og budsjettet. Spør om det dere satte som mål for sprinten, faktisk ble nådd, ikke bare om enkeltfunksjoner ble ferdige. Sjekk også hvor mye av budsjettet og tiden som er brukt, sammenlignet med hvor mye som gjenstår. En demo som ser bra ut funksjon for funksjon, kan likevel skjule at dere er på vei til å sprenge budsjettet.
Hvordan gir jeg tilbakemeldinger teamet kan bruke?
Vær konkret og pek på det som kan observeres. «Knappen føles feil» er vanskelig å gjøre noe med; «når jeg sender uten å fylle ut e-post, skjer det ingenting, og jeg vil se en feilmelding» kan bygges med en gang. Beskriv hva du så, hva du forventet, og hvilken nytte endringen gir. Jo mer konkret, desto raskere kan teamet gjøre riktig.
Bør jeg forberede meg før en sprintdemo?
Ja. Les gjennom på forhånd hva sprinten skulle levere slik at du kan sjekke mot det i stedet for bare å reagere på det som vises. Ha spørsmålene klare, og test gjerne selv hvis du får tilgang. En forberedt kunde forvandler demoen fra en høflig forestilling til et reelt kontrollpunkt, og det er da den skaper verdi.