Backlog Refinement och AI: vad som faktiskt förändras

En praktisk genomgång av hur AI förändrar Backlog Refinement: vad som går snabbare, var riskerna uppstår, hur teamets tid omfördelas och vad som behöver kontrolleras manuellt.

26 Mar 2026 · 06:54 UTC23 min läsning

Telegram Original

Det här är den första artikeln i en serie om hur AI förändrar de klassiska mötena i ett tvärfunktionellt utvecklingsteam. Nedan börjar jag med Backlog Refinement, och i kommande material går jag separat igenom Planning, Daily, Review, Retrospective och sammanställer sedan allt i en avslutande översiktsartikel.

Jag klargör ramen direkt: nedan talar jag om refinement som en regelbunden teamsession och praktik för att förtydliga backlog items, inte nödvändigtvis som en separat officiell Scrum-händelse. Det är viktigt för terminologins precision: i Scrum Guide 2020 (RU PDF) beskrivs refinement som en ongoing activity, inte som en fristående event. I den ryska versionen av Scrum Guide 2020 formuleras tanken rakt ut: förtydligande av Product Backlog är en ständig aktivitet för att lägga till detaljer, ordning och storlek.

Backlog Refinement är en av de första platserna där AI börjar ge teamet påtaglig nytta. Det hjälper till att snabbare samla kontext, förbereda ett utkast till formulering, snabbt generera ett utkast till acceptanskriterier, hitta liknande fall och formulera en lista med öppna frågor. Den tesen stöds också av mer tillämpade arbeten: till exempel validerades generering av acceptance criteria separat i LLM-Assisted Requirements Engineering in Agile MDD , och i det industriella fallet Acceptance Test Generation with Large Language Models noterade användarna att AI-scenarier hjälpte till att upptäcka tidigare förbisedda fall. Men just därför är det särskilt lätt att hamna i fällan här: att förväxla ett välformaterat utkast med en verkligen begriplig uppgift.

Enligt min mening förenklar AI inte refinement i den bemärkelsen att teamet nu behöver tänka mindre. Det gör snarare det dyraste manuella arbetet runt det billigare — sökning, sammanfattning, paketering och initial nedbrytning. Därmed försvinner inte värdet av själva teamdiskussionen, utan förskjuts: mindre tid går åt till att ur kaoset bygga något som liknar en uppgift, och mer till att förstå om det överhuvudtaget går att ta i arbete.

“AI snabbar inte upp själva teamets överenskommelse, utan förberedelsen av materialet inför den”

Varför förändringarna märks först och främst just i Backlog Refinement

Om man tittar på de vanliga teamritualerna och mötena i agil praktik, visar sig refinement vara en av de mest känsliga för AI:s intåg. Orsaken är ganska enkel: kring refinement har det historiskt funnits mycket manuellt intellektuellt rutinarbete. Man behöver samla spridd kontext från dokument, gamla ärenden, chattar och människors minne. Man behöver förvandla en rå affärsidé till ett begripligt backlog item. Man behöver formulera affärsproblemet, scenariot, acceptanskriterierna, begränsningarna, de öppna frågorna, beroendena och möjliga gränsfall.

Det är just i detta lager som AI passar särskilt väl. Det stämmer också väl med hur man i dag diskuterar användning av LLM inom requirements engineering: modellerna är starka på sammanfattning, initial strukturering av krav, generering av utkast och stöd för analytisk förberedelse, men svagare där det krävs domänprecision, spårbarhet och ansvar för de slutliga besluten. I den meningen blir refinement verkligen en av de första processerna där nyttan med AI märks snabbt, och gränserna för dess tillförlitlighet nästan omedelbart. Det skrivs det bra om både i översikten Challenges in applying large language models to requirements engineering tasks, i den färska systematiska översikten Large Language Models (LLMs) for Requirements Engineering (RE): A Systematic Literature Review, och i det mer tillämpade arbetet LLM-Assisted Requirements Engineering in Agile MDD.

Teamet analyserar ett backlog item med hjälp av AI och agila artefakter — AI snabbar väl upp förberedelsen inför refinement, men ersätter inte den kollektiva kontrollen av innebörden.

Hur refinement såg ut före AI

