Per Persson, Ph.D.

Erfarenhetsbank: fokuserade sprintar

En fokuserad sprint samlar rätt kompetenser under en kort och koncentrerad period för att bygga något verkligt, testa hypoteser och skapa underlag för beslut om nästa steg. Arbetssättet, och varför AI gör det möjligt på ett nytt sätt, beskrivs närmare i blogginlägget Från projekt till fokuserade sprintar.

Den här sidan är en levande erfarenhetsbank som samlar principer, sprinttyper och konkreta lärdomar från genomförda sprintar. Innehållet bygger på åtta sprintar genomförda under 2026, med Sundsvalls kommun som huvudsaklig arena, och är hämtat från sprintarnas egna dokumentationssidor och retrospektiv.

Grundprinciper

Kärnan i arbetssättet kan sammanfattas i en mening:

Samla rätt kompetenser under en kort och fokuserad period, bygg något verkligt, testa hypoteserna och fatta därefter beslut om nästa steg.

  • Noll avstånd

    Mellanlager mellan verksamhet och utveckling minimeras. Direkt dialog och direkt feedback ska vara normen – inga överlämningar av kravdokument genom flera led.

  • Snabba leveranser

    Korta cykler och dagliga leveranser till testmiljön gör att förändrade behov upptäcks tidigt. Små förändringar görs synliga och testbara varje dag.

  • Tvärfunktionellt team med full rådighet

    Teamet täcker de kompetenser som behövs för helheten, har egen deploykedja och full rådighet över utvecklings- och testmiljöer – utan väntan på andra team eller externa köer.

  • Hypotesdrivet

    Teamet testar antaganden med en fungerande prototyp innan lösningen färdigställs. Att ett antagande visar sig fel är ett lärande, inte ett misslyckande.

  • AI-accelererat

    AI används för att öka tempo, utforska alternativ och frigöra tid till problemlösning – i utveckling, analys och dokumentation, och ibland även som del av den byggda tjänsten.

  • Löpande anpassning

    Process, prioriteringar och lösning justeras när teamet lär sig mer. Grovplanen är just en grovplan – ny insikt slår gammal plan.

Sprintens fyra faser

Alla genomförda sprintar följer i grunden samma fasmodell – och en återkommande lärdom är att fas 0 avgör hur mycket sprinttiden faktiskt ger.

  • Fas 0

    Förberedelse

    Prototyp eller grundplåt tas fram, arkitektur och teknik förankras, deploykedjan sätts upp och torrkörs, och verksamhetens deltagande planeras. Hit hör också konkret underlag från verksamheten – exempeldokument, beslutsmallar, testdata – och sådant som AI-nycklar och testanvändare.

  • Fas 1

    Genomförande

    De intensiva dagarna i samma rum. Daglig standup fungerar som nav för demo, hinder, beslut och direkt feedback, och leveranser görs löpande till testmiljön.

  • Fas 2

    Utvärdering

    Resultatet och arbetssättet utvärderas mot hypotesen. Lärdomar, risker och förbättringar dokumenteras och förs vidare – till nästa sprint och till den ordinarie utvecklingsförmågan.

  • Fas 3

    Fortsatt utveckling

    Produktionsutvecklingen tar vid från den körande prototypen, den prioriterade restlistan och de beslut som fattats – utan att behöva börja om från noll.

Spelregler och mindset under sprinten

Samma spelregler återkommer på alla sprintsidorna, i något olika varianter – i avvikelsesprinten beskrivna som ”inte förhandlingsbara”. En lärdom från retrospektiven är att reglerna också ska presenteras uttryckligen på uppstartsmötet.

En sprint lyckas inte för att teamet har rätt kompetens – den lyckas för att teamet har rätt inställning.

  • Ägarskap

    Förstå varför, inte bara vad. Ta ansvar för att driva processen framåt utan att vänta på instruktioner eller tilldelning. Ser du något som behöver göras – gör det.

  • Kommunikation

    Prata direkt med varandra, alltid. Ge feedback omedelbart – tystnad är ett större hinder än ofärdiga idéer.

  • Tempo

    Varje timme räknas. Agera med tillräckligt bra information i stället för att vänta på perfektion.

  • Förenkla, förenkla, förenkla

    Good-enough framför optimalt. Komplexitet är en kostnad teamet inte har råd med under sprinten.

  • Omfamna förändring

    Ändringar är bevis på lärande, inte på dålig planering. Teamet ska inte nödvändigtvis bygga det man trodde från början, utan det man lär sig att man behöver.

  • Teamet framför individen

    Alla roller är jämlika under dagarna. Är du klar men en kollega har fastnat? Hjälp kollegan. Teamet levererar tillsammans eller inte alls.

  • Våga vara obekväm

    Visa halvfärdigt arbete, erkänn när du inte vet och ändra uppfattning när ny kunskap uppstår.

  • AI-accelererat

    AI används aktivt i kodning, modellering och dokumentation – hela tiden. Det är så en månads arbete hinns med på en vecka.

