Sprintplanering Excel - Gratis Mall

1. Steg 1 — Öppna fliken Översikt och fyll i sprintnamn, sprintperiod, produktägare, scrum master, teamets kapacitet i timmar och sprintmål.
2. Steg 2 — Kontrollera teamtabellen i Översikt. Lägg in rätt roll och timkostnad för varje person som ska kunna väljas som ansvarig.
3. Steg 3 — Gå till Sprintbacklogg och registrera ett unikt ID, ärende och beskrivning för varje arbetsuppgift. Använd en rad per backloggpost.
4. Steg 4 — Välj ansvarig, stad, prioritet och status från rullistorna. Ange story points, planerade timmar, nedlagda timmar, startdatum, slutdatum och eventuell risk eller kommentar.
5. Steg 5 — Kontrollera de beräknade kolumnerna Timkostnad, Beräknad kostnad, Procent klart och Sprintmål uppfyllt. Dessa fylls i automatiskt utifrån dina registreringar.
6. Steg 6 — Använd Översikt vid sprintplanering, dagliga avstämningar och retrospektiv. Följ särskilt blockerade uppgifter och skillnaden mellan teamets kapacitet och planerade timmar.

En sprintplanering fungerar bäst när backloggen används som arbetsyta före, under och efter sprinten. En produktägare formulerar ärendet och sprintmålet, medan scrum mastern använder status, risk/kommentar och blockerade uppgifter för att styra uppföljningen. Utvecklare, UX-designers och testare fyller i uppskattningar och uppdaterar nedlagda timmar.

Fliken Sprintbacklogg (bild 1) är byggd för ett konkret arbetsflöde. Varje rad innehåller ett ID, ett ärende och en beskrivning. Därefter anger du ansvarig, stad, prioritet, status, story points, planerade timmar och nedlagda timmar. Startdatum och slutdatum gör det möjligt att se när en uppgift faktiskt ska genomföras, medan risk/kommentar fångar beroenden som annars lätt försvinner i mötesanteckningar.

Från refinement till sprintstart

Under refinement kan teamet dela upp ett större ärende i mindre leveranser och sätta story points. Ett exempel från mallen är en BankID-inloggning på 8 story points och 32 planerade timmar. En dashboard för kundöversikt är satt till 13 story points och 56 timmar, vilket visar varför teamet bör jämföra omfattning med kapacitet innan sprinten låses.

Översikten (bild 2) passar för planeringsmötet. Där anges bland annat kapacitet på 480 timmar, samtidigt som arbetsbladet räknar summerade timmar, story points och kostnad. För ett team med 480 tillgängliga timmar är 420 planerade timmar ett mer hållbart utgångsläge än 500, eftersom 80 timmar då finns kvar för support, möten och oförutsedda hinder.

Daglig uppföljning och avslut

På daily scrum bör du filtrera Sprintbacklogg på Pågår och Blockerad. Vid sprintavslut kontrollerar produktägaren att klara uppgifter verkligen motsvarar sprintmålet, medan scrum mastern använder Översikt och diagrammen som underlag för retrospektiven.

Mallen kopplar samman inmatade backloggdata med beräknade resultat. Timkostnad i kolumn M hämtas med LETARAD från området A15:C22 på Översikt. Om ansvarig är Anna och hennes timkostnad är 850 kr blir 32 planerade timmar en beräknad kostnad på 27 200 kr.

Kolumn N räknar kostnaden som planerade timmar multiplicerat med timkostnaden. Det är ett planeringsvärde, inte en löneberäkning eller ett bokföringsunderlag. Om en uppgift ändras från 32 till 40 timmar ökar kostnaden i exemplet från 27 200 kr till 34 000 kr.

Formlerna bakom statusen

Kolumn O översätter status till en enkel framdriftsindikator: Klar blir 100 %, Pågår blir 50 % och Ej påbörjad eller Blockerad blir 0 %. Kolumn Q visar Ja endast när status är Klar och procenten är 100 %. Det är en avsiktligt strikt definition, eftersom en uppgift inte ska räknas som uppfylld enbart för att någon har arbetat på den.

Översikten använder funktioner som ANTAL.OM, SUMMA, MEDEL och SUMMA.OM. Den räknar exempelvis antal uppgifter med ID som börjar på SB-, summerar story points och beräknar kostnad per ansvarig. Statusdiagrammet bygger på fyra statusvärden, prioriteringsdiagrammet på Hög, Medel och Låg, och kostnadsdiagrammet summerar beräknad kostnad för ansvariga i teamtabellen.

Kapacitet är inte samma sak som arbetstid