Förenklat var refinement före AI mycket ofta en process av manuell sammansättning av förståelse. I backlog hamnade inte en färdig uppgift, utan snarare en affärsavsikt: förbättra onboarding, lägga till påminnelser, ge chefen en ny rapport, minska antalet försenade ärenden. Därefter började produktägaren, analytikern eller någon av leadsen manuellt samla kontext: gamla kundärenden, liknande funktioner, begränsningar i nuvarande arkitektur, gällande statusar, befintliga aviseringar, UI-mönster och allt annat som plötsligt kunde dyka upp redan i diskussionen.

Därefter försökte samma person eller ett par personer manuellt förvandla det insamlade materialet till ett första utkast: formulera affärsproblemet, beskriva scenariot, skriva acceptanskriterier, lyfta fram öppna frågor och ange möjliga begränsningar. Men även om ett sådant utkast redan fanns, gick mötet ändå ofta åt till att lyfta kontexten in i hela teamets huvuden. Produktägaren förklarade på nytt vad affären ville, analytikern berättade vad man redan lyckats ta reda på, utvecklarna lyfte arkitektoniska begränsningar, QA tog fram gränsfallsscenarier, designern och frontend diskuterade om en separat skärm behövdes och var den i så fall skulle ligga.

Samma fall: utan AI och med AI

För att inte stanna på en allmän formelnivå tar jag ett konkret fall. Produkten är en B2B LMS-plattform för företagsutbildning. Stora kunder tilldelar anställda obligatoriska kurser inom compliance, säkerhet och interna regelverk. Från affären kommer en förfrågan: man behöver lägga till automatiska e-postpåminnelser till anställda som inte slutfört en obligatorisk kurs före deadline.

Vid första anblicken ser det ut som en enkel uppgift om att skicka ett mejl. Men redan i de första stegen blir det tydligt att det här i praktiken finns många vägval: vem som exakt ska räknas som att inte ha slutfört kursen, när påminnelserna ska skickas, hur utskicken ska dedupliceras, hur detta konfigureras av kunden, om en logg över utskick behövs, vad man ska göra med time zone, vilket språk mejlet ska vara på och om archived och inaktiverade användare ska uteslutas.

I läget utan AI kom teamet fram till dessa frågor huvudsakligen genom lång manuell förberedelse och ett omfattande samtal på själva mötet. Först lyfte Produktägaren kundkontexten. Sedan gick analytikern manuellt igenom interna material: letade efter gamla liknande förfrågningar, tittade på notifikationstjänsten, kontrollerade aktuella statusar för assignment’er, förekomsten av schemaläggarjobb, fält för språkinställning och tidszon. Redan i detta skede dök verkliga begränsningar upp: systemet har e-postmallar, men bara för transaktionella mejl; tidszonen lagras på kundnivå, inte på användarnivå; det finns inga loggar över utskick; det finns inte heller någon separat påminnelsemodell i produkten.

Därefter sammanställde analytikern manuellt ett första utkast till kravspecifikation, men det förblev ändå omoget. Till exempel kunde de exakta statusar som påminnelser ska skickas för, dedupliceringslogiken, den minsta omfattningen av arbete för UI, fallback för språk eller gränserna för den första versionen inte vara fastställda i det. Och redan på själva refinement-sessionen byggde teamet ihop uppgiften direkt under samtalet. Det var just där det blev tydligt att påminnelser bara behövs för obligatoriska kurser, att statusarna not_started och in_progress passar, medan expired hellre inte bör tas med i den första versionen, att support och kundframgångsteam snabbt skulle drunkna i frågor utan en logg över utskick, och att det utan ett separat skydd skulle uppstå dubbletter när schemaläggarjobben körs igen.

I läget med AI ser samma fall annorlunda ut. Produktägaren laddar in en kort sammanfattning från kundframgångsteamet, de senaste kundärendena och den råa ursprungliga förfrågan i AI:n. AI:n grupperar snabbt kundernas smärtpunkter, lyfter fram återkommande förväntningar och hjälper till att formulera problembeskrivningen. Analytikern ber AI:n lyfta fram allt som rör notifikationsflöden, tilldelningsstatusar, schemaläggarjobb, språkinställning, tidszon och liknande uppgifter i Jira. Backend kör i förväg beskrivningen av den nuvarande notifikationsarkitekturen genom AI:n och ber om ett förslag på tekniskt angreppssätt. Frontend och designern kontrollerar snabbt var det är mest logiskt att bygga in inställningarna och historiken över utskick. QA tar fram en startlista över gränsfall och tidsrisker.