Sprintveckans rytm

En grovplan för veckan sätts i förväg men anpassas löpande efter vad teamet lär sig. Några fasta hållpunkter bär strukturen – så här såg de ut i avvikelsesprinten:

  • Uppstartsmöte

    Första morgonen, med hela teamet inklusive expertstöd: målbild, tekniskt komplicerade frågor, arkitekturskiss och arbetsfördelning – och spelreglerna. Sedan full fart.

  • Daglig standup

    En kort avstämning varje morgon med hela teamet, inklusive expertstödet: genomgång av gårdagen, demo av ny funktionalitet – även halvfärdig – och frågor, hinder och synk som tas direkt, inte nästa dag.

  • Halvtidsdemo

    Mitt i veckan visas körande funktionalitet – inte slides. Feedback tas emot direkt, in i backloggen eller in i koden.

  • Dokumentationsansvarig varje dag

    I ekbistånd-sprinten utsågs varje dag en dokumentationsansvarig som skrev beslut, frågor och bordlagda punkter i realtid – så att inget lärande går förlorat i tempot.

  • Bekräftad beslutslogg per block

    I förankringssprinten avslutades varje block med att beslutsloggen lästes upp och bekräftades punkt för punkt, och frågor som inte kunde avgöras parkerades med ansvarig person och datum. Loggen blir därmed en överenskommelse, inte en minnesanteckning.

  • Slutdemo och retrospektiv

    Sista dagen demonstreras resultatet, lärdomarna summeras och riktningen sätts inför nästa steg – allt dokumenteras på sprintsidan.

  • Stödresurser löpande

    Experter och stödresurser är nåbara via chattkanaler hela veckan. Fastnar teamet ropar det direkt – det väntar inte till nästa möte.

  • Sprintlogg dag för dag

    Veckan dokumenteras medan den pågår – vad som byggts, beslutats och lärts. Loggen gör arbetet transparent och blir underlag för retro och erfarenhetsbank. I utvecklingssprinten fick varje dag två delar: vad som sades på standupen och vad som faktiskt levererades i kod, per repo och utvecklare.

  • Tre beslutsnivåer och veto

    I utvecklingssprinten sorterades besluten i förväg: fältnamn, utformning och teknik avgörs i rummet samma dag; processregler och vem som ser vad avgörs på standupen med verksamhetens mandat; juridik och personuppgifter eskaleras och byggs runt tills svaret kommit. Sprintledaren kan stoppa ett beslut på alla nivåer men tar inte över frågan – den går tillbaka till den som äger den.

  • Frågelista med status

    Verksamhetens frågor och synpunkter samlas på sprintsidan med löpande nummer, status – hanterad eller under utredning – och hänvisning till raden i funktionslistan där beslutet skrivits in. Efter tio dagar i utvecklingssprinten stod där tjugofyra frågor, och alla kunde se vilka som var avgjorda.

  • Laget runt följt av dagens verksamhetsfråga

    I utvecklingssprinten för alkohol och tobak följdes morgonens laget runt varje dag av ett pass med verksamheten om en konkret fråga – yttre tillsyn, tillfälliga tillstånd, hur ett tillstånd avslutas, catering och restaurangnummer. Flera av passen landade i beslut eller nya Jira-ärenden samma dag.

  • Överlämningssida till nästa sprint

    Den tekniska sprinten för alkohol och tobak avslutades med en egen sida inför utvecklingssprinten: vad demon bekräftade, vad som blockerar bygget, nya krav ur genomgången, processer som visade sig vara okartlagda, hur verksamheten ska medverka – och en numrerad checklista över vad som ska vara gjort före sprintstart. Sidan är underlaget som nästa sprint börjar i.

Olika sprintar för olika osäkerheter

