Sprintplanlegging: Hva er det, og hvordan gjør man det?
Er du klar til å få mest mulig ut av sprintplanleggingen? Som agil prosjektleder eller produkteier er det opp til deg å sørge for at alle er samkjørte og at dere leverer resultater.
Så det er på tide å rydde opp i kaoset og få full kontroll på suksesskriteriene med denne ultimate veiledningen, som vil gjøre sprintplanleggingen din så organisert at du kan gi Marie Kondo konkurranse! Selv om et godt agilt prosjektstyringsverktøy kan være svært nyttig, finnes det heller ingenting som kan måle seg med menneskesinn og teamarbeid når det gjelder å lage en vellykket sprintplan.
Derfor skal jeg i denne omfattende veiledningen gå gjennom alt du trenger for å planlegge vellykkede sprinter – inkludert å sette et sprintmål, hvordan du forbereder deg til sprintplanleggingsmøtet, setter sammen møteagendaen og andre beste praksiser.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Hva er sprintplanlegging?
Sprintplanlegging er den innledende fasen i en agil utviklingssyklus og er en del av agil prosjektplanlegging. I dette møtet samles hele teamet til et sprintplanleggingsmøte for å definere arbeidet som skal utføres i en sprint, og lage en plan for å nå disse målene.
Sprintplanleggingsmøtet er vanligvis strukturert i to deler:
- «Hvorfor» og «hva» for sprinten: Teamet setter sprintmålet og blir enige om hva som skal gjøres. Det velger elementene fra produktkøen som skal behandles i sprinten. Prosjektplanleggingsverktøy med funksjoner for sprintplanlegging kan bidra til å organisere og prioritere elementer i produktkøen, slik at teamet holder fokus og er samkjørt om sprintmålene.
- «Hvordan» sprinten skal gjennomføres: Utviklerne diskuterer detaljene i de enkelte elementene fra produktkøen og deler dem opp i oppgaver. Hver oppgave tilpasses slik at den kan fullføres på én arbeidsdag eller mindre, og kan spores med et oppgavestyringsverktøy.
Avhengig av sprintens lengde varer planleggingsmøtet mellom to og åtte timer. Det bør tidsavgrenses i henhold til sprintens lengde (f.eks. maksimalt fire timers møte for en to ukers sprint).
Ved slutten av møtet bør sprintmålet og oppgavene som skal fullføres være fastsatt, og sprinten bør offisielt ha startet.
Hvorfor er sprintplanlegging viktig?
Sprintplanlegging er viktig fordi den etablerer en tydelig retning for teamets kommende sprint. Når den gjennomføres på en god måte, kan en sprintplanleggingsøkt:
- Etablere en tydelig, felles forståelse av prosjektets mål og formål
- Gjøre det mulig for teamene å prioritere og velge arbeidselementer for den kommende sprinten
- Fremme effektiv ressursallokering og tidsstyring
- Fremme samarbeid og kommunikasjon mellom teammedlemmene
Alt i alt er sprintplanlegging et viktig forberedende trinn i agil prosjektstyring. Den legger grunnlaget for en velorganisert og effektiv sprint, slik at teamene kan levere resultater av høy kvalitet innenfor den fastsatte tidsrammen.
Hvem deltar i sprintplanleggingen?
Kort sagt bør hele Scrum-teamet delta i sprintplanleggingen og delta på Scrum-arrangementet i begynnelsen av hver sprint. Disse teammedlemmene kan omfatte:
- Produkteieren: Gir innsikt i produktvisjonen, tydeliggjør kravene og prioriterer elementene fra produktkøen som skal inkluderes i sprinten.
- Scrum-masteren (kalt agil veileder i noen team og må ikke forveksles med en prosjektleder): Leder møtet, sørger for at den avtalte arbeidsflyten følges, og at deltakerne utvikler en felles forståelse av sprintmålet.
- Utviklerne: Bidrar med teknisk ekspertise og innsikt i gjennomførbarheten og innsatsen som kreves for å implementere brukerhistorier.
Noen ganger vil interessenter fra virksomheten også delta som rådgivere dersom de kan bidra med et viktig perspektiv eller nyttig kunnskap.
Slik forbereder du deg til sprintplanleggingsmøtet
For å få et effektivt møte bør produkteieren (PO) forberede følgende:
- Funnene fra den siste sprintgjennomgangen og sprintretrospektivet, samt tilbakemeldinger fra interessenter i backloggen.
- En oversikt over arbeidet som allerede er gjort.
I tillegg bør produkteieren forberede seg til et sprintplanleggingsmøte ved å gjennomføre flere prosesser, som jeg vil diskutere mer detaljert nedenfor. Disse inkluderer:
- Forhåndsdefinere sprintmålet med tilknyttede prioriterte backlog-elementer som kan diskuteres under planleggingen.
- Regelmessig forbedre backloggen, der de viktigste oppføringene oppdateres.
- Vurdere teamets hastighet og kapasitet for neste sprint.
Jeg vil beskrive disse tre aktivitetene i detalj nedenfor.
Hva er et sprintmål?
Under sprintplanleggingen blir produkteieren og utviklerne enige om et spesifikt sprintmål. Sprintmålet beskriver resultatet eller utfallet av den nye sprinten som teamet arbeider med. Det er en kortsiktig milepæl på veien mot det endelige produktet.
Målet er at det ved slutten av sprinten finnes et leverbart produktinkrement som allerede gir kundene en fordel.
Hva er en backlog?
Hvis du er produkteier, er sjansen stor for at du har hørt begrepet "backlog" flere ganger enn du kan telle. Men hva er det egentlig? På et grunnleggende nivå vet vi selvfølgelig alle hva det er – en liste over oppgaver eller funksjonalitet som må fullføres.
Men når det kommer til detaljer som forskjellen mellom en produktbacklogg og en sprintbacklogg, blir ting raskt kompliserte, så spenn deg fast og la oss dykke ned i det!
Produktbacklogg kontra sprintbacklogg
Scrumteamet samler alle brukerhistorier, epos og oppgaver som kreves for å lage det endelige produktet, i produktbackloggen. Produkteieren prioriterer deretter backlog-elementene slik at historiene med høyest verdi for kundene ligger øverst. Denne prioriteringen gjøres vanligvis sammen med utviklerne.
Produktbackloggen er imidlertid ikke en endelig liste som opprettes i begynnelsen av utviklingsfasen og deretter behandles. Nei, denne listen vokser og endres hele tiden.
Den vokser både gjennom kunnskapen som opparbeides i sprintene, og gjennom nye krav som oppstår underveis. Derfor er det nødvendig å forbedre backloggen regelmessig for å håndtere disse endringene.
La oss for eksempel si at produktbackloggen består av alle historiene som er nødvendige for å lage et nettsted, for eksempel hjemmesiden, kontaktskjemaet og produktsidene. Hvis markedsføringsteamet plutselig innser at de absolutt trenger en bloggseksjon på nettstedet, kan denne inkluderes i backloggen og prioriteres deretter.
Sammenlignet med produktbackloggen inneholder sprintbackloggen bare backlog-elementene som er valgt for den aktuelle sprinten, samt et overordnet sprintmål.
Slik anslår du elementer i backloggen
Hvor mye arbeid kan et team fullføre i løpet av sprinten? Dette er et av de sentrale spørsmålene utviklerne må besvare under sprintplanleggingen. For å kunne lage en prognose gjør de et estimat.
Dette kan være ganske utfordrende, siden teamet håndterer mange ukjente variabler. Men over tid, og med erfaringen fra fullførte sprinter, blir teamet stadig bedre til å lage estimater.
Slik beregner du teamets hastighet og kapasitet
Før estimeringen kan begynne, er det viktig å kjenne den gjennomsnittlige ytelsen fra de tidligere sprintene (hastigheten) og teamets tilgjengelige kapasitet for den kommende sprinten, som kan være redusert på grunn av opplæring, ferie osv.
Basert på disse vurderingene anslår teamet arbeidsmengden (hastigheten) det kan håndtere i sprinten, vurderer deretter de enkelte backlog-elementene og velger hvor mange av dem som skal inkluderes i sprintbackloggen.
La oss si at den gjennomsnittlige hastigheten var 40 historiepoeng i løpet av de siste sprintene (2-ukers syklus), og at det ikke forventes noen betydelig reduksjon i teammedlemmenes tilgjengelighet. Da vil teamet planlegge ut fra å opprettholde den samme hastigheten (dvs. at backlog-elementene som velges for den kommende sprinten, vil fylle rundt 40 historiepoeng).
Selv om gjennomsnittlig tid for å fullføre en oppgave vanligvis kan spores med et godt tidsregistreringsverktøy, kan du også bruke flere andre estimeringsmetoder til å utføre smidig kapasitetsplanlegging og fastslå teamets gjennomstrømming.
Estimeringsmetoder: En kort oversikt
Ønsker du å forstå estimeringskunsten bedre? Med ulike metoder og variabler i spill kan det ofte føles som et skremmende tema – men ikke bekymre deg! Når du forstår det grunnleggende, vil du være godt rustet til å estimere backloggen din på kort tid.
Historiepoeng
Mange smidige team som arbeider med langsiktige prosjekter, estimerer gjennomstrømmingen sin i historiepoeng.
Historiepoeng er en abstrakt enhet som teamet bruker til å estimere innsatsen som kreves for å fullføre et element i backloggen. Dette er basert på tre kriterier:
- Arbeidsmengde: Hvor mange deloppgaver må fullføres for å fullføre brukerhistorien?
- Risiko og usikkerhet: Er alle krav tydelige, eller kan det oppstå uventede forsinkelser og endringer?
- Historienes kompleksitet: Er de enkelte deloppgavene knyttet til hverandre, slik at historiens kompleksitet øker? Og finnes det avhengigheter utenfor teamet?
Fibonacci-sekvensen & primtall
Smidig planlegging ved bruk av Fibonacci-sekvensen og primtall hjelper team med å lage prognoser som ikke bare er intuitivt basert på optimisme, men som heller bygger på prinsipper for numerisk logikk.
Hvis en brukerhistorie har mange variabler og er kompleks eller omfattende, betyr det å tildele den et høyere tall på Fibonacci-skalaen at teamet er forberedt på å sette av nok ressurser og innsats til å gjennomføre den – fordi de allerede kjenner arbeidsmengden som ligger i en slik oppgave.
På den annen side får historier med færre variabler eller enklere resultater tildelt lavere tall – noe som gir bedre kontroll over budsjetteringen av tid og energi. Kort sagt tar smidig planlegging håp og drømmer bort fra møteromsbordet og erstatter dem med noen harde, håndgripelige tall!
Vær imidlertid oppmerksom på at historiepoeng ikke nødvendigvis kan sammenlignes på tvers av programvareutviklingsteam, siden hvert team estimerer omfanget litt forskjellig. Det betyr at det team A estimerer som en historie på 5 SP, kan være en historie på 8 SP for team B.
Estimering med historiepoeng egner seg også for mindre team eller prosjekter, ettersom teamet med denne metoden vurderer oppgavene basert på kompleksiteten og tiden det tar å behandle dem. Andre teknikker omfatter å estimere innsatsen basert på T-skjortestørrelser eller planleggingspoker-metoden.
T-skjortestørrelser
Å estimere backloggelementer med T-skjortestørrelser er en interessant tilnærming for å prioritere prosjektoppgaver. I stedet for å tildele et nøyaktig antall timer eller dager til en oppgave kan du tildele den én av fire størrelser (liten, middels, stor og ekstra stor), avhengig av graden av kompleksitet eller usikkerhet.
Det er en forenklet, men overraskende effektiv måte å sikre at de riktige oppgavene blir gjort til riktig tid på – enten du arbeider med små, mellomstore eller store prosjekter, trenger du bare å velge størrelsen som passer. Sørg bare for at alle som er involvert i prosjektet, er enige om hvordan hver størrelse tilsvarer et bestemt estimert innsatsnivå!
Planleggingspoker
Hvis du ser etter en smart måte å estimere backloggelementene dine på, hvorfor ikke prøve planleggingspoker?
Det er en populær teknikk som har eksistert siden 2002, da James Grenning fant på begrepet.
Tilnærmingen er enkel: Teammedlemmene oppgir estimatene sine anonymt ved å velge kort fra kortstokken for planleggingspoker, som representerer ulike estimeringer (dvs. det estimerte antallet historiepoeng for elementet).
Dette oppmuntrer alle til å uttrykke sin mening uten frykt for andres fordømmelse eller latterliggjøring. Når alle teammedlemmene har lagt inn estimatene sine og man har kommet frem til enighet, går teamet videre til neste element.
Agenda for sprintplanleggingen
Du har altså gjort alle nødvendige forberedelser, og du har endelig kommet til møtet for sprintplanlegging. Planleggingen av en Scrum-sprint følger vanligvis denne agendaen:
- Produkteieren (PO-en) presenterer sitt forhåndsdefinerte sprintmål og deler ideen sin om hvordan produktets verdi kan økes i den kommende sprinten. Det endelige sprintmålet fastsettes i fellesskap av produkteieren og utviklerne.
- PO-en navngir de (prioriterte) elementene fra produktkøen som bør implementeres for å nå målet.
- Teamet anslår arbeidsmengden for de enkelte oppføringene, hvis dette ikke allerede er gjort på forhånd (f.eks. under forbedring av produktkøen). Ved behov videreutvikler teamet enkelte oppføringer eller innhold (f.eks. akseptansekriterier med gitt–når–så).
- Teamet velger produktelementene fra produktkøen som det skal levere innen slutten av sprinten. På dette tidspunktet diskuterer produkteieren oppgavene som skal fullføres med utviklerne, basert på kundeverdi og arbeidsmengde. Er de valgte elementene tilstrekkelige for å nå sprintmålet og skape verdi for kunden? Til syvende og sist bestemmer utviklerne selv hvor mye arbeid de påtar seg i sprinten. Viktig: Dette valget er ikke en forpliktelse overfor produkteieren og interessentene, men en prognose basert på estimatet av arbeidsmengden og teamets gjennomsnittlige hastighet.
- Utviklerne samles deretter for å bryte ned de valgte elementene fra produktkøen i mindre oppgaver. Ideelt sett bør disse arbeidspakkene tilpasses slik at de kan fullføres på én dag eller mindre.
- Sprintkøen består av det omforente sprintmålet, elementene fra produktkøen som skal behandles, og planen for hvordan disse skal behandles.
- Mange team visualiserer sprintkøen og arbeidet som skal gjøres, på et Scrum-brett. Hvert team har sitt eget brett og bruker ulike kolonner for å dokumentere fremdriften i sprinten. I hovedsak bør de tre viktigste kolonnene på alle brett være følgende: «Gjøremål», «Pågår», «Ferdig».
I praksis deler mange Scrum-team sprintplanleggingen inn i to faser:
I den første delen gjennomføres de fire første punktene i agendaen som er beskrevet ovenfor. Produkteieren og teamet avklarer spørsmålene: «Hvorfor er denne sprinten verdifull?» og «Hva skal implementeres i denne sprinten?» Utviklerne gjennomfører den andre delen uten PO-en og arbeider med hvordan de skal utføre det valgte arbeidet.
Mal for agenda til sprintplanleggingsmøte
Trenger du en agendamal for sprintplanleggingsmøtene dine? Last ned vår tydelige og enkle mal for å komme raskt i gang med sprintplanleggingsmøtene dine. Du finner også en sjekkliste og en e-postmal for ekstra bekvemmelighet.
På tide å rydde opp i sprintplanleggingsmøtene dine på Marie Kondo-måten
Med denne omfattende veiledningen er du nå klar til å få mest mulig ut av sprintplanleggingsøktene dine. Hvis du hadde nytte av denne veiledningen, anbefaler vi også at du ser på veiledningen vår om møter for prosjektplanlegging.
Ved å følge trinnene som er beskrevet i dette innlegget, vil produkteiere garantert lykkes med å omdanne kaos til klarhet og hjelpe teammedlemmene med å lykkes i den neste sprinten. Les mer om Scrum-rammeverket og andre Scrum-seremonier, som daglig Scrum, her.
Hvis du vil holde deg oppdatert med flere organisatoriske tips og få innblikk i temaer knyttet til gjennomføring av effektive produktdrevne prosjekter, inviterer jeg deg til å abonnere på nyhetsbrevet til The Digital Project Manager. Derfra vil vi fortsette å dele innsikt fra bransjeeksperter og prosjektledere over hele verden.