Här uppstår vanligtvis en naturlig fråga: vad händer om AI:n har missat något? Hur mycket kan man egentligen lita på en sådan kort sammanfattning, särskilt när källbasen är stor? Forskning och praktiska fall ger här en ganska nykter bild: LLM:er kan verkligen påskynda genereringen av användarberättelser, utkast till acceptanskriterier och första kravspecifikationer, men resultatets kvalitet beror starkt på ingångskontexten, domänen och den efterföljande mänskliga granskningen. Därför är det bra att också ha mer tillämpade arbeten i åtanke som AI-Generated User Stories: Are They Good Enough? och LLM-Assisted Requirements Engineering in Agile MDD: de visar tydligt att generering av ett starkt utkast och beredskap för utveckling inte är samma sak.

Enligt min erfarenhet av att arbeta med Cursor är det i tillämpade scenarier ganska sällan jag tvivlar på att modellen kan göra ett användbart första genomlopp över en stor mängd källor. Det som är mycket viktigare är något annat: hur väl jag formulerade uppgiften, vilka begränsningar jag satte, vilka förtydligande frågor jag hann lägga till och hur jag faktiskt organiserade kontrollen av resultatet. När jag känner tvekan försöker jag inte lösa den med frågan "tror jag på AI eller inte" — jag förtydligar helt enkelt förfrågan, ber att få se källorna separat, lyfter fram de omtvistade punkterna, separerar fakta från antaganden eller bygger om svaret med en annan ram. I den meningen är arbetet med AI mycket likt coaching: det är nyttigt att kunna ställa precisa frågor som inte bara startar genereringen utan styr modellens tänkande i rätt riktning.

Detta är naturligtvis min personliga erfarenhet, inte en universell regel. Kanske skriver jag separat ytterligare ett material just om tillit till AI, kvaliteten på förtydligande frågor och kontrollerad verifiering av resultatet. För refinement är detta särskilt viktigt: ju större källbasen är och ju övertygande den korta sammanfattningen är, desto högre är risken att förväxla en stark förberedelse med redan verifierad förståelse.

"Ju större källbasen är och ju övertygande den korta sammanfattningen är, desto högre är risken att förväxla en stark förberedelse med redan verifierad förståelse"

Som ett resultat kommer teamet till refinement inte längre med en rå idé, utan med ett ganska starkt underlag: det finns ett utkast till användarberättelse, ett utkast till acceptanskriterier, öppna frågor, en risklista, en preliminär teknisk ansats och ett UI-förslag. Därför blir själva mötet kortare och mer konkret. Teamet lägger inte längre lika mycket tid på att lyfta den grundläggande kontexten och diskuterar huvudsakligen de omtvistade punkterna: ska man inkludera expired, ska man ha en separat tidszon per användare, behövs en sändningslogg i den första releasen, ska man begränsa sig till fasta triggers, hur skyddar man sig mot dubbletter och vad ska räknas som gränserna för den första versionen.

Vad består teamets framsteg i?

När teamet precis börjar använda AI fungerar det mest som en snabb generator av ett första utkast. Men i takt med mognaden är nästa logiska steg att sluta arbeta enbart med en allmän modell och gradvis börja flytta över det som tidigare bara fanns i människors minne till teamets styrda kontext. Det kan vara produktprinciper, mallar för acceptanskriterier, vanliga orsaker till att en uppgift avvisas på refinement, typiska gränsfall, arkitektoniska begränsningar, en uppsättning typiska förtydligande frågor, organisationens interna regelverk, Definition of Ready och Definition of Done på organisations- och teamnivå samt exempel på bra lösningar för liknande fall.

Då börjar kvaliteten på det första utkastet verkligen öka. Inte för att modellen plötsligt "förstod domänen själv", utan för att teamet har lärt sig att systematiskt ladda in sina egna tankemönster, interna begränsningar och verifieringsregler i den. Och här blir refinement inte bara en plats för att granska uppgiften, utan också en plats där teamet gradvis tränar sitt eget AI-lager.

Vad förändras per roll

Nedan är det nyttigt att inte bara titta på rollerna som abstrakta funktioner, utan också på konkreta handlingar i det simulerade fallet med påminnelser om obligatoriska kurser. Det är just så skillnaden mellan läget utan AI och med AI blir verkligt märkbar.

