Grooming av uppgifter i mobilutveckling: essens, mål och genomförandeprocess

Vad är grooming av uppgifter?

Backlog Grooming (refinement) — processen att förbereda Product Backlog-uppgifter för framtida sprintar. Ett möte där Product Owner och utvecklingsteamet går igenom uppgifter: förtydligar krav, lägger till Acceptance Criteria, bedömer komplexitet, identifierar beroenden och risker. I Scrum Guide finns ingen obligatorisk “grooming”-händelse — det är en extra praxis som Scrum-team inför för att minska osäkerheten vid Sprint Planning. Rekommenderad frekvens — 1 gång per sprint, högst 60 minuter.

Termen “kamning” (grooming) återspeglar essensen: teamet “kammar” backloggen, tar bort föråldrade uppgifter, förtydligar oklara och delar upp alltför stora. Inom mobilutveckling är grooming särskilt viktigt på grund av plattformsspecificitet: en uppgift för Android kan skilja sig från iOS-versionen i komplexitet, man måste ta hänsyn till targetSdk, compileSdk, kompatibilitet med API-nivåer. Utan grooming förvandlas Sprint Planning till kaos: teamet ser uppgifterna för första gången och kan inte uppskatta dem, vilket leder till oförutsägbarhet och förseningar.

Resultatet av grooming — flera uppgifter redo för Sprint Planning: de har beskrivning, Acceptance Criteria, uppskattning och motsvarar Definition of Ready. Product Owner bör grooma uppgifter i prioritetsordning: de närmast den aktuella sprinten — mest detaljerade. Uppgifter för 3-4 sprintar framåt — endast på epiknivå. Progressive Refinement-teknik: ju närmare uppgiften är sprinten, desto mer detaljerad är dess beskrivning. För uppgifter i den aktuella sprinten — full refinement (AC, design, API-specifikation). För uppgifter om 2 sprintar — story-level (user story utan implementeringsdetaljer). För uppgifter om 3+ sprintar — epic-level (endast namn och affärsvärde).

Definition of Ready: när är en uppgift redo för sprinten

Definition of Ready (DoR) — checklista över kriterier som uppgiften måste uppfylla innan den inkluderas i Sprint Backlog. DoR är ett kontrakt mellan Product Owner och teamet: PO garanterar att all information för utveckling finns tillgänglig, teamet garanterar att de kan uppskatta och utföra uppgiften. DoR är inte universell — varje team bestämmer sin egen uppsättning kriterier. Utan DoR kan uppgiften hamna i sprinten med oklara krav, vilket leder till omarbete och förseningar.

Typisk DoR för mobilutveckling: 1) Acceptance Criteria är beskrivna (acceptanskriterier i Given-When-Then-format). 2) Designmockup är klar i Figma (för UI-uppgifter) med alla tillstånd: default, loading, error, empty state. 3) API-specifikation är godkänd (OpenAPI/Swagger, exempel på förfrågningar och svar). 4) Uppskattning i story points finns. 5) Beroenden av andra uppgifter är identifierade. 6) Uppgiften är inte beroende av ofärdiga externa komponenter. 7) Mobil specificitet: mål-OS-versioner, behov av feature flag, stöd för gamla API-nivåer är fastställda.

Tekniker för uppgiftsuppskattning

Planning Poker — den mest populära uppskattningstekniken vid grooming. Varje utvecklare får en kortlek med Fibonacci-tal (1, 2, 3, 5, 8, 13, 21). PO visar uppgiften och förklarar den. Efter diskussion visar alla samtidigt sitt kort. Om uppskattningarna skiljer sig kraftigt (t.ex. 3 och 13) — förklarar utvecklarna sin uppskattning, varefter de röstar igen. Iterationer upprepas tills konsensus nås. Syftet med Planning Poker är inte exakt uppskattning, utan att identifiera skillnader i förståelsen av uppgiften.

T-Shirt Sizing — en förenklad teknik för snabb uppskattning: XS (1 SP), S (2), M (3), L (5), XL (8), XXL (13). Lämplig för initial sortering av backloggen när det finns många uppgifter och man snabbt behöver uppskatta storleksordningen. Efter T-Shirt Sizing görs en mer exakt uppskattning genom Planning Poker för uppgifter i nästa sprint. Affinity Estimation — gruppsortering av uppgifter efter relativ komplexitet utan siffror; uppgifter läggs på bordet från enklast till mest komplexa, grupperas sedan i kluster, varje kluster får en uppskattning.

