Hvis jeg bare måtte nevne én nøkkelbegivenhet i hele Scrum-rammeverket som stadig blir undervurdert, ville det vært sprintplanlegging.
Det skal være et samarbeidsmøte hvor Scrum-teamet forbereder sitt arbeid til neste sprint. Det bør ikke ta mer enn to timer per toukers sprint. I stedet for alt dette ender det ofte med usikkerhet og mye arbeid som gjenstår for å avklare hva omfanget av neste sprint skal være.
Innholdsfortegnelse
Sprintplanlegging og dens betydning i smidig utvikling
Dette er arrangementet der teamet vurderer produktreserven. Det er en liste over epos og funksjoner som inneholder krav og akseptkriterier for produktet. Teamet velger de høyest prioriterte elementene fra etterslepet å jobbe med i neste sprint. Deretter blir elementene delt opp i enkeltstående oppgaver som utgjør det komplette arbeidet utviklingsteamet må utføre for å fullføre og levere sprinten.
Betydningen av sprintplanlegging er å etablere denne felles forståelsen av arbeidet som teamet forplikter seg til å levere. Det bestemmer også hva som er de mest verdifulle varene for øyeblikket, så sprintplanlegging maksimerer verdien for kunden. Til slutt skaper denne prosessen implisitt en følelse av eierskap og engasjement for hele teamet. Naturligvis øker dette produktiviteten til teamet.
Komponenter i sprintplanlegging
Det er noen grunnleggende deler som hvert sprintplanleggingsmøte i Scrum bør inneholde.
#1. Produkt Backlog
Før sprintplanleggingen bør produkteieren ha finpusset produktreserven for å sikre at den er oppdatert og prioritert. Under sprintplanleggingsmøtet gjennomgår teamet produktreserven. De diskuterer elementene som er på toppen av etterslepet.
#2. Sprintmål
Teamet definerer et sprintmål og visjonen som produkteieren har for sprinten. Dette er en oppsummering som beskriver hvordan lagets inkrementelle verdi vil se ut etter slutten av denne spurten. Sprintmålet bør være spesifikt, målbart og oppnåelig innenfor perioden av en sprint.
#3. Sprint innhold
Elementene fra backloggen som er valgt for neste sprint, utgjør sprintinnholdet. Teamet skal være trygg på at alt som er inne i innholdsteamet kan leveres fullt ut innenfor sprintperioden. For det må teamet beregne innsatsen for hvert av elementene fra sprintinnholdet.
Deler av Sprintplanleggingsmøtet
For å sette komponentene i perspektiv, danner de alle spesifikke handlinger du forventer skal skje i sprintplanleggingen.
Teamet finpusser etterslepet. Det er en diskusjon mellom Produkteieren (som eieren av innholdet) og utviklingsteamet, som er her for å forstå formålet og akseptkriteriene til elementene. Et element (eller en historie) foredles bare hvis hele teamet er enige om at historien er klar for utviklingsaktiviteter.
Hva du skal oppnå
Det endelige målet for et sprintplanleggingsmøte er å definere et sprintmål og bli enige om sprintinnhold som teamet skal jobbe med i den kommende sprinten.
For at det skal skje, må teamet ha nok klare til å ta historier og funksjoner som kan danne dette innholdet i backlog. En oppgave for Product Owner er å prioritere historiene før møtet slik at utviklingsteamet vet hvilke temaer som har høyest forretningsprioritet. En oppgave for utviklingsteamet er å gjøre seg kjent med disse elementene og anstrenge disse elementene i etterslepet.
Hvordan oppnå
Sprintplanleggingsmøte handler om kommunikasjon og samarbeid mellom Product Owner og utviklingsteamet. De jobber sammen for å få klarhet i omfanget av de høyest prioriterte elementene i etterslepet. Når teamet har raffinert nok toppprioriterte historier, vil produkteieren definere hva som er målet for neste sprint. Dette er en melding til alle eksterne interessenter som forteller hva neste sprint hovedsakelig vil handle om. Eller hva vil være hovedintensjonen og formålet med leveransen for denne sprinten?
Utviklingsteamet vil deretter beregne lagkapasitet for sprinten og fylle ut sprintinnholdet med de høyest prioriterte elementene som utgjør sprintmålet.
Etter hvert kan teamet legge til sprintinnholdet andre historier som ikke stemmer overens med sprintmålet. Selv om bare for å fylle opp den gjenværende ledige sprintkapasiteten. Likevel er sprintmålet noe laget kommuniserer som den viktigste inkrementelle verdien av sprinten.
Avhengig av nivået på forhåndsforberedelsen, kan sprintplanleggingsmøtet enten være en ganske lang diskusjon eller en veldig rask beslutningsperiode. I tilfelle laget allerede er erfarent, kan det allerede være nok godt forberedte historier i etterslepet for de neste to eller tre spurtene.
I slike tilfeller handler møtet egentlig bare om å definere vårmålet og plukke opp relevante poster fra etterslepet. Hvis disse historiene ikke er klare før sprintplanleggingsmøtet, må de fullføres på det møtet. Da krever dette interaktiv diskusjon mellom produkteieren og utviklingsteamet.
Roller og ansvar
Det er tre hovedroller som deltar på hvert sprintplanleggingsmøte: Produkteieren (PO), utviklingsteamet og Scrum Master (SM). Hver rolle har spesifikke ansvarsområder under sprintplanleggingsmøtet.
PO er ansvarlig for selve innholdet i etterslepet og for å sikre at produktrestansen er oppdatert og prioritert. PO eier til syvende og sist sprintplanleggingsmøtet og er ansvarlig for å legge til rette for diskusjonen rundt produktbacklog-elementene, og hjelper teamet med å forstå forretningsverdien til hver vare. PO kommuniserer også og samarbeider med utviklingsteamet for å bestemme sprintmålet. Og sikrer at sprintinnholdet stemmer overens med den generelle produktvisjonen.
Utviklingsteamet er ansvarlig for å velge produktbacklog-elementene som de vil jobbe med under sprinten og effektivt lage sprintinnholdet. Bare utviklingsteamet kan forplikte seg til de spesifikke elementene fra backlog. Utviklingsteamet er ansvarlig for å estimere innsatsen som kreves for hver oppgave og tildele dem til teammedlemmer.
SM er ansvarlig for å orkestrere sprintseremoniene og legge til rette for sprintplanleggingsmøtet, og sørge for at alt holder seg på rett spor. SM hjelper også teamet med å forstå hensikten med sprintplanleggingsmøtet og viktigheten av å skape en felles forståelse av arbeidet. Det handler også om å lære teamet de beste smidige praksisene underveis.
Alle (i omfanget av sine roller) samarbeider for å etablere en felles avtale om arbeidet for neste sprint og hvordan teamet skal levere det. Teammedlemmene er ansvarlige for å stille spørsmål, dele sine perspektiver og jobbe sammen for å lage sprintinnhold. Det endelige målet er å levere leveringer av høy kvalitet innenfor sprintens periode.
Hvordan forberede seg til sprintplanlegging
Det meste av forberedelsesarbeidet ligger hos Produkteieren. PO er den som er ansvarlig for etterslepberedskap og forberedelse. Det er ikke slik at PO må definere alle historiene og funksjonene i etterslepet, men ansvaret og eierskapet ligger hos PO. Det er også opp til PO å eie dette møtet og drive innholdsdiskusjonen.
Deretter skal utviklingsteamet studere etterslepet i god tid før sprintplanleggingen, slik at selve møtet kan gå knirkefritt. Hvis folk leser elementene for første gang på sprintplanleggingen, vil det selvsagt ta mye mer tid å få klarhet i elementene.
Hvert punkt som skal diskuteres i sprintplanleggingen skal også ha akseptkriterier allerede definert. Dette er igjen en oppgave for PO å sikre. Selve vareinnholdet og akseptkriteriene er de to viktigste inputene for sprintplanleggingen. Hvis de mangler eller bare er veldig vinglete (vanligvis en historie som bare inneholder overskriften og ikke noe innhold i det hele tatt), kan ikke teamet forberede seg på dem i utgangspunktet.
Sette målet på riktig måte
Den mest effektive prosessen med å sette opp mål og mål under sprintplanleggingsmøtet er å følge noe som du kan kalle en iterativ tilnærming. Her er noen trinn som forteller mer om hvordan du definerer effektive mål og mål:
Bare ikke glem at hvert sprintmål skal gjenspeile faktisk sprintkapasitet (hvor mye laget vil være tilgjengelig i neste sprint), og innsatsberegning for hvert element som utgjør sprintinnholdet må eksistere.
Beste praksis for sprintplanlegging
Hvis du ønsker å lykkes i dette møtet, må du alltid forberede deg på forhånd. Denne meldingen kommer hovedsakelig til produkteierne, men dette er ikke for å ekskludere utviklingsteamet også. Alle bør gjennomgå den nåværende tilstanden til produktreserven i god tid.
Med det trenger du ikke spørre folket om dette virkelig er første gang de ser denne historien. I et ideelt tilfelle vil du gjerne ha noen av de mest enkle historiene allerede anslått. Selv om det ikke er en realistisk forventning mesteparten av tiden.
SM bør gjøre alt som er mulig for å holde møtet fokusert på den faktiske agendaen og temaene som skal dekkes. Dette er ekstremt vanskelig, spesielt hvis laget ikke er modent ennå. Det er en sterk tendens til å diskutere alt og hver detalj og stille spørsmål ved selv de grunnleggende fakta som man ellers ville betraktet som atomære. Kutt dette og be teamet om å gå videre.
Samarbeid og kommunikasjon er det som driver alle vellykkede scrum-team. Alle har mulighet til å stille spørsmål når som helst, så bruk det til gode. Det er ingenting verre enn sprintplanlegging, hvor du bare kan høre produkteieren (eller enda verre, bare Scrum Master).
Sprintplanleggingsmøtet skal ha konkrete tidsbegrensninger. Ikke forleng dette avtalte tidsrommet. Og vær så snill, ikke lag en annen (spesiell) andre del av sprintplanleggingen fordi den som nettopp skjedde ikke var nok. Lær av det og gjør det (mye) bedre neste gang.
En absolutt ikke
Ikke forlat sprintplanleggingen uten at elementene er delt inn i historier. Det er en vanlig feil å tro at dette er noe laget kan gjøre enda senere. Først av alt har det en direkte innvirkning på nøyaktigheten av estimatene for sprintinnholdet.
Dessuten flytter du effektivt noen av aktivitetene til sprintplanleggingen inn i en tid som er for selve utviklingen av gjenstandene. Du forkorter utviklingstiden for sprintinnhold og gir den ikke engang en tidsbegrensning.
Det er aldri en god idé å øke, forlenge eller flere sprintseremonier. Til tross for det er dette akkurat det som skjer mesteparten av tiden. Ikke følg mengden her.
La oss kort se på noen planleggingsverktøy du kan bruke mens du utfører sprintplanleggingsøktene. Det kan hjelpe deg med å oppnå høyere effektivitet, selv om jeg kan hevde at den mest effektive måten fortsatt 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 å hjelpe til med å planlegge og administrere sprints mer effektivt. Verktøyet er designet for å automatisere manuelle oppgaver involvert i sprintplanlegging, for eksempel å estimere innsats og tildele oppgaver til teammedlemmer. Tara.ai gir også sanntidsinnsikt og analyser for teamene for å spore deres fremgang og områder for forbedring.
Åpenbart er en av de viktigste forskjellene mellom Tara.ai og andre lignende verktøy bruken av AI. Tara.ai bruker maskinlæringsalgoritmer for å analysere data fra tidligere spurter og gi anbefalinger for å forstå hvordan man kan forbedre prosessen for de neste spurtene. Verktøyet kan også bidra til å lage mer nøyaktige og detaljerte brukerhistorier.
Et annet spesifikt aspekt er hvor tilpassbar Tara.ai er. Verktøyet kan konfigureres for å matche de spesifikke behovene til hvert team. Den kan til og med integreres med andre verktøy og plattformer ganske enkelt.
#2. Klikk opp
Kilde: clickup.com
Klikk opp er et sprintplanleggingsverktøy som gir deg en omfattende plattform for prosjektledelse, inkludert sprintplanlegging. Verktøyet er svært funksjonsrikt og støtter en rekke mulige integrasjoner.
Hovedforskjellen mellom ClickUp og andre verktøy er fleksibiliteten. Du kan tilpasse ClickUp kanskje enda mer og konstruere mange tilpassede arbeidsflyter og prosesser for å oppfylle dine krav til prosjektet. Verktøyet tilbyr en rekke maler og forhåndsbygde arbeidsflyter som du kan tilpasse ytterligere.
En annen forskjell er at ClickUp støtter en rekke integrasjoner med andre verktøy og plattformer. Verktøyet kan integreres med populære verktøy som f.eks Slakk, Trelloog Google Diskslik at team kan strømlinjeforme arbeidsflyten og samarbeide sammen.
ClickUp gir teamet en god mengde funksjoner for å hjelpe med å planlegge og administrere spurtene deres, som oppgaveadministrasjon, tidsregistrering og rapportering. Verktøyet støtter sanntidsinnsikt og analyser for å analysere teamets fremgang over tid og med det identifisere områder for forbedring.
#3. Lucidspark
Kilde: lucidspark.com
Lucidspark er et sprintplanleggingsverktøy som gir en virtuell tavle for team til å samarbeide og planlegge spurtene sine. Verktøyet har som mål å hjelpe team med å brainstorme nye ideer og sette et system inn i informasjonskaos. Den planlegger bare teamets arbeid mer effektivt.
En av de viktigste forskjellene som skiller Lucidspark er fokuset på visuelt samarbeid. Verktøyet gir en rekke maler og visuelle elementer som teamene kan bruke til å organisere ideene sine og planlegge spurtene sine. Den virtuelle tavlen gjør det mulig for teamene å samarbeide i sanntid, noe som i stor grad eliminerer ulempene ved ulike steder.
En annen egenskap ved Lucidspark er dens brede integrasjonsmulighet med andre verktøy og plattformer. På samme måte som ClilckUp, integreres den enkelt med verktøy som Slack, Google Drive og Trello.
Lucidspark støtter mange funksjoner for lag å planlegge og administrere spurtene sine. For eksempel oppgavestyring, tidsregistrering og rapportering. Og nok en gang gir Lucidspart også sanntidsinnsikt og analyser for å hjelpe teamene med å spore fremgangen deres og identifisere områder for forbedring.
#4. Wrike
Kilde: wrike.com
Wrike er et sprintplanleggingsverktøy som gir 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 samarbeidsfunksjoner, inkludert sanntidsredigering, kommentarer og oppgavetildeling. Verktøyet støtter også ut av esken mange kommunikasjonsfunksjoner, som chat, e-post og videokonferanser.
Wrike kan integreres med lignende verktøy som de som er nevnt før (Slack, Google Drive), men også med Microsoft Teamsnoe som kan være en fordel for enkelte bedrifter.
Wrike støtter også funksjoner for å hjelpe lag med å planlegge og administrere spurtene sine. Disse inkluderer oppgavestyring, tidsregistrering og rapportering.
#5. Zoho
Kilde: zoho.com
Zoho Sprint er et annet planleggingsverktøy som gir en omfattende plattform for smidig prosjektledelse.
En av nøkkelegenskapene til Zoho Sprint er fokuset på enkelhet. Verktøyet gir deg et enkelt og intuitivt grensesnitt som er enkelt å bruke. Dette gjelder selv for team som er nye innen Agile prosjektledelse. Verktøyet gir også en god mengde maler og forhåndsbygde arbeidsflyter som kan tilpasses for å oppfylle kravene til prosjektet ditt.
Som med andre verktøy fra listen, tilbyr Zoho Sprint også oppgavestyring, tidssporing og rapportering. Og også sanntidsinnsikt og analyser for teamene for å måle og identifisere områder for forbedring.
Konklusjon
Å gjennomføre sprintplanleggingen på riktig måte er en prosess som du bare kan mestre med erfaring. Selv om du lærer deg alle teoriene som er tilgjengelige, vil folks aller første grunnleggende instinkt når de er i et møte være å drive bort fra fokusområdet.
Et team fullt av teknisk erfaring er også et team fullt av komplikasjoner. Teamets modenhet, i dette tilfellet, måler forståelsen av tankesettet i stedet for erfaringsnivået til de tekniske ferdighetene de har. Det er derfor det er så viktig å vite hvor du kan forbedre og (enda viktigere) hvordan du kan forbedre.
Deretter kan du sjekke ut usunne prosesser som kan ødelegge spurten din.