Roll	Utan AI	Med AI
Produktägare	Lyfter kundkontexten manuellt, sammanställer förfrågningar från kundsupportteamet, förklarar affärsproblemet på nytt på mötet.	Förbereder en avidentifierad input, ber AI gruppera kundernas smärtpunkter, tar med ett utkast till problemformulering och en lista över omtvistade produktbeslut till mötet.
Affärsanalytiker	Söker liknande fall, samlar manuellt statusar, begränsningar, beroenden och skriver sedan om allt till det första utkastet till kravställning.	Organiserar förfrågan till AI utifrån källor, stämmer av den korta sammanfattningen mot källorna, redigerar acceptanskriterierna, dokumenterar öppna frågor och det som modellen kan ha missat.
Backend-utvecklare	Sätter sig ofta först på refinement på djupet in i problemet, lyfter begränsningar i aviseringstjänsten och risker med dubbletter direkt under diskussionens gång.	Får före mötet ett första genomlopp av tekniska alternativ, kontrollerar i förväg deduplicering, schemaläggarens uppgifter, audit trail och gränserna för den första versionen.
Frontend-utvecklare	Försöker tillsammans med designern på mötet förstå om en separat skärm behövs, var inställningarna ska ligga och vad som verkligen ingår i det minimala UI:t.	Tittar före mötet på AI-utkastet till UI-inbäddning, markerar i förväg omtvistade punkter kring inställningar, tillstånd och gränssnittsbegränsningar.
Kvalitetsingenjör / QA-ingenjör	Kopplas in huvudsakligen på mötet, plockar fram negativa scenarier, statuskollisioner och tidsrisker redan i det gemensamma samtalet.	Får före mötet en startlista med gränsfall, kontrollerar att AI inte har missat dubbletter, tidszoner, språkliga fallback-scenarier och undantag för användarstatusar.
UX/UI-designer	Sätter sig in i uppgiften under diskussionens gång och uppskattar på plats om en ny skärm, ett inställningsblock eller en sändningshistorik behövs.	Testar snabbt tillsammans med frontend flera varianter av UI-ansats och kommer redan med ett genomtänkt förslag, inte från noll.
Scrum master	Samlar deltagarna, håller tiden, hjälper till att inte tappa bort sig i den kaotiska kontextuppbyggnaden och för tillbaka teamet till kärnan när diskussionen sprider ut sig.	Lägger mindre tid på organisatorisk mekanik och avstämning av grundkontext, mer på facilitering av omtvistade beslut, dokumentation av öppna frågor och kvalitetskontroll av diskussionen.

Fördelar, risker och frigjord tid

Nyttan av AI i refinement är ganska påtaglig. Kontexten samlas snabbare, ett utkast till uppgiften uppstår snabbare, diskussionen startar lättare och resultaten paketeras bättre. Men just i refinement visar sig AI-riskerna också mycket tidigt. Den mest uppenbara risken är falsk klarhet. AI kan skapa prydliga backlog items som ser bra ut visuellt och strukturellt. Därför är det lättare för teamet att lura sig självt med känslan av att uppgiften redan är förstådd, trots att produkt- och teknikluckor fortfarande finns kvar i den.

Här är det bra att kalla saker vid deras rätta namn. För det första är det automatiseringsbias och överdrivet beroende — benägenheten att alltför gärna acceptera systemets rekommendation och gå från aktiv granskning till mer passiv övervakning. I NIST-profilen för generativ AI beskrivs detta direkt som överdrivet förtroende för AI-system, och i den empiriska studien Automation Bias in AI-Decision Support: Results from an Empirical Study visas att hög upplevd nytta av systemet kan öka falsk samstämmighet med dess fel, medan kvaliteten på användarutbildningen minskar sannolikheten för en sådan effekt. För det andra är det modellhallucination — en slutsats som är trovärdig men inte bekräftad av källor. För refinement är detta särskilt kritiskt, eftersom AI nästan alltid arbetar genom sammanfattning av dokument, tickets och korrespondens, vilket innebär att risken inte bara ligger i ett “vackert men påhittat utkast till acceptanskriterier”, utan också i en tyst förvrängning av det ursprungliga sammanhanget. Det är just därför AI i refinement oftare gör fel inte i textens stil utan i kontextens fakta — och denna risk beskrivs väl i arbetet On Faithfulness and Factuality in Abstractive Summarization. Ett praktiskt motmedel här är ganska enkelt: be modellen skilja fakta från hypoteser, kräva hänvisningar till källor och bygga en kort sammanfattning så att den snabbt kan spåras tillbaka till dokument, tickets och teamets beslut.