”Sprint” behöver inte betyda samma sak varje gång. Varje sprint organiseras efter den osäkerhet som just då är dyrast att bära vidare – och längden anpassas efter frågan: två dagar kan räcka för en prototyp, tre dagar för att verifiera och estimera, medan tekniskt komplexa frågor kan kräva en eller två veckor – och en lösning som ska hela vägen till produktion kan behöva två sprintar med ett uppehåll för test emellan.

  • Innovationssprint

    Testar om ett verksamhetsproblem går att lösa på ett nytt sätt. Ett tvärfunktionellt team bygger en fungerande lösning som verksamheten kan använda och bedöma, och sprinten avslutas med ett beslut om att gå vidare eller inte. I kortare form – innovationsdagar – används formatet som verifieringsmoment: lösningen prövas mot verkliga ärenden, juridiska gränser och tekniska förutsättningar innan ett större genomförande estimeras.

  • Prototypsprint

    Ersätter antaganden med konkret kunskap genom en körbar prototyp av en hel kedja – till exempel från medborgarens ansökan till handläggarens beslut. Sprinten utgår från en uttalad hypotes och ett fåtal frågor som ska besvaras. Målet är inte produktionsfärdig kod utan besvarade frågor och fattade beslut.

  • Teknisk sprint

    Isolerar och angriper de svåra tekniska frågorna – som behörighetsstyrning och datasäkerhet – innan verksamhetssprintar tar över. Kärnteamet arbetar tätt, medan verksamheten koncentrerar sin tid till uppstart, standups och demos. Formatet fungerar också som mellansteg mellan förankring och bygge: i alkohol- och tobakssprinten omsattes förankringssprintens bottenplatta till lösningsmönster och färdiga miljöer, verksamhetens öppna frågor fick dokumenterade ställningstaganden, och sprinten avslutades med en demo där verksamheten godkände processen innan utvecklingssprinten startade.

  • Förankringssprint

    Ett alternativ till den klassiska förstudien som växte fram ur retrospektiven och nu prövats skarpt: verksamhet och utveckling reder tillsammans ut process, teknik och osäkerheter innan bygget startar, i stället för att ett dokument produceras och lämnas över genom flera led. Formatet skiljer sig från de övriga genom att inget system byggs – leveransen är en överenskommen processmodell, dokumenterade lösningsmönster och en beslutslogg som blir bottenplatta för nästa sprint. Verksamheten deltar i halvdagsblock, utvecklingsteamet omsätter besluten till mönster och konfiguration under eftermiddagarna, och varje förmiddag inleds med att verksamheten verifierar gårdagens resultat.

  • Utvecklingssprint

    Bygger den lösning som ska driftsättas – inte en prototyp som värderas efteråt. Formatet har prövats i två varianter: två sprintar om tio arbetsdagar med ett uppehåll på några veckor, där verksamheten testar det som byggts på riktigt och återkopplingen styr innehållet i den andra sprinten – och en tvåveckorssprint med ett mål per vecka, där det som byggs vecka ett är grunden för vecka två. Allt byggs i skarp miljö från dag ett med tester, CI och behörighet på riktigt, och ”klart” betyder fyra saker samtidigt: byggt i skarp miljö, verifierat med tester, visat på en standup – men inte driftsatt. Verksamheten deltar via den dagliga standupen och är nåbar samma dag, och arkitekt och UX sitter med i rummet så att tekniska val och gränssnittsfrågor inte behöver lämna sprinten för att avgöras.

Genomförda sprintar