Om ett team har 480 timmar i kapacitet bör du inte automatiskt planera in 480 timmar. Med 8 personer som vardera har 60 tillgängliga timmar blir kapaciteten 480 timmar, men 10 procent för möten och support motsvarar 48 timmar. En plan på 432 timmar är därför ett bättre tekniskt riktmärke än full beläggning.

Datavalideringen begränsar story points till heltal mellan 0 och 100, timmar till 0–1 000 och datum till perioden 2000-01-01–2100-12-31. Svenska Excel-användare kan översätta funktionerna till exempelvis LETARAD, ANTAL.OM, SUMMA.OM och MEDEL med semikolon som argumentavskiljare.

Det vanligaste praktiska felet är att samma arbete registreras som flera uppgifter med olika ID. Då räknar Översikt varje rad som en separat uppgift, vilket kan göra att klarandelen och antalet story points blir missvisande. Använd därför ett unikt ID per leverans, till exempel SB-001, SB-002 och SB-003.

Felaktiga uppskattningar

En uppgift på 13 story points och 56 planerade timmar bör granskas om den bara har ett slutdatum två dagar efter startdatum. Story points är inte timmar, men en stor skillnad mellan storlek och tidsplan är en tydlig signal om att ärendet behöver delas eller uppskattas på nytt.

Ett annat fel är att ange nedlagda timmar som planerade timmar. Om 24 timmar planeras och 40 timmar redan har lagts ned ska kolumn I fortfarande visa 24 och kolumn J 40. Annars försvinner avvikelsen som teamet behöver diskutera.

Status som används för optimistiskt

Pågår ger automatiskt 50 % i kolumn O, oavsett om arbetet i verkligheten är 10 % eller 90 % klart. Ändra därför inte status till Klar förrän acceptanskriterierna är uppfyllda. En uppgift som är tekniskt färdig men väntar på produktägarens godkännande bör inte markeras som Klar.

Blockerad ska användas aktivt, inte som en tillfällig ersättning för Pågår. Om tre av tio uppgifter är blockerade visar Översikt 30 % blockerade uppgifter, vilket är ett konkret underlag för att ta bort beroenden. Skriv orsaken i Risk/kommentar, exempelvis väntan på API-beslut eller designgodkännande.

Kostnader som inte går att lita på

Om en ansvarig saknas i teamtabellen blir timkostnaden tom och beräknad kostnad kan inte räknas fram. Kontrollera därför teamtabellen innan planeringsmötet. En uppgift på 56 timmar med Eriks timkostnad 950 kr ska ge 53 200 kr; visar översikten inget belopp saknas normalt kopplingen mellan ansvarig och teamtabell.

Kontrollera även att timmar inte skrivs som text och att datum anges som ÅÅÅÅ-MM-DD. Felaktig datainmatning kan göra filtrering och summeringar svårare att tolka även när formeln i sig är korrekt.

Börja med att anpassa teamtabellen på Översikt. Byt ut exempelnamnen Anna, Erik och Maria mot de personer som faktiskt deltar i sprinten och uppdatera roller och timkostnader. Om Anna har 850 kr per timme och arbetar 32 planerade timmar ska kostnaden visas som 27 200 kr, medan 40 timmar ger 34 000 kr.

Skapa en tydligare arbetsrutin

• Använd ID-formatet SB-001 och fortsätt löpande, så att uppgifter kan hänvisas till utan långa rubriker.
• Skriv beskrivningen som ett konkret leveransresultat, till exempel export av filtrerad kunddata till Excel.
• Använd Risk/kommentar för beslut, beroenden och väntetider, inte för långa mötesanteckningar.
• Bestäm en fast tid varje dag då status och nedlagda timmar uppdateras.

Vill du följa kapacitet mer noggrant kan du jämföra teamets kapacitet i Översikt med summan av planerade timmar i Sprintbacklogg. Om kapaciteten är 480 timmar och planeringen uppgår till 450 timmar finns 30 timmar kvar som buffert. En buffert på 6,25 % är ofta mer användbar än att planera exakt 480 timmar.

Bygg vidare utan att förstöra formler

Lägg nya arbetsuppgifter på lediga rader inom det förberedda området rad 2–101. Behåll kolumnerna M, N, O och Q som beräknade kolumner och ändra i stället inmatningsfält som ärende, ansvarig, status, timmar och kommentarer.

Använd Instruktioner (bild 3) för att introducera nya teammedlemmar. Fliken beskriver arbetsgången i sex steg, rullistorna och kostnadsformatet. Diagrammen kan användas i sprint review och retrospektiv, men mallen innehåller inga kopplingar till Jira, Azure DevOps eller andra externa system.