Det finns också ett annat risklager — data. I fallet ovan arbetar AI med kundförfrågningar, interna systembeskrivningar och användarsignaler. Därför är det viktigt att teamet i förväg kommer överens om vad som överhuvudtaget får skickas till modellen och vad som inte får det. För generativ AI begränsas risken inte bara till prompten: personuppgifter kan hamna i indata, i utdata och till och med genom modellens memorization/regurgitation. Om personuppgifter eller känslig kundkontext förekommer i arbetet bör därför grundläggande principer för datahygi vara obligatoriska: minimera datamängden i prompter, avidentifiera indata där det är möjligt, inte dra in rå export i modellen utan filtrering, tydligt förstå ändamålet med behandlingen och inte ta leverantörens påståenden som «vi behandlar inte personuppgifter» eller «modellen är anonym» för givna utan verifierbara organisatoriska och tekniska kontroller. Det är dessutom nyttigt att i förväg fastställa den rättsliga grunden för behandlingen, den minsta nödvändiga uppsättningen fält, roller och ansvar inom processen samt, där det är tillämpligt, krav på information till registrerade. Om scenariot omfattar personuppgifter och omfattningen eller riskerna är betydande kan det vara värt att i förväg bedöma om en DPIA behövs och separat dokumentera detta beslut. I europeisk kontext stämmer detta väl överens både med principerna i GDPR Article 5, och med CNIL:s praktiska rekommendationer för AI-systemutveckling, samt med EDPS guidance on Generative AI och EDPB Opinion 28/2024.

Och här uppstår ännu en viktig fråga: vart tar den frigjorda tiden för specialisterna vägen. Det enklaste alternativet är att försöka pressa in ännu fler uppgifter i den. Ett mer moget alternativ är att investera besparingen i besluts kvalitet, minskning av teknisk skuld, utveckling av interna mallar, utbildning, dokumentation och åtminstone bättre hantering av teamets uppmärksamhet. I seriens avslutande översiktsartikel kommer jag särskilt att berätta om att AI inte bara förändrar processen utan också kulturen för hur teamtid används.

Nya dolda kostnader som inte kan ignoreras

För att samtalet om effektivitet inte ska verka alltför slätstruket är det viktigt att också lägga till baksidan: AI ger sällan “ren besparing” utan nya typer av arbete. En del tid går nu åt till att förbereda data, ställa in åtkomst till källor, underhålla prompter och mallar, verifiera källor, dokumentera beslut och mänsklig granskning. Ett sådant synsätt stämmer väl överens också med praxis för risk management för generativ AI: till exempel NIST-profilen för generativ AI lägger inte bara vikt vid fördelarna med automatisering, utan också vid behovet av oversight, documentation och ledningskontroll.

Scenariobaserad uppskattning av arbetsinsats för en Backlog Refinement (scenario)

Nedan följer inte en "genomsnittstemperatur för marknaden", utan en scenariomodell för samma Backlog Refinement för samma team på sju personer: PO, BA, backend, frontend, QA, designer och Scrum Master. Det är en uppskattning av en stor eller betydligt osäker backlog item, inte en liten välförstådd story. Värdet av dessa siffror ligger inte i exaktheten på minuten, utan i jämförelsen av kostnadsstrukturen: vart tiden gick tidigare och vart den går nu.

Härefter handlar det specifikt om arbetstimmar per en stor backlog item — förberedelse, diskussion och kort efterarbete efter mötet — och inte om själva mötets varaktighet som sådan. Själva mötet brukar också kortas, men en del av arbetet flyttar helt enkelt över till asynkron förberedelse, förtydligande genomgångar och obligatorisk manuell kontroll.

Anmärkning till beräkningen av arbetsinsats: historiskt beskrevs refinement även i Scrum Guide 2017 (RU PDF) som en ongoing process, och där förekom en riktlinje om att det vanligtvis tar högst 10 % av utvecklingsteamets tillgängliga kapacitet. I Scrum Guide 2020 (RU PDF) finns denna riktlinje inte längre, så tabellen nedan bör hellre läsas som en scenariomodell för att jämföra två arbetssätt än som en norm.

Det är viktigt att särskilt förklara: kolumnen "Med AI" nedan inkluderar redan det grundläggande nya arbetet utan vilket detta scenario inte fungerar — förberedelse av indata, förtydligande frågor, första granskning av sammanfattningen, verifiering av tvistiga punkter och minimal mänsklig kontroll. Det vill säga, den slutliga vinsten i tabellen är inte en "rå" besparing före hänsyn till nya kostnader, utan en mer realistisk scenariouppskattning efter att dessa i grunden inkluderats.