Varje genomförd sprint har en egen dokumentationssida med upplägg, resultat och retrospektiv. Erfarenhetsbanken byggs på med lärdomar från varje ny sprint.

  • Innovationssprint

    Dokumenthantering

    Två veckor (tio arbetsdagar) · våren 2026 · Sundsvalls kommun

    Både metodtest och produktbygge: ett tvärfunktionellt team byggde en dokumenthanteringsapplikation och prövade samtidigt arbetssättet, som svar på en utveckling som lätt fragmenteras mellan roller, specialistteam och överlämningar. Av 60 planerade funktioner hann en stor del byggas eller påbörjas på tio arbetsdagar, i tre kodrepon och med två verksamhetsdemos. Kärnan kom på plats tidigt, vecka två prioriterades om utifrån verksamhetens reaktioner, sökningen växte från stödfunktion till huvudvärde, och AI-stödet kopplades in sist – när grunddata och sökförmåga bar. Slutdemon landade i ett enhälligt ja till att gå vidare. Motsvarande arbete hade tidigare bedömts kräva ett projektupplägg på omkring fyra månader.

    Till sprintens dokumentation
  • Innovationsdagar

    Ekonomiskt bistånd

    Tre dagar · 2026 · Sundsvalls kommun

    Tre innovationsdagar med tio personer för att designa, verifiera och estimera automatiseringen av ekonomiskt bistånd – ett verifieringsmoment före ett större bygge, med digital ansökan, processmotor och myndighetsintegration på plats redan i fas 0. Utfall: fyra av fem leverabler klara, tre beslut fattade och åtta MVP-krav definierade. När det stod klart att flera frågor krävde tillgång till faktiska API:er valde teamet att inte utveckla vidare i blindo, utan flyttade fokus till problemförståelse och preciserade åtta öppna frågor inför nästa sprint – enligt retrospektivet mer värdefullt än att pressa fram en ofullständigt verifierad POC.

    Till sprintens dokumentation
  • Prototypsprint

    Egensotning

    Två dagar · 2–3 juni 2026 · med Räddningstjänsten Medelpad och Jämtland

    Ett byggmoment snarare än ett designmöte: en körbar prototyp av hela kedjan från medborgarens ansökan till handläggarens beslut, som ersättning för en manuell process genom flera system. Sprinten utgick från en uttalad hypotes och fyra frågor – bland annat om AI kan läsa utbildningsbevis och hur tidsbegränsade beslut byggs utan administrativ börda. Dag ett byggdes medborgarflödet och beslut fattades i rummet; dag två byggdes handläggarvyn och hela kedjan testades, med slutdemo där räddningstjänsten själv klickade igenom flödet. På två sprintdagar plus förberedelser producerades cirka 26 400 rader kod, och tvådagarsformatet tvingade fram fokus på det ”glada flödet” – undantagen flyttades till en prioriterad restlista.

    Till sprintens dokumentation
  • Teknisk sprint

    Avvikelsehantering

    10–14 augusti 2026 · välfärdssektorn, Sundsvalls kommun

    Sprinten startade inte från blankt papper: registreringsdelen fanns i testmiljö och en AI-byggd demo var godkänd som funktionell målbild. Uppgiften var att isolera de svåra tekniska frågorna – framför allt behörighetsstyrning och datasäkerhet – innan kommande verksamhetssprintar. Kärnteamet (processledare, två backend- och två frontendutvecklare) satt tillsammans hela veckan, medan verksamhetsexperten deltog vid uppstart, standups och demos och var tillgänglig däremellan. Resultatet blev bland annat auktoriseringskontroll per resurs över hela API:et med rollbaserade attributrestriktioner, allt konfigurerbart och täckt av automatiska tester, mergat bakom featureflaggor – plus en dokumenterad restlista och öppna frågor med utpekat ägaransvar.

    Till sprintens dokumentation
  • Förankringssprint

    Alkohol- och tobaksärenden

    Tre dagar · 25–27 augusti 2026 · Sundsvalls kommun

    Den första sprinten i formatet där ingenting byggs: DigIT och verksamheten landade tillsammans processen för ett nytt handläggningsstöd som på sikt ersätter två äldre system. Sju block över tre dagar täckte ansökan, anmälan, tillsyn, åtgärd och förnyelse – verksamheten deltog i halvdagsblock, utvecklingsteamet omsatte besluten till lösningsmönster på eftermiddagarna, och varje block avslutades med att beslutsloggen lästes upp och bekräftades punkt för punkt. Sprinten sattes upp mot en uttalad förväntansbild i två listor: vad veckan skulle resultera i och vad den uttryckligen inte skulle resultera i. Leveransen var en processmodell, tolv lösningsmönster (elva var planerade – behörighet och sekretess tillkom under veckan) och en beslutslogg med knappt tvåhundra beslut, noteringar och öppna frågor, samtliga märkta med vilket block de kom upp i. Varje obesvarad fråga fördes vidare klassad efter ägare till den efterföljande tekniska sprinten. Slutdemon ersattes av dialog om tillsynsprocessen, vilket gjorde att bottenplattan inte hann stämmas av formellt med verksamheten – en avstämning som därför flyttades framåt och gjordes vid den tekniska sprintens demo två veckor senare.

    Till sprintens dokumentation
  • Teknisk sprint

    Alkohol- och tobaksärenden

    Fem dagar · 7–11 september 2026 · Sundsvalls kommun

    Mellansteget mellan förankringssprinten och utvecklingssprinten i vecka 39–40: bottenplattan från förankringen omsattes till lösningsmönster och färdiga miljöer, processmotorn kom på plats med fastställd ansvarsfördelning, en ny tjänst för tillståndsdata byggdes från datamodell till CSV-import, och underliggande tjänster prövades mot flödet. Dokumentationen delades i två: en sida med det som låg fast över hela sprinten – verksamhetens frågor med DigIT:s förslag och verksamhetens ställningstagande, material verksamheten ska leverera, avgränsningar och kriterier för klart – och en daglig logg med Jira-ärenden och status per dag. Dag två hölls ett verksamhetsmöte om de frågor som följt med från förankringen. Dag tre visade sig kundbilden vara större än sprinten: Draken är ärendecentrerat och saknar kundkort. Dag fyra fattades ett beslut i två delar – ärendecentrerad kundbild med förenklad startvy nu, en CRM-tjänst som långsiktigt spår med egen workshop. Dag fem gick verksamheten igenom hela flödet på demon och stabschefen godkände processen. Demon gav sex bekräftade beslut, sex nya krav och tre processer som rymde mer än vad som var dokumenterat, och allt samlades på en sida inför utvecklingssprinten med fem blockerande punkter och en checklista i elva steg. Retrot pekade på verksamheten i rummet som starkaste framgångsfaktor och tidsbrist som tydligaste förbättringsområde – svaret blev ett passchema för verksamhetens medverkan, känt i förväg.

    Till sprintens dokumentation
  • Utvecklingssprint

    Avvikelsehantering i Draken, sprint 1 av 2

    Tio arbetsdagar · 31 augusti–11 september 2026 · vård och omsorg samt individ- och arbetsmarknad, Sundsvalls kommun

    Den första sprinten med uttalat mål att bygga det som ska driftsättas: en avvikelsehantering som ersätter ett äldre system i två förvaltningar, produktionsfärdig när sprint 2 är slut i oktober. Den tekniska sprinten i augusti fungerade som fas 0, så att arbetet kunde börja i verksamhetens frågor – vem ser vad, vilka fält behövs, hur ska flödet kännas – i stället för i infrastruktur. Verksamhet, utveckling, arkitektur och UX möttes på en daglig standup klockan 08.15 som sprintens enda fasta möte, med demo av halvfärdig funktionalitet varje dag och beslut som skrevs in samma dag, antingen i sprintloggen eller på berörd rad i funktionslistan med 114 rader. Slutdemon följde en avvikelse genom hela kedjan från rapport till avslut, inklusive överlämning till LEX-ansvarig och tillbaka, med utredningar, beslut och handlingsplan som bilagor på ärendet. Sprinten prövade en hypotes i den lösning som ska driftsättas: att enkel rapportering och verklig återkoppling ger det underlag som saknas för att se mönster och arbeta förebyggande. Retrot lyfte två saker: morgonmötet krockar med verksamheter som behöver chefen just då, och skisser och miljöer hann glida isär så att synpunkter ibland gällde något inaktuellt. Under det tre veckor långa uppehållet hölls inga standupar: den första veckan gick åt till att slutföra det slutdemon visade och få in ärendelagrets del i huvudgrenen, medan webbens del låg kvar på sprintgrenen med konflikter och fallerande tester. Verksamheten testade, men fastnade delvis på texter den redan lämnat synpunkter på, eftersom de ändrade texterna ännu inte låg i testmiljön. Sprint 2 startade den 5 oktober med en planering vid tavlan där fjorton krav fördelades på sprintens två veckor och på det som tas efter sprinten – prodsättning med härdning, utrullning i verksamheten och notifiering ligger efter sprint 2, och datumet för driftsättning var ännu inte bestämt. Efter första veckan låstes enhetschefens flöde som version 1.0 – textändringar går alltid att göra, men tiden lades på det som återstod – och Lex Sarah-flödet testades av verksamhet och team med var sin roll, från rapporten till avslutat ärende. Flödet höll hela vägen, och de nio beslutade ändringarna från testrundan var gjorda dagen efter. Frågan om utrullning gick vidare till styrgruppen, med teamets rekommendation att börja med en liten grupp.

    Till sprintens dokumentation
  • Utvecklingssprint

    Alkohol- och tobaksärenden

    Två veckor · 21 september–2 oktober 2026 · Sundsvalls kommun

    Tredje steget efter förankringssprinten och den tekniska sprinten: att bygga Draken för alkohol och tobak till en produktionsklar applikation. Målen delades per vecka – vecka 39 registrering och handläggning till beslut, vecka 40 assets, tillsyn och presentation – med ett minimimål för första veckan: ett bifallsbeslut och ett asset-id, där skalet räcker. Uppstartsmötet spikade labelstrukturen och arbetsordningen: först ett tomt ärende genom hela processkalet, därefter data fas för fas. Varje dag följdes laget runt av ett pass med verksamheten om en konkret fråga, och flera av dem landade i beslut samma dag. Vecka 39 nådde målet: ärenden kunde registreras i Katla, stegas genom processmotorn och avslutas, och folköl gick som semi-automatiskt flöde hela vägen till tillstånd. Demon dag sex bröts av en rollbugg som genrepet redan visat, men gav en rad synpunkter som blev Jira-ärenden samma eftermiddag. Vecka 40 gav automatiskt genererade tillståndsbevis med förhandsgranskning, serveringsställen på adressen, en första kundbild och en byggtidsfix som kortade byggtiden med 57 procent, och verksamheten testade registreringsformulären själv. Sista dagen visade verksamheten hur remisser hanteras i dag – med blanketter på upp till 28 sidor – vilket ändrade bilden av vad som behöver byggas. Enligt läget efter sprinten nådde sprinten ungefär halvvägs in i vecka 40: flödet går att ta sig igenom, men utredningssteget, tillsyn och åtgärd och visningen på Mina sidor återstod. Arbetet fortsätter fyra veckor till – två i samma arbetsform och två som svans för fix och städning – styrt av en restlista i tre prioritetsnivåer. Retrot i den dagliga loggen lyfte närheten till verksamheten – frågor besvarades samma dag i stället för efter de två till tre veckor som är normal ledtid – och pekade på mer förarbete om verksamhetens processer, mer tid i samma rum och mindre chatt som förbättringar.

    Till sprintens dokumentation

