Sådan får du mere ud af hver sprintdemo
Sprintdemoen er dit vigtigste kontrolpunkt som kunde, men kun hvis du bruger den aktivt. Tjek at det der vises, er reelt færdigt og ikke næsten færdigt, ved at bede om at se det køre for alvor. Følg op på sprintmålet og budgettet, ikke kun på enkelte funktioner. Giv konkret feedback som teamet kan handle på med det samme.
Sprintdemoen er det tilbagevendende punkt hvor du som kunde faktisk ser hvad du betaler for. Alligevel bliver den ofte brugt passivt: Teamet viser, kunden nikker, og alle går videre. Det er spild af dit bedste kontrolpunkt. Med de rigtige spørgsmål og det rigtige fokus bliver demoen i stedet et skarpt styringsværktøj. Her er hvad du skal tjekke, følge op på og sige.
Skeln mellem færdigt og næsten færdigt
Den mest almindelige måde en demo vildleder på, er at “færdigt” bliver vist i et forløb hvor alt går efter planen. Funktionen virker præcis så længe alt bliver tastet perfekt ind, men grænsetilfældene mangler. Din opgave er at skelne mellem reelt færdigt og næsten færdigt.
Sådan gør du:
- Bed om at se det køre for alvor, ikke blive beskrevet eller vist i et forberedt forløb hvor alt lykkes.
- Spørg hvad der sker når noget går galt: tomme felter, forkerte inputdata, en afbrudt forbindelse.
- Test selv hvis du får adgang. Din hånd på tastaturet finder det som teamets forberedte demo undgår.
Kan teamet ikke vise at funktionen virker i praksis, også når det går galt, er den ikke færdig. Det er en venlig, men bestemt holdning: “Næsten færdigt” er ikke færdigt, og det er billigere at vide det nu end ved lanceringen.
Følg op på sprintmål og budget
En demo der ser godt ud funktion for funktion, kan alligevel skjule to større problemer: at I missede sprintens egentlige mål, eller at pengene slipper op hurtigere end arbejdet bliver gjort. Løft derfor blikket fra de enkelte funktioner.
| Spørgsmål at stille | Hvad det fanger |
|---|---|
| Nåede vi sprintmålet? | Om helheden rykkede fremad, ikke kun dele af den |
| Hvor meget af budgettet er brugt? | Om tempoet er holdbart i forhold til det der er tilbage |
| Hvad blev ikke færdigt, og hvorfor? | Tidlige tegn på forhindringer eller fejlestimater |
Hold især budgetforbruget op mod det resterende arbejde. Har I brugt halvdelen af budgettet, men kun lavet en tredjedel af arbejdet, er det et advarselstegn der er værd at handle på med det samme. Det er langt bedre at opdage det i en demo midt i projektet end på en slutfaktura.
Giv feedback som teamet kan handle på
Din feedback er kun noget værd hvis teamet kan omsætte den. Vag feedback skaber en ny runde gætterier mens konkret feedback bliver til en opgave der kan bygges. Forskellen ligger i at pege på det der kan observeres.
- Svagt: “Den dér føles lidt forkert.”
- Stærkt: “Når jeg sender formularen uden e-mailadresse, sker der ingenting. Jeg vil gerne se en tydelig fejlmeddelelse.”
Beskriv hvad du så, hvad du forventede i stedet, og gerne hvorfor det betyder noget. Så kan teamet gå direkte fra din kommentar til en handling uden først at skulle tolke hvad du mente.
Et konkret scenarie
Lad os sige at teamet viser en ny bookingfunktion, og den ser upåklagelig ud når de booker en tid. Du beder om at prøve selv, forsøger at booke en tid der allerede er taget, og der sker ingenting: ingen advarsel, ingen forklaring. Du noterer det konkret: “Ved dobbeltbooking vil jeg have at kunden får at vide at tiden er optaget.” Derefter spørger du til sprintmålet, som var “kunden kan booke og afbestille”, og det viser sig at afbestilling ikke nåede at blive færdig. Til sidst gør du status over budgettet og ser at det holder.
På tyve minutter har demoen givet dig tre ting: en reel fejl der blev fanget, indsigt i at målet kun blev delvist nået, og et overblik over budgettet. Det er forskellen på at se på og at styre.
Forbered dig, for det er dér værdien skabes
Den aktive demo begynder ikke når mødet begynder, men før. Læs på forhånd hvad sprinten skulle levere så du kan holde demoen op mod det i stedet for bare at reagere på det der tilfældigvis bliver vist. Hav dine spørgsmål klar. Får du adgang til det der er bygget, så prøv det gerne selv før mødet. Så kan demoen bruges på de interessante spørgsmål i stedet for på en første gennemgang.
En forberedt kunde stiller bedre spørgsmål, fanger mere og signalerer desuden over for teamet at demoen bliver taget alvorligt. Det hæver også kvaliteten af det der bliver vist næste gang: Et team der ved at kunden tester grænsetilfældene, sjusker mindre med dem. Det modsatte gælder lige så meget. En kunde der altid nikker tingene igennem, lærer teamet at en pæn happy path er nok.
At forberede dig med sprintens mål i hånden er forskellen på at se på og at styre, og det hænger sammen med hvordan du tager rollen som kunde i det hele taget. Vil du vide hvordan vores demoer bliver tilrettelagt? Kontakt os.
Ofte stillede spørgsmål
Hvad er en sprintdemo?
En sprintdemo er mødet i slutningen af hver sprint hvor teamet viser hvad de har bygget. For dig som kunde er det lejligheden til at se de faktiske fremskridt, give feedback og godkende eller bede om ændringer før arbejdet går videre. Det er dit tilbagevendende kontrolpunkt. Brugt rigtigt er det dér du styrer projektet og ikke bare får en rapport om det.
Hvordan skelner jeg mellem færdigt og næsten færdigt?
Bed om at se funktionen køre for alvor, ikke bare blive beskrevet eller vist i et forløb hvor alt går efter planen. Spørg hvad der sker når noget går galt, med tomme felter eller usædvanlige inputdata. 'Næsten færdigt' plejer at betyde at happy path virker, men at grænsetilfældene mangler. Kan teamet ikke vise at funktionen virker i praksis, er den ikke færdig, uanset hvordan den bliver beskrevet.
Hvad skal jeg følge op på ud over funktionerne?
To ting: sprintmålet og budgettet. Spørg om det I satte som mål for sprinten, faktisk blev nået, ikke bare om enkelte funktioner blev færdige. Gør også status over hvor meget af budgettet og tiden der er brugt i forhold til hvad der er tilbage. En demo der ser godt ud funktion for funktion, kan alligevel skjule at I er på vej til at sprænge budgettet.
Hvordan giver jeg feedback som teamet kan bruge?
Vær konkret, og peg på det der kan observeres. 'Knappen føles forkert' er svært at handle på. 'Når jeg sender uden at udfylde e-mail, sker der ingenting, og jeg vil gerne se en fejlmeddelelse' kan bygges med det samme. Beskriv hvad du så, hvad du forventede og hvilken nytte ændringen giver. Jo mere konkret, jo hurtigere kan teamet gøre det rigtige.
Bør jeg forberede mig til en sprintdemo?
Ja. Læs før mødet hvad sprinten skulle levere så du kan holde demoen op mod det i stedet for bare at reagere på det der bliver vist. Hav spørgsmålene klar, og test gerne selv hvis du får adgang. En forberedt kunde forvandler demoen fra en høflig fremvisning til en skarp opfølgning, og det er dér den skaber værdi.