För att denna uppskattning ska vara reproducerbar är det praktiskt att beräkna den enligt ett enkelt schema: T_AI = T_base × ((1 − p) + p × s) + o, där T_base — tid utan AI, p — andel arbete som kan accelereras, s — accelerationskoefficient för denna del, och o — nytt arbete för dataförberedelse, förtydligande frågor och kontroll av resultatet.

Nedan följer ett kalibrerat exempel specifikt för detta basscenario. Dess uppgift är inte att bevisa en universell norm, utan att visa hur samma modell kan reproducera siffrorna från tabellen för ett konkret fall. I ett verkligt team är det bättre att kalibrera sådana parametrar utifrån de 3–5 senaste Backlog Refinement och sedan få fram sitt eget intervall.

# Calibrated to reproduce the table (base scenario)
# T_ai = T_base * ((1 - p) + p * s) + o
roles = {
    "PO": {"T_base": 4.5, "p": 0.75, "s": 0.20, "o": 0.7},
    "BA": {"T_base": 10.0, "p": 0.70, "s": 0.20, "o": 0.6},
    "BE": {"T_base": 3.5, "p": 0.75, "s": 0.20, "o": 0.6},
    "FE": {"T_base": 3.0, "p": 0.75, "s": 0.20, "o": 0.3},
    "QA": {"T_base": 3.0, "p": 0.50, "s": 0.20, "o": 0.2},
    "UX": {"T_base": 3.0, "p": 0.50, "s": 0.20, "o": 0.2},
    "SM": {"T_base": 2.5, "p": 0.50, "s": 0.20, "o": 0.0},
}

def t_ai(x):
    return x["T_base"] * ((1 - x["p"]) + x["p"] * x["s"]) + x["o"]

total_base = sum(r["T_base"] for r in roles.values())
total_ai = sum(t_ai(r) for r in roles.values())

print("Total base:", round(total_base, 1))
print("Total AI:", round(total_ai, 1))
print("Gain:", round(total_base - total_ai, 1))

for role, x in roles.items():
    print(role, round(t_ai(x), 1))

Roll	Utan AI	Med AI (med hänsyn till nytt arbete)	Vad förändras
Produktägare	4,5 tim	2,5 tim	Samlar snabbare kundkontext, men lägger en del tid på att förbereda indata och förtydligande frågor
Affärsanalytiker	10 tim	5 tim	Mindre manuell sökning och omskrivning, mer verifiering, redigering och kontroll av att AI inte missat något viktigt
Backend-utvecklare	3,5 tim	2 tim	Får snabbare en första teknisk analys, men kontrollerar separat arkitekturbegränsningar och risk för dubbletter
Frontend-utvecklare	3 tim	1,5 tim	Uppskattar snabbare UI-inbäddning och inställningar, men engageras tidigare i kontroll av tvistiga punkter
Kvalitetsingenjör / QA-ingenjör	3 tim	2 tim	Får tidigare gränsfall och tidsrisker, men engageras starkare i kontroll av förbisedda fall och negativa scenarier
UX/UI-designer	3 tim	2 tim	Samlar snabbare ett första förslag på UI-ansats och utesluter i förväg onödiga gränssnittsalternativ
Scrum Master	2,5 tim	1,5 tim	Mindre tid på organisatorisk kontextanpassning, mer på facilitering av beslut och dokumentation av öppna frågor
Totalt	29,5 tim	16,5 tim	Scenariovinst — cirka 13 arbetstimmar på en sådan Backlog Refinement redan efter hänsyn till det grundläggande nya arbetet

Scenariospann: hur vinsten kan variera

Scenario	Utan AI	Med AI	Nettovinst	När det är så
Försiktigt	24–28 tim	18–21 tim	4–10 tim	Källorna är ofullständiga, mycket manuell kontroll, teamet bygger just upp mallar för arbete med AI.
Bas	28–32 tim	15–18 tim	10–15 tim	Ungefär så ser det modellerade fallet ut: AI accelererar förberedelsen väl, men det nya arbetet med verifiering är redan inräknat.
Starkt	30–36 tim	14–17 tim	13–19 tim	Teamet har bra källor, återanvändbara mallar och tydliga regler för datahygien och manuell kontroll.

Vilket nytt arbete som redan ingår i scenariot med AI