Lärdomar hittills

Det deltagarna framför allt lyft som framgångsfaktorer är inte ett visst AI-verktyg – det är förutsättningarna runt teamet. Lärdomarna nedan är sammanfattade från sprintarnas retrospektiv och loggar och ordnade efter hur ofta de återkommer: det som lyfts i flest sprintar står först. Detaljerna finns på respektive sprints dokumentationssida.

Före sprinten

  • Gör fas 0 på riktigt och provkör hela kedjan i förväg. Deploykedja, miljöer, AI-nycklar, testanvändare och behörigheter ska fungera före dag ett – det är den lärdom som återkommer i flest sprintar. Där förarbetet fanns, som i egensotningen, avvikelsesprinten och de utvecklingssprintar som hade en teknisk sprint som fas 0, kunde arbetet börja i verksamhetens frågor. Där det saknades gick dagar åt till uppsättning – och på avvikelsesprintens slutdemo kunde behörighetslösningen inte visas eftersom testanvändaren saknade riktiga AD-grupper. Inför utvecklingssprinten för alkohol och tobak var regeln att ett ärende skulle köras genom hela kedjan veckan innan, ”inte på måndag morgon”.
  • Säkra verksamhetens medverkan – och mandatet. Verksamheten i rummet är den framgångsfaktor som lyfts oftast, och verksamhetens tidsbrist det vanligaste förbättringsområdet. Kontrollera nyckelrollernas tillgänglighet innan datumen sätts, lägg standupen när verksamheten faktiskt kan och planera medverkan i pass som är kända i förväg. Ta också reda på vem som har mandatet: i alkohol- och tobakssprintarna hade deltagarna olika uppfattningar utifrån hur de själva arbetar, medan mandatet låg hos andra.
  • Börja i verksamhetens egen process. Inled med en dragning av hur arbetet går till i dag, och kartlägg detaljerna innan bygget – det är där arbetet avgörs och där estimaten spricker. Att förarbetet om processerna borde ha varit djupare kom upp både i förankringssprintens och utvecklingssprintens retro för alkohol och tobak: vad som får ändras på ett utfärdat tillstånd fanns inte dokumenterat någonstans, och hur remisser faktiskt hanteras visades först sista dagen. Kopiera samtidigt inte det gamla systemet: ta med det som är bra och tänk nytt i stället för att behålla något för att det känns bekant. Märk också upp det som inte är byggt i prototypen, så att tomheten inte tolkas som ett designbeslut.
  • Be om underlag, inte bara beslut. Exempeldokument, beslutsmallar, testdata, regelverk, verkliga tillståndsbevis och listor över bilagor per ärendetyp. Saknat underlag har blockerat hela lösningsmönster och tvingat fram egna sammanställningar mitt i sprinten.
  • Sätt målbilden i delar och definiera ”klart”. Skriv ner vad som ska byggas, vad sprinten ska lära organisationen och vad den uttryckligen inte ska resultera i – och vad ”klart” betyder, så att alla menar samma sak. Utvecklingssprinten för alkohol och tobak delade målen per vecka med ett minimimål för vecka ett – ett bifallsbeslut och ett asset-id – och skrev ut hur veckorna hänger ihop: halkar vecka ett påverkar det hela vecka två.
  • Lös det blockerande före start och lyft principfrågor ur sprinten. Sortera det som återstår i blockerande, nya krav och okartlagt, och ge rena teknikfrågor och informationssäkerhetsfrågor ägare och deadline före dag ett – annars hänger de öppna hela sprinten. Principfrågor som gäller flera sprintar, som behörighetsmodellen för sekretessbelagda uppgifter som följt med från förankringen genom tre sprintar, kräver ett gemensamt lösningsmönster utanför sprinten.
  • Planera för den faktiska omfattningen. Både förankringssprinten och den tekniska sprinten för alkohol och tobak blev mer än dubbelt så omfattande som planerat och spillde över till heltid, och utvecklingssprinten nådde ungefär halvvägs in i sin andra vecka och fick fyra veckor till. Räkna med frånvaro, estimera i två steg, säg till tidigt om två veckor egentligen är tre – och planera en svans för fix och städning i stället för att låta den äta upp utvecklingstiden.
  • Sortera besluten i nivåer och skriv ner riskerna. Bestäm i förväg vad som avgörs i rummet, vad som kräver verksamhetens mandat och vad som måste eskaleras – och var besluten dokumenteras. Gå igenom på uppstarten vad som får sprinten att tappa fart: svar som dröjer, beslut som skjuts upp, omfattning som växer och testning som inte blir av.
  • Välj format, bemanning och arkitektur efter osäkerheten. Organisera sprinten efter det som är dyrast att bära vidare – verksamhetslogik, teknik eller förankring – och bemanna därefter, med en kort teknisk brief före dag ett. Ta in arkitekten tidigt och planera grundarkitekturen i stället för att lita på att AI syr ihop den.

