Om jeg skulle fremheve én enkelt, men likevel undervurdert, hendelse i hele Scrum-rammeverket, ville det vært sprintplanleggingen.
Det skal være et kollaborativt møte der Scrum-teamet forbereder sine oppgaver for den kommende sprinten. Ideelt sett bør det ikke overstige to timer for hver to-ukers sprint. Likevel, i praksis, oppstår ofte usikkerhet og en betydelig mengde arbeid gjenstår for å definere omfanget av den kommende sprinten.
Sprintplanlegging og dens betydning i smidig utvikling
I dette møtet analyserer teamet produktets «backlog». Dette er en oversikt over «epics» og funksjoner som spesifiserer krav og akseptkriterier for produktet. Teamet velger de høyest prioriterte elementene fra backlogen som skal arbeides med i den kommende sprinten. Disse elementene blir deretter brutt ned i individuelle oppgaver som utviklingsteamet må fullføre for å levere en fullført sprint.
Sprintplanlegging er essensielt for å etablere en felles forståelse av arbeidet teamet forplikter seg til. Det avgjør også hva som er de mest verdifulle oppgavene for øyeblikket, noe som sikrer at verdien for kunden maksimeres. I tillegg skaper denne prosessen en følelse av eierskap og engasjement i hele teamet, noe som naturligvis øker teamets produktivitet.
Komponenter i sprintplanlegging
Det finnes noen essensielle elementer som hvert sprintplanleggingsmøte i Scrum bør inkludere.
#1. Produkt Backlog
Før sprintplanleggingen bør produkteieren ha finjustert produktbacklogen for å sikre at den er oppdatert og prioritert. Under sprintplanleggingsmøtet gjennomgår teamet produktbacklogen og diskuterer de elementene som ligger øverst på listen.
#2. Sprintmål
Teamet definerer et sprintmål og den visjonen produkteieren har for sprinten. Dette er en oppsummering som beskriver hvordan teamets inkrementelle verdi vil se ut etter at sprinten er fullført. Sprintmålet bør være spesifikt, målbart og oppnåelig innenfor tidsrammen for en sprint.
#3. Sprintinnhold
De elementene fra backlogen som er valgt for den kommende sprinten, utgjør sprintinnholdet. Teamet må være sikre på at alt i innholdet kan leveres fullt ut i løpet av sprintperioden. For å sikre dette, må teamet beregne innsatsen som kreves for hvert element i sprintinnholdet.
Deler av sprintplanleggingsmøtet
For å sette komponentene i perspektiv, utgjør de alle spesifikke handlinger som forventes å skje under sprintplanleggingen.
Teamet finjusterer backlogen i en diskusjon mellom produkteieren (som eier innholdet) og utviklingsteamet. De diskuterer formålet og akseptkriteriene for de ulike elementene. Et element (eller en historie) anses bare som ferdig finjustert når hele teamet er enig i at det er klart for utviklingsarbeid.
Hva man skal oppnå
Det overordnede målet med et sprintplanleggingsmøte er å definere et sprintmål og bli enige om sprintinnholdet som teamet skal jobbe med i den kommende sprinten.
For at dette skal skje, må teamet ha et tilstrekkelig antall ferdigstilte historier og funksjoner klare i backlogen som kan danne dette innholdet. En av produkteierens oppgaver er å prioritere historiene før møtet, slik at utviklingsteamet er klar over hvilke temaer som har høyest forretningsprioritet. Det er utviklingsteamets ansvar å sette seg inn i disse elementene og estimere dem i backlogen.
Hvordan oppnå dette
Sprintplanleggingsmøtet handler om kommunikasjon og samarbeid mellom produkteieren og utviklingsteamet. De jobber sammen for å skape klarhet i omfanget av de høyest prioriterte elementene i backlogen. Når teamet har finjustert nok av de mest prioriterte historiene, vil produkteieren definere hva som er målet for den kommende sprinten. Dette er en beskjed til alle eksterne interessenter som kommuniserer hva den kommende sprinten hovedsakelig vil dreie seg om – eller hva som vil være det primære formålet med leveransen for denne sprinten.
Utviklingsteamet beregner deretter teamets kapasitet for sprinten og fyller ut sprintinnholdet med de høyest prioriterte elementene som er i tråd med sprintmålet.
Etter hvert kan teamet legge til ytterligere historier i sprintinnholdet, selv om de ikke samsvarer direkte med sprintmålet, for å fylle opp den gjenværende kapasiteten. Uansett kommuniseres sprintmålet som den viktigste inkrementelle verdien av sprinten.
Avhengig av nivået på forberedelse, kan sprintplanleggingsmøtet enten være en langvarig diskusjon eller en rask beslutningsprosess. Hvis teamet er erfarent, kan det allerede være et tilstrekkelig antall godt forberedte historier i backlogen for de neste to eller tre sprintene.
I slike tilfeller handler møtet i hovedsak om å definere sprintmålet og velge relevante oppgaver fra backlogen. Hvis disse historiene ikke er klare før sprintplanleggingsmøtet, må de ferdigstilles under møtet, noe som krever interaktiv diskusjon mellom produkteieren og utviklingsteamet.
Roller og ansvar
Det er tre hovedroller som deltar i hvert sprintplanleggingsmøte: produkteieren (PO), utviklingsteamet og Scrum Master (SM). Hver rolle har sine spesifikke ansvarsområder under sprintplanleggingsmøtet.
PO er ansvarlig for selve innholdet i backlogen og for å sikre at produktbacklogen er oppdatert og prioritert. PO leder sprintplanleggingsmøtet og er ansvarlig for å fasilitere diskusjonen om produktbacklog-elementene, og hjelper teamet med å forstå forretningsverdien av hvert element. PO kommuniserer og samarbeider også med utviklingsteamet for å bestemme sprintmålet og sikrer at sprintinnholdet stemmer overens med den overordnede produktvisjonen.
Utviklingsteamet er ansvarlig for å velge de produktbacklog-elementene de vil jobbe med i løpet av sprinten, og for å skape et fullstendig sprintinnhold. Bare utviklingsteamet kan forplikte seg til spesifikke elementer fra backlogen. Utviklingsteamet er også ansvarlig for å estimere innsatsen som kreves for hver oppgave og delegere dem til teammedlemmer.
SM er ansvarlig for å organisere sprintseremonier og fasilitere sprintplanleggingsmøtet, og sørge for at alt holder seg på rett spor. SM hjelper teamet med å forstå formålet med sprintplanleggingsmøtet og viktigheten av å skape en felles forståelse av arbeidet. I tillegg er det SMs rolle å lære teamet beste smidige praksis underveis.
Alle samarbeider (innenfor sine roller) for å skape en felles enighet om arbeidet for den kommende sprinten, og hvordan teamet skal levere det. Teammedlemmene har ansvar for å stille spørsmål, dele sine perspektiver og jobbe sammen for å utvikle et sprintinnhold. Det endelige målet er å levere produkter av høy kvalitet innenfor sprintperioden.
Hvordan forberede seg til sprintplanlegging
Mesteparten av forberedelsesarbeidet faller på produkteieren. PO er ansvarlig for å klargjøre og forberede backlogen. Dette betyr ikke at PO må definere alle historier og funksjoner i backlogen, men at ansvaret og eierskapet ligger hos PO. Det er også POs ansvar å lede møtet og styre innholdsdiskusjonen.
Deretter bør utviklingsteamet studere backlogen god tid før sprintplanleggingen slik at selve møtet kan gjennomføres effektivt. Hvis elementene leses for første gang under sprintplanleggingen, vil det naturligvis ta lengre tid å få klarhet i dem.
Hvert punkt som skal diskuteres under sprintplanleggingen bør også ha akseptkriterier definert på forhånd. Dette er igjen POs ansvar. Selve vareinnholdet og akseptkriteriene er de to viktigste innsatsfaktorene for sprintplanleggingen. Hvis disse mangler eller er dårlig definert (som en historie som kun inneholder overskriften og ikke noe annet innhold), kan ikke teamet forberede seg på disse.
Sette målet på riktig måte
Den mest effektive måten å definere mål og oppgaver under sprintplanleggingsmøtet er å følge en iterativ tilnærming. Her er noen steg som forklarer hvordan man setter effektive mål og oppgaver:
- Gå gjennom produktbacklogen før planleggingen. Dette sikrer at du vet hva som skal diskuteres, og unngår å kaste bort tid under møtet.
- Definer sprintmålet sammen når mulige historier for den kommende sprinten er klare for oppstart.
- Velg backlog-elementer for å understøtte det nylig avtalte sprintmålet. Sørg for at alle elementene er oppnåelige i løpet av sprinten.
- Finjuster sprintmålet ved behov når sprintinnholdet er fylt med elementer fra backlogen. Juster det slik at det sikrer riktig og tydelig kommunikasjon av sprintens fremgang til alle utenfor teamet.
- Gå gjennom og revider sprintmålene, selv under selve sprinten, spesielt hvis det oppstår uforutsette komplikasjoner. I slike tilfeller er det nødvendig å omdefinere sprintmålet, og jo før det gjøres, desto bedre er det for alle.
Husk at hvert sprintmål skal reflektere teamets faktiske kapasitet (hvor mye teamet vil være tilgjengelig i løpet av den kommende sprinten), og at innsatsberegningen for hvert element i sprintinnholdet må være tilgjengelig.
Beste praksis for sprintplanlegging
For å lykkes med dette møtet, er det nødvendig å forberede seg på forhånd. Denne meldingen er hovedsakelig rettet mot produkteierne, men den ekskluderer ikke utviklingsteamet. Alle bør gå gjennom den nåværende statusen for produktbacklogen i god tid.
Dette betyr at man ikke skal spørre folk om det er første gang de ser en historie. Ideelt sett bør noen av de enkleste historiene allerede være estimert, selv om dette ikke alltid er realistisk.
SM bør gjøre alt som er mulig for å holde møtet fokusert på den fastsatte agendaen og temaene som skal behandles. Dette er spesielt vanskelig hvis teamet ikke er modent ennå. Det er en sterk tendens til å diskutere alt i detalj, og stille spørsmål om selv de mest elementære fakta. Unngå dette og be teamet om å gå videre.
Samarbeid og kommunikasjon driver alle suksessfulle Scrum-team. Alle har muligheten til å stille spørsmål når som helst, så bruk denne muligheten. Det finnes ikke noe verre enn en sprintplanlegging der man bare hører produkteieren (eller enda verre, bare Scrum Master).
Sprintplanleggingsmøtet skal ha en fast tidsramme, og denne bør ikke overskrides. Unngå å arrangere en andre del av sprintplanleggingen bare fordi den første ikke var tilstrekkelig. Lær av erfaringen og gjør det bedre neste gang.
En absolutt «ikke»
Ikke forlat sprintplanleggingen uten at elementene er delt opp i historier. Det er en vanlig feil å anta at dette er noe teamet kan gjøre senere. Dette påvirker nøyaktigheten av estimatene for sprintinnholdet.
I tillegg flytter du effektivt noen av aktivitetene fra sprintplanleggingen inn i den tiden som er beregnet til utvikling av elementene. Dette fører til at utviklingstiden forkortes og får ingen tidsramme.
Det er aldri en god idé å øke, forlenge eller ha flere sprintseremonier. Til tross for dette er det dette som skjer mesteparten av tiden. Ikke følg denne trenden.
La oss kort se på noen planleggingsverktøy som kan brukes under sprintplanleggingsøktene. De kan bidra til økt effektivitet, selv om jeg argumenterer for at den mest effektive måten er å ha et modent team uten ekstra verktøy.
#1. Tara
Kilde: tara.ai
Tara.ai er et sprintplanleggingsverktøy som bruker kunstig intelligens (AI) for å planlegge og administrere sprinter mer effektivt. Verktøyet er designet for å automatisere manuelle oppgaver i sprintplanlegging, som for eksempel å estimere innsats og tildele oppgaver til teammedlemmer. Tara.ai gir også sanntidsinnsikt og analyser slik at teamet kan spore sin fremgang og identifisere områder for forbedring.
En viktig forskjell mellom Tara.ai og andre lignende verktøy er bruken av AI. Tara.ai benytter maskinlæringsalgoritmer for å analysere data fra tidligere sprinter og komme med anbefalinger for å forbedre prosessen i de neste sprintene. Verktøyet kan også bidra til å lage mer nøyaktige og detaljerte brukerhistorier.
En annen fordel med Tara.ai er hvor tilpasningsdyktig verktøyet er. Det kan konfigureres for å imøtekomme de spesifikke behovene til hvert team, og kan enkelt integreres med andre verktøy og plattformer.
#2. ClickUp
Kilde: clickup.com
ClickUp er et sprintplanleggingsverktøy som tilbyr en omfattende plattform for prosjektledelse, inkludert sprintplanlegging. Verktøyet er svært funksjonsrikt og støtter et bredt spekter av integrasjoner.
Hovedforskjellen mellom ClickUp og andre verktøy er fleksibiliteten. ClickUp kan tilpasses i stor grad, og man kan bygge mange tilpassede arbeidsflyter og prosesser for å imøtekomme ulike prosjektkrav. Verktøyet tilbyr en rekke maler og forhåndsbygde arbeidsflyter som kan tilpasses ytterligere.
En annen fordel er at ClickUp støtter mange integrasjoner med andre verktøy og plattformer. Verktøyet kan integreres med populære verktøy som Slack, Trello og Google Disk, slik at teamet kan effektivisere arbeidsflyten og samarbeide på en sømløs måte.
ClickUp tilbyr også mange funksjoner som hjelper team med å planlegge og administrere sprintene, som oppgavestyring, tidsregistrering og rapportering. Verktøyet støtter sanntidsinnsikt og analyser for å spore teamets fremgang over tid og identifisere områder for forbedring.
#3. Lucidspark
Kilde: lucidspark.com
Lucidspark er et sprintplanleggingsverktøy som tilbyr en virtuell tavle for team å samarbeide og planlegge sine sprinter. Målet er å hjelpe team med å utveksle ideer og skape et system i et informasjonskaos, for å planlegge teamets arbeid mer effektivt.
En av de viktigste forskjellene med Lucidspark er fokuset på visuelt samarbeid. Verktøyet tilbyr en rekke maler og visuelle elementer som teamet kan bruke for å organisere sine ideer og planlegge sprintene. Den virtuelle tavlen gjør at teamet kan samarbeide i sanntid, noe som i stor grad eliminerer ulempene ved å være på forskjellige steder.
En annen fordel ved Lucidspark er de mange integrasjonsmulighetene med andre verktøy og plattformer. Som ClickUp, integreres det enkelt med verktøy som Slack, Google Drive og Trello.
Lucidspark støtter mange funksjoner for team å planlegge og administrere sprintene sine, som oppgavestyring, tidsregistrering og rapportering. Lucidspark gir også sanntidsinnsikt og analyser for å hjelpe teamet med å spore sin fremgang og identifisere områder for forbedring.
#4. Wrike
Kilde: wrike.com
Wrike er et sprintplanleggingsverktøy som tilbyr en omfattende plattform for prosjektledelse, inkludert sprintplanlegging.
En av de viktigste forskjellene mellom Wrike og andre lignende verktøy er fokuset på sanntidssamarbeid. Wrike har implementert en rekke funksjoner for samarbeid, inkludert sanntidsredigering, kommentarer og oppgavetildeling. Verktøyet støtter også kommunikasjonsfunksjoner som chat, e-post og videokonferanser.
Wrike kan integreres med lignende verktøy som tidligere nevnt (Slack, Google Drive), men også med Microsoft Teams, noe som kan være en fordel for enkelte bedrifter.
Wrike støtter også funksjoner som hjelper teamet med å planlegge og administrere sine sprinter, som oppgavestyring, tidsregistrering og rapportering.
#5. Zoho
Kilde: zoho.com
Zoho Sprint er et annet planleggingsverktøy som tilbyr en omfattende plattform for smidig prosjektledelse.
Et av de viktigste trekkene ved Zoho Sprint er fokus på enkelhet. Verktøyet har et enkelt og intuitivt grensesnitt som er lett å bruke, selv for team som er nybegynnere innen smidig prosjektledelse. Verktøyet tilbyr også en rekke maler og forhåndsbygde arbeidsflyter som kan tilpasses for å møte prosjektkravene.
Som med andre verktøy på listen, tilbyr Zoho Sprint også oppgavestyring, tidssporing og rapportering, samt sanntidsinnsikt og analyser for å måle fremgang og identifisere områder for forbedring.
Konklusjon
Det å gjennomføre sprintplanleggingen på riktig måte er en prosess som man bare kan mestre gjennom erfaring. Selv om man lærer seg all den tilgjengelige teorien, vil menneskers første instinkt i et møte være å avvike fra fokusområdet.
Et team med mye teknisk erfaring er også et team med mange komplikasjoner. Teamets modenhet måler forståelsen av tankesettet, snarere enn erfaringsnivået av de tekniske ferdighetene de har. Det er derfor det er så viktig å vite hva som kan forbedres, og viktigst av alt, hvordan man kan forbedre det.
Deretter kan man se på usunne prosesser som kan ødelegge sprinten.