Tabellen nedan upphäver inte den slutliga vinsten från den första. Den förklarar bara genom vilka nya åtgärder en del av den sparade tiden återförs till processen — och varför nettoeffekten ändå förblir märkbar även efter detta.

Nytt arbetsområde	Vad som tillkommer med AI	Varför det behövs
Förberedelse av indata	Rensning, avidentifiering, sammanfattning av relevant kontext	För att inte överbelasta modellen med skräp och inte dra in onödiga data
Förtydligande frågor	Upprepade genomgångar, förtydligande av svarets ram, begäran att skilja fakta från antaganden	För att inte ta det första vackra svaret för den slutliga förståelsen
Mallinställning	Prompter, mallar för ärenden, regler för resultatets format	För att AI ska ge ett användbart, återanvändbart utkast och inte slumpmässig text
Faktakontroll	Kontroll av källhänvisningar, termer, statusar och begränsningar	För att fånga modellens hallucinationer och falska klarhet före mötet
Dokumentering av tillit	Fastställande av vad som faktiskt kontrollerades manuellt och varför resultatet går att lita på	Så att teamet inte ersätter ansvar med ett snyggt utkast

Skillnader per fas

Fas	Utan AI	Med AI
Insamling av kontext före mötet	Lång manuell sökning i dokument, ärenden och människors minne	Första genomgången av källor och en kort sammanfattning går märkbart snabbare
Utkast till uppgiftsbeskrivning	Skrivs manuellt och förblir ofta rå	Det finns ett starkt underlag som teamet kan kritisera och förfina
Själva Backlog Refinement	Mycket tid går åt till att jämna ut förståelsen	Fokus flyttas till omtvistade beslut, beroenden och gränser för första versionen
Efterarbete efter mötet	Ofta måste uppgiftsbeskrivningen skrivas om nästan från grunden	Resultaten är redan väl paketerade och kräver mindre manuellt efterarbete

Kvalitetschecklista för AI-förberedelse inför refinement

Viktigt: denna Definition of Ready är teamets interna praxis, inte en del av Scrum Guide. Här behövs den som skydd mot falsk klarhet, luckor och otydligt ansvar i AI-förberedelsen.

Definition of Ready för AI-utkast

Fakta är åtskilda från antaganden: teamet förstår vad som hämtats från källor och vad som föreslagits av modellen.

Det finns länkar eller tydliga hänvisningar till källor för centrala produkt- och teknikpåståenden.

Öppna frågor är inte gömda under prydlig text utan lyfts fram explicit.

Domäntermer, statusar, begränsningar, roller och beroenden är kontrollerade.

För varje centralt påstående är bevisnivån tydlig: det är ett faktum från en källa, en arbetshypotes eller ett antagande från modellen.

Gränsfall, negativa scenarier och tidsrisker är kontrollerade separat.

Det är tydligt vilka data som inte fick skickas till modellen och vilka dataskyddsåtgärder som vidtogs.

Ägare för granskning är utsedda per typ av påstående: affärslogik, arkitektonisk genomförbarhet, testbarhet och datahantering.

Teamet har enats om att AI-utkastet är råmaterial för diskussion, inte en nästan färdig uppgift.

För att denna checklista inte ska förbli alltför abstrakt, så här skulle den se ut i vårt case med e-postpåminnelser:

AI föreslår att statusarna not_started, in_progress och expired inkluderas — teamet markerar explicit att expired ännu är en hypotes, inte en bekräftad regel för första versionen.
I den korta sammanfattningen står det att aviseringar ska skickas enligt användarens tidszon — backend stämmer av detta mot källorna och bekräftar att tidszonen i det nuvarande systemet endast lagras på klientsidan, och att övergångar mellan tidszoner och DST måste kontrolleras separat.
AI lade till utskickshistorik som en "självklar" del av lösningen — Produktägaren och BA beslutar separat om detta är en obligatorisk del av första versionen eller en förbättring i nästa release, eftersom det även finns en fråga om revision och belastning på supporten.
QA får inte bara en lista med gränsfall utan en konkret uppgift att kontrollera dubbletter vid omkörning av schemaläggarjobb, språkliga fallback-scenarier, undantag för archived och inaktiverade användare samt negativa scenarier kring deadlines.
Backend kontrollerar separat rate limits, throttling, deliverability och hur systemet beter sig vid upprepade utskick och leverantörsfel.
PO och BA validerar dessutom aviseringspolicyn: vem som får ta emot påminnelser, var opt-out eller kundspecifika undantag behövs, och vad som anses vara acceptabelt beteende för obligatoriska kurser.