Under sprinten

  • Sitt tillsammans och skydda fokuset. Samma rum, daglig avstämning och inga andra möten är det som oftast hamnar under ”fortsätt” i retrospektiven – och ”ännu närmare” under förbättringar när avstämningarna skett digitalt. Prata direkt: att gå via någon som tolkar och återberättar ger missförstånd och extra varv. Med AI-stöd blir stegen större och ett felsteg dyrare, och tät avstämning fångar det tidigt.
  • Bygg hela kedjan tunt först. Fokusera på det glada flödet och flytta undantag till restlistan. I utvecklingssprinten för alkohol och tobak drevs först ett tomt ärende genom alla processteg och data fylldes på fas för fas – hellre alla faser med tomt skal än en färdig utredningsdel, eftersom verksamhetens input ändå skulle ändra fälten. Vecka ett nådde sitt mål.
  • Visa körande funktionalitet och låt verksamheten klicka själv. Det som byggs är referensen, inte skisserna – när de glider isär lämnas synpunkter på något inaktuellt. I avvikelsehanteringens andra sprint blev det ett uttalat beslut: testmiljön är sanningen, och AI-skissen ligger efter. Demonstrera i testmiljön snarare än lokalt, och rätta det genrepet visar: demon i alkohol- och tobakssprinten bröts av samma bugg som genrepet dagen innan. Var tydlig med att testmiljön är en utvecklingsmiljö där saker ändras.
  • Använd mandatet och låt inte stora frågor stoppa bygget. Någon ska kunna bryta en metadiskussion och fatta beslutet. Hängande arkitekturfrågor får en uttalad deadline. Frågor som visar sig större än sprinten – kundbilden har gjort det i två sprintar – avgörs i två delar: en enkel lösning nu och ett långsiktigt spår med egen ägare. Juridik och personuppgifter flaggas och byggs runt, inte gissas.
  • Behandla verksamhetens tid som sprintens knappaste resurs. Ta de öppna frågorna tidigt i veckan, ge varje pass en konkret ingång – ett verkligt ärende eller en befintlig konfiguration – och avsluta när innehållet är klart. Retrots förslag från alkohol- och tobakssprintarna: presentera ett färdigt förslag att stresstesta i stället för öppna frågor, och kom överens om en svarstid för blockerande frågor.
  • Bekräfta och logga besluten löpande. Läs upp beslutsloggen och bekräfta den, dokumentera varje verksamhetsfråga som förslag plus ställningstagande med status, och för loggen mot ärendehanteringen. Beslut som ersätts loggas båda – det ska gå att se vad som gällde när. Det gäller även textsynpunkter: i avvikelsehanteringen visste verksamheten inte vilka av de inskickade ändringarna som var införda, förrän en genomgång sorterade dem i gjorda, delvis gjorda och ej gjorda. Inspelningar av genomgångar och testrundor fångar detaljer som annars faller bort och kan bearbetas till underlag för ändringarna.
  • Säg nej och skjut upp uttryckligen. Omfattning som växer stoppas, den förhandlas inte. Det som skjuts upp läggs i en lista som verksamheten bekräftar punkt för punkt – en avgränsning som inte är bekräftad återkommer som krav. Lås ett flöde som version 1.0 när det håller, så att tiden går till det som återstår.
  • Skilj tes från beslut. Märk det som ännu inte är prövat som en tes och bestäm hur den ska prövas. I utvecklingssprinten för alkohol och tobak noterades färdiga fraser i tillsynsprotokollet och ett tillståndsbevis utan underskrift som teser, inte som fastställda krav.
  • Undvik parallella sprintar i samma grund. Beroenden mellan samtidiga sprintar pekades ut som en kostnad i retrot från både avvikelsehanteringens utvecklingssprint och den tekniska sprinten för alkohol och tobak – det ger mer synk än planerat och tar tid från testningen.
  • Låt verksamheten testa under sprinten, med ett tydligt uppdrag. Registreringsformulären släpptes till verksamheten dag sju: en testperson, uppdelning på tobak och alkohol, fokus på om frågorna är rätt, en gemensam sida för kommentarer och uppföljning dagen efter. Nästa testomgång förbereddes med en rensad testmiljö, tre till fem ärenden av olika typ och en lista över kända brister, så att verksamheten vet vad den inte ska testa. I avvikelsehanteringen testades Lex Sarah-flödet med en roll per deltagare genom hela kedjan, och fynden sorterades i beslutade ändringar, frågor där teamet återkommer med tidskostnad och en förbättringslista för senare. Skapa egna testanvändare i stället för att vänta, och kontrollera att gränssnitt och backend låser samma saker.
  • Håll koll på verktygskedjan när tempot stiger. Byggtiden i en central tjänst växte till 30 minuter mitt i sprinten och granskningskön växte med tempot. Byggtiden fick ett eget ärende och kortades med 57 procent. Samla små ändringar – nya attribut togs i ett svep i stället för en ny API-version per tillägg – och merga bakom featureflaggor när fler ska in i samma kod.
  • Få UX-resursen att räcka. Ge UX mandat över ordval och ta textfrågorna utanför standupen. När UX-resursen är hårt belastad kan AI ta fram en bruttolista ur skärmbilder som UX sedan prioriterar – men ändringar i gemensamma komponenter slår mot andra appar i produktion och behöver en leveransplan.
  • Rita mer och håll tempot hållbart. Begreppsförvirring kring system och tjänster löses bäst visuellt. Planera fler och kortare pauser, överväg att sprida ut dagarna, och använd chattkanalen för transparens snarare än som huvudkanal – svaren dröjer och det blir kontextbyten. Behövs svar från en viss person, ring.