Inom mobilutveckling måste uppskattning ta hänsyn till plattformskomplexitet. En Android-uppgift kan uppskattas till 5 SP, och samma uppgift för iOS — till 3 SP (eller tvärtom). Detta är normalt: olika plattformar har olika implementeringskomplexitet. Tips: uppskatta varje plattform separat om teamet är cross-platform. Använd en relativ skala: basuppgift (t.ex. en skärm med text och knapp) = 1 SP. Allt annat — relativt till den. Enligt Scrum.org (2025) når teamets uppskattningsnoggrannhet efter 3-4 sprintar ±20% av den faktiska komplexiteten.

Dekomposition: hur man delar stora uppgifter

Uppgifter större än 8 SP bör dekomponeras till mindre. Stora uppgifter kan inte slutföras på en sprint, är svåra att uppskatta och ger ingen känsla av framsteg. Dekompositionsteknik: dela uppgiften efter horisontella lager (UI → ViewModel → Repository → Network/DB) eller efter vertikala snitt (feature: en hel skärm). Horisontell dekomposition är mer lämplig för mobilutveckling: Sub-task 1 — UI-layout (XML/Jetpack Compose/SwiftUI), Sub-task 2 — ViewModel + State, Sub-task 3 — Repository + Network, Sub-task 4 — Enhetstester.

Vertikal dekomposition — att skära en user story i mindre berättelser med oberoende värde. Exempel: Epic “Kundvagn” → Story 1 “Lägga till produkt i kundvagnen”, Story 2 “Visa kundvagnen”, Story 3 “Ta bort produkt från kundvagnen”, Story 4 “Genomföra beställning”. Varje Story har sitt eget affärsvärde och kan släppas oberoende. SPoK (Story Points on Kano): rangordna Stories efter affärsvärde (Must-have, Should-have, Could-have) och implementera i värdeordning.

Checklista för dekomposition vid grooming: 1) Är uppgiften större än 8 SP? → Dekomponera. 2) Finns Acceptance Criteria? → Om inte — lägg till. 3) Beror på andra uppgifter? → Identifiera och dokumentera beroenden. 4) Innehåller osäkerhet? → Lägg till Spike (undersökning) före huvuduppgiften. 5) Behövs design? → Kontrollera mockup-beredskap. INVEST-regeln: Independent (oberoende av andra), Negotiable (kan diskuteras), Valuable (värdefull för verksamheten), Estimable (kan uppskattas), Small (liten), Testable (testbar). Om uppgiften inte uppfyller INVEST — är den inte redo för sprinten.

Groomingprocessen: steg för steg

Steg 1: Uppvärmning (5 minuter). Scrum Master påminner om målet med grooming och DoR. Teamet tittar på tavlan, PO visar vilka uppgifter som kommer att diskuteras. Steg 2: Uppgiftsgranskning (30 minuter). PO presenterar i tur och ordning uppgifter från slutet av den aktuella sprinten och början av nästa. För varje uppgift: namn, beskrivning, Acceptance Criteria (om de finns), länk till design, API-specifikation. Teamet ställer förtydligande frågor: “Finns det en mockup för tomt tillstånd?”, “Vilken HTTP-metod?”, “Vad är iOS minimum deployment target?”.

Steg 3: Uppskattning (15 minuter). Teamet uppskattar uppgiften genom Planning Poker eller T-Shirt Sizing. Om skillnaden > 2 SP — diskuterar de orsakerna och röstar igen. Regel: om uppgiften inte kan uppskattas (oklara krav, ingen design) — skickas den tillbaka till PO för omarbetning och kommer till nästa grooming med förtydliganden. Uppskatta inte uppgifter med okända faktorer — detta leder garanterat till fel i sprinten. Steg 4: Registrering av resultat (10 minuter). PO registrerar uppskattningarna i Jira/Linear, uppdaterar uppgiftsbeskrivningen och sätter prioriteringar.