För ett sådant case är det bra att även lyfta två praktiska saker som ofta dyker upp närmare produktion: deliverability blir snabbt en belastning för supporten och kundteamet om det inte finns en bra diagnostik för "varför kom inte mejlet fram", och quiet hours och kalenderfönster visar sig ofta inte vara en "extra funktion" utan ett företagskrav från kunden.

Vem kontrollerar vad manuellt

Vad vi kontrollerar	Vem som äger	Exempel i LMS-caset
Mål och produktpolicy	PO och BA	Vem som ska få påminnelser och när, vilka undantag som är tillåtna, var gränserna går för första versionen.
Korrekthet i regler och statusar	BA	Vilka statusar som anses vara "inte slutförd", vad som ska göras med `expired` och var detta redan är bekräftat av källor.
Arkitektoniska begränsningar	Backend-utvecklare	Deduplicering, schemaläggarjobb, idempotens, revisionslogg, rate limits och beteende vid upprepade utskick.
UI-gränser för första versionen	Frontend-utvecklare och UX/UI-designer	Var inställningarna finns, om en separat historikskärm behövs och vilka gränssnittsscenarier som faktiskt ingår i första versionen.
Negativa och tidsrelaterade scenarier	Kvalitetsingenjör / QA-ingenjör	DST, tidszoner, språkliga fallback-scenarier, undantag för archived och inaktiverade användare samt dubbletter vid omkörning av schemaläggarjobb.
Facilitering av beslut och öppna frågor	Scrum Master	Vad som redan är beslutat, vad som fortfarande är omtvistat och var teamet måste göra en medveten kompromiss.
Data hygiene och tillåtlighet för data	PO/BA och, om sådan finns, Security eller DPO	Vad som får skickas till modellen, vad som måste avidentifieras och vilka kontroller som är obligatoriska före start av AI-förberedelsen.

Vad jag skulle rekommendera teamet

Att inte betrakta AI-utkastet som en färdig uppgift bara för att det ser bra ut.
Komma överens om vilka delar av kontexten teamet måste granska manuellt före mötet och vilka som ska granskas under själva mötet.
Gradvis flytta över egna produkt- och processmönster till teamets AI-lager i stället för att bara använda den gemensamma chatten "som den är".
Dra inte ner refinement mekaniskt bara för att förberedelsen har blivit snabbare.
Fatta medvetna beslut om vart den frigjorda tiden går: till kvalitet, lärande, dokumentation, teknisk skuld eller återhämtning av teamets uppmärksamhet.

Det är särskilt viktigt att komma ihåg gränserna för när detta scenario är tillämpligt. AI-effekten kommer att variera mycket beroende på dokumentationens mognad, tillgången till interna källor, produktens domänkomplexitet och hur väl teamet kan förvandla implicit kunskap till återanvändbar kontext. Där underliggande data är svag kan AI snabba upp paketeringen, men förbättrar inte nödvändigtvis kvaliteten på besluten.

Slutsats

Om man ska sammanfatta det helt kort skulle jag formulera AI:s huvudsakliga effekt för refinement så här: AI snabbar inte upp själva teamets överenskommelse, utan förberedelsen av materialet inför den. Det är just därför refinement blir snabbare i början: kontexten samlas snabbare, ett utkast uppstår snabbare, grundläggande frågor och risker identifieras snabbare och resultaten paketeras snabbare.

Men det gör inte refinement automatiskt enklare. För så snart kostnaden för förberedelse sjunker ökar värdet av det som AI ännu inte klarar av på riktigt: att förstå domänen, känna de verkliga begränsningarna, upptäcka falsk klarhet, hantera data varsamt och hjälpa teamet att fatta medvetna avvägningar.

Därför är det bästa sättet att se på AI i refinement detta: det tar bort en del av det dyra manuella arbetet runt praktiken, men gör den mänskliga kontrollen av innebörden ännu viktigare. Ju enklare det blev att producera backlog-items, desto viktigare blev det att förstå vilka av dem som verkligen är redo för diskussion och vilka som bara ser bra ut. I kommande artiklar i serien blir det intressant att se hur denna förskjutning påverkar inte bara processen utan också kulturen kring hur teamets tid används.

Källor och riktmärken

← Alla essäer