Efter sprinten

  • Håll retrospektiv direkt och dokumentera öppet. Erfarenhetsbanken är en del av arbetssättet, och retrots fortsätt–börja–sluta blir nästa sprints arbetssätt – som när den tekniska sprintens retro skrevs in i upplägget för utvecklingssprinten.
  • Låt slutdemon vara ett formellt godkännande. Skriv ner vem som godkände. Där demon föll bort blev bottenplattan aldrig avstämd. Räkna med att en bra demo producerar backlog och lägg in den direkt – i alkohol- och tobakssprinten blev demons synpunkter Jira-ärenden samma eftermiddag.
  • Ge varje öppen fråga en ägare. Skillnaden mellan en restlista och en parkeringslista är den utpekade ägaren. Publicera frågorna med status, skilj på besvarat och utfört, och märk beslut som fattats efter sprintveckan som just det.
  • Avsluta med en sida inför nästa steg. Bekräftat, blockerande, nya krav, okartlagt, medverkan och checklista – det som kommer tillbaka från demon ska stå där bygget börjar. När sprinten inte når hela vägen: sortera restlistan efter vad som blockerar, vad som måste finnas och vad som kan vänta, som i läget efter utvecklingssprinten för alkohol och tobak. Släpp testmiljön med testinstruktioner och de kända skillnaderna mot skisserna.
  • Uppehållet mellan två sprintar är inte en paus. Det är där verksamheten testar på riktigt, och blir testningen inte av står nästa sprint utan riktning. Se till att det verksamheten testar är aktuellt: i avvikelsehanteringen låg de ändrade texterna inte i testmiljön under uppehållet, så testarna fastnade på sådant de redan lämnat synpunkter på.
  • Planera för kontinuitet och återhämtning. Mycket av förståelsen sitter i huvudet på dem som varit med – ett helt nytt team i nästa sprint fungerar inte. Gå igenom och dokumentera det som byggts, som processhanteringen, så att fler än den som byggt det kan felsöka. Växla med lugnare ”gråa veckor” och se upp för förväntningsraketen: extrem takt under en sprint är inte ett hållbart normalläge.
  • Återför snabba val till ordinarie arkitektur och förvaltning. Lokal frihet får inte bli ny teknisk skuld: i alkohol- och tobakssprinten byggdes en egen integration mellan ärendehanteringen och processmotorn, som fungerar för en verksamhet men inte skalar när fler ansluts och därför fått ett eget spår mot en gemensam meddelandekö. Förenkla samtidigt administrationen runt sprinten – listor räcker som bokföring av arbetet, och komplexa AI-genererade lösningsdokument eller tunga stories med tidsuppskattningar behövs inte.
  • Fatta beslut om nästa steg medan kunskapen är färsk. Och låt teamet fortsätta direkt medan allt sitter i huvudet. Ta också ställning till utrullningen i tid: börja med en liten grupp så att lösning och utbildning kan justeras – tidpunkten avgör hur mycket arbete som återstår efter sprinten.

Räkna med att flaskhalsen flyttar

När AI gör själva byggandet snabbare blir organisationens begränsningar tydligare: beslut, informationssäkerhet, juridik, integrationer, miljöer och förändringsledning tar en relativt större del av ledtiden. Avvikelsesprinten blottlade till exempel runt hundra säkerhetskrav för K3-klassad information, där flera inte var programmeringsfrågor utan krävde organisatoriska rutiner, kryptering, separerade nätsegment och tydligt ägarskap.

Snabbare utveckling behöver därför kombineras med gemensam arkitektur, öppna gränssnitt, återanvändning och tydligt ägarskap – annars producerar vi bara våra gamla problem snabbare. Mer om detta i blogginlägget om fokuserade sprintar.

← Tillbaka till tjänster