Resultat av grooming: 3-7 fullt redo för Sprint Planning-uppgifter (med DoR, uppskattning, design, API). PO uppdaterar backloggen: tar bort föråldrade uppgifter, slår samman dubbletter, förtydligar prioriteringar. Viktigt: grooming avslutar inte PO:s arbete — mellan grooming-sessioner bör han förbereda nästa uppgifter. Rekommenderad takt: PO förbereder 3-4 uppgifter för grooming, teamet bearbetar dem. Om det finns mer än 50 uppgifter i backloggen — bör PO utföra prioritering (MoSCoW eller Weighted Shortest Job First) före grooming.

Hur grooming skiljer sig från Sprint Planning

Grooming — är förberedelse. Det finns inga åtaganden — uppgiften förtydligas och uppskattas bara. Sprint Planning — är ett åtagande. Teamet väljer uppgifter från de som förberetts vid grooming och åtar sig att slutföra dem i sprinten. Huvudsakliga skillnader: grooming är inte knuten till en specifik sprint (allmän backlog refinement), vid grooming finns inget Sprint Goal, grooming kan genomföras när som helst under sprinten. Sprint Planning — strikt i början av sprinten och leder alltid till Sprint Goal.

Vid grooming uppskattas uppgifter endast, men de tas inte in i sprinten. Vid Planning väljs uppgifter från den förberedda poolen. Utan grooming tar Sprint Planning 6-8 timmar (istället för 4), eftersom teamet ser uppgifterna för första gången och inte kan uppskatta dem snabbt. 80/20-regeln: 80% av uppgifterna vid Sprint Planning bör vara fullt förberedda (har genomgått grooming), 20% — kan vara nya (brådskande buggar, hotfixar). Om det vid Planning finns mer än 20% ouppskattade uppgifter — var grooming otillräcklig.

Vanliga misstag vid grooming

Misstag 1: grooming en gång i månaden. Teamet samlar på sig 3-4 sprintar av uppgifter, försöker förtydliga allt på 2 timmar. Resultat: hälften av uppgifterna förblir ouppskattade, Planning tar hela dagen. Lösning: grooming måste vara regelbunden — 1 gång per sprint, 60 minuter. Om det finns många uppgifter — lägg till en andra grooming mitt i sprinten. Bättre att grooma färre uppgifter kvalitativt än många — men ytligt. Takt: 3-5 uppgifter per grooming, varje får full diskussion och uppskattning.

Misstag 2: uppskattning utan sammanhang. PO visar uppgiften “Implementera kundvagnsskärm” utan design, utan API, utan AC. Teamet uppskattar “på ögat” — 13 SP. Vid Planning visar det sig att det egentligen är 5 SP (för skärmen är enkel). Lösning: uppgiften uppskattas inte om det inte finns design eller API. PO är skyldig att förbereda material före grooming. Regel: “Ingen mockup — ingen uppskattning”. Undantag: Spike-uppgifter — undersökning av osäkerhet, de uppskattas separat utan design (2-5 SP beroende på undersökningens komplexitet).

Misstag 3: grooming blir Planning. Teamet börjar fördela uppgifter till utförare och diskutera vem som ska göra vad. Lösning: påminna om att grooming handlar om förtydligande, inte om fördelning. Fördelning — vid Daily efter sprintstart. Grooming svarar på frågan “vad ska göras?”, Planning — “när ska det göras?”, Daily — “vem gör det?”. Att blanda dessa frågor i ett möte minskar effektiviteten för varje. Scrum Master bör stoppa Planning-diskussionen och rikta fokus mot förtydligande av uppgiften.

Misstag 4: ignorering av Tech Debt. Vid grooming diskuteras endast nya funktioner, tekniska uppgifter ignoreras. Efter 3-4 sprintar ackumuleras teknisk skuld till en kritisk nivå. Lösning: vid varje grooming måste minst 1 Tech-uppgift genomgå uppskattning. Proportion: på 3 funktioner → 1 teknisk uppgift. Använd måttet Tech Debt Ratio: förhållandet mellan Tech-uppgifter och Feature-uppgifter i sprinten. Målvärde: 0.25-0.3 (25-30% av tiden på teknisk skuld). Om ratio är under 0.2 — kommer utvecklingshastigheten att minska i efterföljande sprintar.