Scrum-produktledning: komplett guide + exempel
Scrum är inget nytt inom produktledning. De flesta av oss använder Scrum i våra företag och försöker navigera i ramverkets roller och principer för att nå våra mål.
Tyvärr är det vanligt att företag misstolkar principerna i Scrum och använder dem felaktigt, vilket gör att användarna går miste om Scrums många fördelar.
Den här trevliga lilla guiden handlar därför om att hjälpa dig att använda det här ramverket bättre genom att förklara vad det handlar om, varför det finns olika Scrum-roller, vilket ansvar produktledningen har och hur du lyckas med tvärfunktionellt samarbete.
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
Vad är Scrum inom produktledning?
Många av oss tycker om att diskutera produktchefens roll inom ramen för Scrums processer och agil metodik (med andra ord, vad produktchefen gör i ett Scrum-team). I stället för att bara förklara det tycker jag att det är enklare att visa dig var produktchefen finns i teamets organisationsschema.
I den här guiden vill jag dock närma mig ämnet från motsatt håll och visa hur Scrum passar in i din verklighet som yrkesverksam inom produktledning och hur det kan hjälpa dig att nå dina produktmål.
Jag vill börja med att diskutera hur Scrum-ramverkets grundläggande principer påverkar effektiviteten i vårt arbete.
Den kanske enskilt mest värdefulla Scrum-principen för oss är att ständigt leverera värde till användarna. Ju snabbare människor kan lösa problem, desto bättre kommer din produkt att prestera. Dessutom får du tillgång till tidig feedback från personer som har använt funktionen i ett verkligt scenario.
Den andra fördelen med Scrum är flexibiliteten. Om marknadsläget förändras kan du snabbt anpassa dig genom att göra om din produktbacklogg helt och lämna över nya funktioner till teamet i nästa sprint (det här är något som AI i sprintplaneringen kan hjälpa till med).
Det här är två saker som är mycket svåra (eller nästan omöjliga) att göra med traditionella ramverk som vattenfallsmodellen, där allt är fastställt i omfattning och användarna får tillgång till produkten först i slutet av SDLC.
Exempel på produktframgångar tack vare integrering av Scrum
Efter att ha arbetat med Scrum-team i flera år är jag helt partisk till förmån för det här agila ramverket. Så ta inte mitt ord som lag. Låt oss i stället titta på verkliga fall där övergången till Scrum hjälpte produktteam att lyckas snabbare.
Microsoft Visual Studio: Teknikjättens främsta verktyg för kodredigering var ökänt för sina återkommande cykler av produktionskaos, med buggiga lanseringar och otroligt sällsynta utgåvor. Från det ögonblick då produktteamet började dra nytta av Scrum såg företaget en kraftig ökning av produktstabiliteten, tillsammans med mycket tätare lanseringscykler – vilket återställde dess konkurrenskraft på marknaden.
Spotify: Vår älskade musiktjänsts användning av Scrum är en av de mest kända i branschen. Spotify hade svårt att anpassa sig och skala upp tillräckligt snabbt för att lösa sina processutmaningar ... tills organisationen införde Scrum. Men det som skiljer Spotify från mängden är att de utvecklade sin egen modell för Scrum-projektledning, som byggde på en grupp självständiga agila team med tillgång till all den expertis de behövde för att snabbt experimentera och ta till sig användarfeedback.
ING: Den nederländska bankjätten var en av de tidiga finansinstitutionerna som insåg att bankväsendets framtid är digital. De insåg också att deras mycket traditionella projektledningsprocesser inte var hållbara för mjukvaruutveckling. Därför införde de snabbt lean- och Scrum-metoder och blev, föga förvånande, ledande inom internetbanktjänster.
Viktiga roller inom Scrum-baserad produktledning
Om du som produktchef beslutar att Scrum är rätt väg att gå får du här en snabb översikt över de viktigaste rollerna i det här ramverket, som hjälper dig att skilja mellan din roll som produktchef och produktägare i Scrum.
Låt mig börja med rollerna. Ett typiskt Scrum-team består av följande personer:
- Scrum master: Den här personen hjälper teamet att följa Scrums regler och optimera sina processer.
- Produktägare: Den här personen representerar verksamheten och användarna i Scrum-teamet. Produktägare ansvarar för backloggen och fastställer sprintmål och prioriteringar för användarberättelser.
- Scrum-team: Dina utvecklare, designers, kvalitetssäkrare och andra specialister som bygger produkten.
När det gäller Scrum-teamet kan du ha många andra typer av specialister där. Begreppet tvärfunktionella team innebär att teamet är självständigt när det gäller tillgång till yrkeskompetens. Om din produkt till exempel är starkt inriktad på analys kan du även ha en dataanalytiker i teamet.
Produktchef kontra produktägare: Vad är skillnaden?
Definitionen av produktägare som jag gav kanske förvirrar dig lite eftersom den låter väldigt lik det som en produktchef vanligtvis gör.
Så vad är i det här fallet skillnaden mellan produktchef och produktägare?
För att förstå skillnaden ska vi först titta på vars och ens huvudsakliga ansvarsområden.
Produktchefer
- Genomför produktutforskning och förstår kundernas behov och problem.
- Definierar produktvisionen och den riktning som teamet ska följa.
- Tar fram produktlösningar som kan tillgodose kundernas behov.
- Leder processen för att leverera produkten.
- Förbättrar produkten i små steg baserat på kundfeedback och datadrivet beslutsfattande.
- Hanterar produktvisionen och genomförandet inom hela företaget och mellan företagets olika delar.
Produktägare
- Skapar och underhåller produktbackloggen.
- Fungerar som den enda sanningskällan när det gäller strategi, design och affärslogik för Scrum-teamet.
- Prioriterar punkterna i produktbackloggen och tydliggör för teamet vad som är viktigt.
- Definierar acceptanskriterier för funktioner och godkänner sprintresultaten utifrån dessa.
- Hjälper teammedlemmarna att komma vidare genom att förtydliga krav och lösa relaterade problem.
- Deltar i Scrum-evenemang och fungerar som verksamhetens och kundernas röst i teamet.
Som vi kan se gör de flesta av oss saker som finns med på båda listorna. Det är helt normalt och vanligt eftersom många av oss fungerar som både produktchefer och produktägare samtidigt.
Den huvudsakliga skillnaden mellan de två är att produktledning är ett yrke och en uppsättning färdigheter, medan produktägarskap är en roll i Scrum-teamet.
Men vad innebär det?
Det innebär att produktägaren inte behöver vara produktchef. I en liten startup där du har en vd tillsammans med tre utvecklare tar vd:n på sig rollen som produktägare genom att förse utvecklarna med en prioriterad backlogg.
Den motsatta situationen är också möjlig. Du kan vara produktchef utan att vara produktägare. Jag är ett bra exempel på detta eftersom ett av mina tidigare team inte använde Scrum. Inget Scrum innebär ingen produktägare i teamet. Däremot följde vi principerna för Lean och agilt arbete.
För att ge dig en bättre förståelse för skillnaden mellan dessa två kommer här en jämförelse sida vid sida av vad de gör.
Men vad var egentligen poängen med att ha en särskild roll i Scrum-teamet? Kunde de inte bara samarbeta med produktchefer som inte ingår i teamet? Jag tycker verkligen om hur Teresa Torres besvarar frågan.
Den främsta anledningen till att det finns en särskild produktroll i Scrum-teamet är alltså att bidra med intern produktkunskap och expertis och ytterligare förstärka teamets tvärfunktionalitet.
Så samarbetar produktchefen med Scrum-team
Om vi antar att du har bestämt dig för att välja Scrum-vägen behöver du veta hur du ska vara medlem i teamet och hur du ska samarbeta med dina kollegor. Låt mig ge dig en kort översikt av detta för varje Scrum-evenemang och artefakt.
- Daglig Scrum (även kallade dagliga avstämningar): Det viktigaste arbetet du utför under dessa tidsbegränsade möten är att besvara de produktrelaterade frågorna från ditt utvecklingsteam och undanröja hinder.
- Planeringsmöte för sprinten: Här är det du som sätter målet för sprinten genom att tydligt definiera dina förväntningar när det gäller de funktioner du förväntar dig att leverera.
- Sprintretrospektiv: De processer du använder för att leverera prioriteringar och krav till teamet kan avgöra hur effektiva de är. Därför kan du använda det här mötet för att samla in feedback från teamet och förbättra dina processer.
- Granskning av sprinten: Här är din uppgift att godkänna sprintens färdiga funktioner och ge teamet feedback på deras arbete.
- Förfining av produkten: Du äger det här mötet och behöver använda den tid som är avsatt för dig till att diskutera prioriteringarna och detaljerna i de användarberättelser du har för teamet. Uppmuntra alltid teamet att ifrågasätta dina krav och hitta ”produktbuggar” som du har lämnat där.
- Produktbacklogg: Det är ditt ansvar att hantera produktbackloggen och hålla den ren och prioriterad, eftersom teamet kommer att bygga sin sprint utifrån den.
- Sprintbacklogg: Den här äger du inte. Din främsta samarbetsuppgift är att vägleda teamet så att de väljer rätt berättelser till sprintbackloggen för att säkerställa att de kan uppnå ditt sprintmål.
Utöver detta kommer du att utföra andra typer av produktarbete, såsom intressenthantering eller produktupptäckt. Som medlem i Scrum-teamet är din uppgift att hålla teamet medvetet om både intressenters och användares behov efter att du har klargjort dem.
Om du till exempel intervjuar en användare och upptäcker att användarupplevelsen i ditt inloggningsflöde överlag är förvirrande, är det viktigt att dela denna information med teamet för att säkerställa att de uppmärksammar den delen under efterföljande sprintar.
Bästa praxis för produktledning i Scrum
Även om produktledning verkar enkelt när man ser det genom Scrums lins (och agil utveckling i allmänhet), gör vi ofta många misstag i vårt arbete inom våra självorganiserande team.
Här är därför några bästa praxis för Scrum som kan hjälpa dig att undvika dem:
- Sätt tydliga förväntningar: Det största misstaget du kan göra är att ge teamet vaga prioriteringar och krav. Brist på tydlighet är en ledande orsak till förseningar i utvecklingen och spänningar mellan dig och teamet. Vi kommer snart att gå igenom på djupet hur du uppnår detta.
- Missbruka inte anpassningsförmågan: Det är bra att kunna ändra riktning, men du kan bara göra det i din produktbacklogg, inte i sprintbackloggen. Så snart sprinten har börjat ska du inte lägga till eller ta bort berättelser från den. Det förstör teamets planer och framsteg och leder till ofärdiga sprintar.
- Skapa en känslomässigt trygg miljö: Du är medlem i teamet, inte deras chef. Pressa därför inte teamet att ta på sig större åtaganden eller bli färdiga tidigare. Scrumguider överallt, inklusive den från Scrum.org, lägger stor vikt vid att upprätthålla sunda relationer med dina teammedlemmar, eftersom det är en av hörnstenarna i ett effektivt lagarbete.
Dessa tre bästa praxis är de viktigaste enligt min erfarenhet. Men om du vill ha fler tips om agila arbetsflöden och bästa praxis för Scrum för produktchefer bör du läsa vår separata guide om agil produktledning.
Effektiv hantering av produktbackloggen
Som jag nämnde tidigare är det en av produktchefens viktigaste uppgifter att ge teamet tydlighet. Den goda nyheten är att din produktbacklogg förmodligen är det allra bästa verktyget för att uppnå detta. Här är därför några tips om hantering av produktbackloggen som kan hjälpa dig:
Förfiningsmöten: Oavsett hur väl du skriver dina användarberättelser kommer du att lämna ”buggar” där, och du kommer att vilja att utvecklingsteamet granskar och påpekar dem för dig. Dessutom är du inte utvecklare och kan skriva krav som är svåra att implementera. Återigen kommer teamet att berätta det för dig under förfiningsprocessen.
Prioriteringstekniker: Dra nytta av de många prioriteringsramverken för att förstå vilka funktioner som är viktigare än andra. Min personliga favorit är MoSCoW på grund av dess enkelhet.
Samordning med färdplan och vision: Eposen och berättelserna i din backlogg bör representera de övergripande produktmålen och de mätvärden du vill uppnå. Se därför till att kontinuerligt granska din färdplan när du lägger till något i backloggen.
Det mest uppenbara tecknet på att en organisation saknar tydlighet är när man går runt i organisationen och frågar olika personer vad de anser vara framgångskriterierna för det som behöver levereras som nästa stora milstolpe, och man börjar höra olika berättelser.
Att samordna intressenter i Scrum
Kärnan i rollen som produktchef i Scrum är att du i grunden fungerar som länken mellan det självorganiserade teamet och omvärlden, vare sig det gäller användare, intressenter eller andra team.
Så utöver dina vanliga uppgifter inom intressenthantering som produktchef behöver du också vidarebefordra den informationen till ditt team och vice versa. Det finns också situationer när du behöver vidarebefordra information från teamet till intressenterna.
Ett bra exempel är uppkomsten av tekniska utmaningar, såsom problem med kontinuerlig integrering, som kan påverka tidsplanen eller omfattningen för en viss funktion. Detta är något du behöver diskutera med intressenterna och antingen acceptera den nya tidsplanen eller omfattningen, eller komma fram till en annan lösning (t.ex. förstärka teamet med mer expertis inom området).
Det finns också situationer när ditt team kan ha kommit på en intressant idé för en funktion eller en lösning som är värd att lägga till i färdplanen. Även här vidarebefordrar du informationen till intressenterna och beslutar om ni ska lägga till den i planen eller inte.
Betydelsen av agil färdplanering i Scrum
Även om agila färdplaner inte är en direkt del av Scrum är de ett av verktygen som gör Scrum möjligt. När allt kommer omkring, vad är poängen med iterativ planering om du använder vattenfallsramverket för din produkt i stället för en agil färdplan?
I så fall skulle det du kallar Scrums produktstrategi helt enkelt vara att dela upp en fördefinierad och fast plan enligt den klassiska SDLC-modellen i delar på två veckor (eller hur långa dina sprintar nu är). För att Scrum ska bli meningsfullt för ditt team behöver du alltså arbeta med agil och interaktiv planering och skapa en färdplan som kan förändras över tid.
För att på rätt sätt förena din agila färdplan med teamets Scrum-processer föreslår jag att du gör följande:
- Koppla färdplanens poster (vanligtvis epiker) till användarberättelser i produktbackloggen. På så sätt finns en direkt koppling mellan ditt taktiska arbete (berättelserna) och din strategi (färdplanen).
- Presentera din färdplan för Scrum-teamet. På så sätt vet de vart produkten är på väg och kan ta kommande funktioner i beaktande när de utformar klient- eller serverarkitekturen.
- Dra nytta av specialiserade verktyg som Jira, Monday.com och Clickup för att effektivisera processen för färdplanering och hantering av produktbackloggen.
När det gäller den sista punkten är dessa tre verktyg de som jag har använt i praktiken. Det finns dock många andra verktyg för produkthantering som du kan överväga att använda i stället.
More Articles
Utmaningar inom produkthantering i Scrum
Även om Scrum är ett utmärkt ramverk för att uppnå dina produktmål medför användningen av detta ramverk sina egna utmaningar, till exempel:
- Ditt team eller dina intressenter kanske inte förstår vad Scrum handlar om. Detta kan uppenbarligen leda till betydande problem med att införa Scrum, till exempel att vissa artefakter vägras användas. Jag rekommenderar att du förebygger detta genom att illustrera det önskade ”slutläget” för hur teamet och arbetsflödet kommer att se ut när ramverket är fullt implementerat.
- Människor (och du) kan bli förvirrade kring din roll i teamet och utanför teamet. Alla företag jag har arbetat för under min karriär hade sin egen uppfattning om vad en Scrum-PO gör. Det är bäst att fastställa vad rollen innebär – och inte innebär – för ditt team.
- Omfattningen av de funktioner du arbetar med tenderar att expandera utan slut. Föga förvånande gör detta det mycket lätt att hamna i situationer med ständigt växande omfattning. Scrum-team måste vara kompromisslösa när det gäller vad de åtar sig och vad de säger ”nej” till.
- Färdplanen kan lätt spåra ur. Eftersom du har ett relativt självständigt team som kan välja vad det ska arbeta med, kan det sluta med att teamet bygger sådant som inte ingår i din färdplan. Att hela tiden hålla slutmålet tydligt i fokus är avgörande för att undvika denna fallgrop.
Även om dessa utmaningar är ganska vanliga är den goda nyheten att det bara tar ett par sprintar för PM:en att förstå Scrum-processen och övervinna den stora majoriteten av dem. För dem som vill formalisera sin expertis kan det ge ledare en trovärdig fördel i att vägleda sina team genom ramverket att lära sig hur man blir Scrum Master.
Slutsats
Scrum är en av de bästa gåvorna till produktchefer. Tack vare balansen mellan att vara agil på lång sikt och strikt inom korta iterationer kan du undvika kaoset i en agil utvecklingsprocess utan ramverk, samtidigt som du behåller möjligheten att ändra produktens riktning utifrån marknadens respons.
Vi hoppas att du uppskattade vår guide. Glöm i så fall inte att prenumerera på vårt nyhetsbrev för fler resurser och guider om produktledning, samt de senaste poddarna, intervjuerna och andra insikterna från branschledare och experter.
FAQ:
Vilken roll har en produktchef i Scrum?
Produktchefer, som vanligtvis tar rollen som produktägare i Scrum-teamet, ansvarar för att ge teamet tydlighet genom att dela produktens planer och prioriteringar med dem samt de nödvändiga kraven på funktioner.
Hur skiljer sig Scrum från andra agila metoder inom produktledning?
Till skillnad från Kanban och andra agila ramverk är Scrum mer strukturerat och har tydliga regler för hur arbetet ska organiseras inom teamet med hjälp av dess händelser (dagliga avstämningar, förfiningar och så vidare) och artefakter (sprintbacklogg, produktbacklogg och så vidare).
Vilka är de vanligaste utmaningarna inom produktledning med Scrum?
Den vanligaste utmaningen är att ditt team och dina intressenter misstolkar reglerna och artefakterna i Scrum-ramverket och försöker ändra dess regler innan företaget har försökt anpassa sig till det nya ramverket.
Kan en produktchef också vara produktägare?
Ja. Produktchef är ett yrke. Produktägare är en roll i ett Scrum-team. Oftast är produktägaren i teamet en produktchef. Ibland, särskilt i små nystartade företag, kan verkställande direktörer ta rollen som produktägare i teamet.
