Vi funderar kring hur man ska lägga upp tidsallokering rörande support ärenden i sprintar?
En fråga från en kursdeltagare på vår senaste CSPO kurs. Här kommer några snabbt svar.
Fokus vs snabbt och lyhört
Vi vill ha fokus i sprinten, så att alla jobbar tillsammans mot ett gemensamt mål.
Samtidigt vill vi inte låta omvärlden (kunder, användare och andra stakeholders) vänta i onödan. Ofta växer företagets kostnader fort vid varje fördröjning.
Å andra sidan drar ibland supportärendet ut på tiden och tar bort fokus från sprintens mål.
Hur kan vi hitta en bra balans?
Luft i sprinten
Alltid bra att ha lite luft i sprinten, så att man kan ta små enkla saker på uppstuds. Finns inget värre för omgivningen att höra “kom tillbaka om en vecka”.
Det värsta som kan hända om vi haft luft i sprinten, är att vi blir färdiga i förtid.
Det är i själva verket en väldigt bra sak. Mycket lättare att ta tag i svårare saker på retrospektiv ifall teamet känner “vi lyckades”. Detta är ett generellt råd till produktägare: Se till att vi (nästan) jämt når vår sprint-mål.
Prioritera supportärenden
Vi vill snabbt ta tag i support ärenden. Gärna prioritera dessa före annat. Men vi vill inte att de tar all tid från alla så att vi inte får något fokus på vårt sprintmål.
Timebox på x minuter
Ett sätt för att hindra att supportärenden växer och tar över är att komma överens om en time-box på supportärenden. Komma överens om i teamet hur lång tid man får lägga på en sak som kommer in från sidan, innan det är dags att prioritera detta mot annat. T.ex. införa regeln 30 minuter är ok att lägga på ärenden när de är nya och fräscha. Ifall de är lösta under den tiden så är det bra så.
Men så fort man slår i taket på timeboxen så eskalera till PO.
När det börjar ta tid så är det inte självklart det är viktigare än sprint målet i sig och jag som PO vill vara med och prioritera: “Är vi nära att lösa det hela? Är det en ask med mask? Finns det work around? Ska vi köra en time box till? Hur mycket tid är det värt?”
Några fördelar:
- PO slipper hålla på mid micro prioriteringar
- Vi slipper estimera
- Vi har bättre underlag för prioritering
Om man inte löst ärendet inom timeboxen har vi några alternativ
- Bestämma om en ny timebox, hur mycket tid är det värt att vi lägger på detta?
- Prioritera in det i senare sprint.
- Bestämma oss för att det inte ska fixas.
- Hitta en work around
Superhöna
Ytterligare en strategi som fungerar i kombination med ovan är att he en suppport-målvakt i teamet. En roll som man med fördel växlar mellan sprintar.
Veckans superhjälte (superman -> super hen -> superhöna 🙂)
som är första instans för allt som trillar in löpande.
Den personen kan jobba med timebox som ovan.
Logga och följ upp
Oavsett strategi, logga antalet supportärenden som kommer in och hur lång tid de tar/tog. Så ni har data att diskutera under retron.
Analys av supportärenden brukar leda till mer nyttiga och jobbiga insikter.
- När får vi många nya ärenden?
- Hur lång tid tar de?
- Kommer de in fler än vi hinner med?
I ett team ledde det till att vi insåg att många skitsaker borde vi kunnat hitta innan kunderna gjorde det. Så vi införde ett mantra ”hitta saker innan kunderna hittar dem” vilket ledde till en annan prioritering och utökat bevakningssystem. Vilket i sin tur minskade mängden supportärenden, i en bra självförstärkande loop.
Läsa mer
Detta var de snabba svaren, de lite längre handlar om Zero Bug Policy och Classes of Services, men det får bli en annan dag.
