Scrum Product Owner

En scrum product owner ejer prioriteringen. Ikke teamet, ikke processen og ikke koden — men rækkefølgen af det, der bliver bygget.

Rollen er én af tre i Scrum, sammen med udviklerne og scrum masteren. Den er defineret i Scrum Guide, som vedligeholdes af Ken Schwaber og Jeff Sutherland og udgives af Scrum.org og Scrum Alliance.

Det centrale i definitionen er, at det er én person. Ikke et udvalg. Andre kan foreslå, men kun product owneren beslutter, hvad der ligger øverst i backlogget.

I praksis er det den regel, der oftest brydes i danske virksomheder.

Typiske opgaver

• Skrive og vedligeholde produktbacklogget, altså den prioriterede liste over alt, der kan bygges
• Formulere opgaver, så udviklerne forstår dem: brugerhistorier, acceptkriterier og eksempler på hvad færdig betyder
• Prioritere ud fra værdi, risiko og afhængigheder, ofte med metoder som WSJF, MoSCoW eller simpelt værdi mod indsats
• Deltage i sprintplanlægning og svare på spørgsmål, mens teamet estimerer
• Være tilgængelig gennem hele sprintet, fordi der altid dukker uafklarede spørgsmål op
• Godkende eller afvise leverancer ved sprint review sammen med interessenterne
• Tale med brugere og kunder, så prioriteringen bygger på noget virkeligt frem for på antagelser
• Håndtere interessenter: salg, drift, ledelse og kunder, som alle mener deres ønske er vigtigst
• Følge op på, om det byggede faktisk bliver brugt, og fjerne det der ikke gør

En almindelig arbejdsdag

Dagen starter typisk med teamets daglige stand-up. Den varer et kvarter, og product owneren lytter mest.

Formiddagen går i afklaringer. En udvikler har fundet en kant i en opgave, som ingen havde tænkt på, og du skal beslutte hvad der så skal ske. Beslutningen skal komme hurtigt, ellers står nogen stille.

Midt på dagen ligger ofte interessentmøder. En afdelingschef vil have sin funktion med i næste sprint. Dit svar er som regel nej eller senere, og det skal begrundes.

Om eftermiddagen skriver du. Nye brugerhistorier, acceptkriterier og opdatering af backlogget. En del af tiden går også med at slette gamle punkter, som aldrig bliver relevante.

En gang pr. sprint er der refinement, planlægning, review og retrospektiv. I et tougers sprint er det typisk en halv til en hel dag samlet.

Det svære i jobbet

Du skal sige nej hele tiden. Til kolleger, chefer og kunder. Siger du ja til alt, bliver backlogget en ønskeliste, og teamet mister retningen.

Du skal også kunne beslutte på et ufuldstændigt grundlag. Venter du på fuld sikkerhed, står teamet stille imens.

Den almindeligste fejlkonstruktion er en product owner uden mandat. Man har titlen, men beslutningerne træffes af en styregruppe eller en direktør. Så bliver rollen til en sekretær for andres ønsker, og det er den hyppigste årsag til, at folk stopper.

Og du skal kunne nok teknik til at forstå, hvad du beder om. Du behøver ikke kunne kode, men du skal forstå, hvorfor en tilsyneladende lille ændring kan tage tre uger.

Hvem har rollen

Stillingen findes overalt, hvor der udvikles software i et team.

Brancherne er især softwarevirksomheder og SaaS, finans og pension, medicinal med digitale produkter, energi, detail og e-handel, transport og telekommunikation. It-konsulenthuse som Netcompany, KMD, Systematic, Trifork og Bluefragments leverer product ownere ind i kundeprojekter.

Den offentlige sektor er en meget stor arbejdsgiver på området. Styrelser, regioner og større kommuner har egne udviklingsteams med product ownere, ofte på borgerrettede løsninger.

En vigtig sondring: i mange virksomheder er product owner en rolle, man har oveni sit job, ikke en fuldtidsstilling. Det fungerer sjældent godt, fordi teamet så venter på svar.

Der findes ingen dansk uddannelse til product owner. Man kommer til rollen fra et fagområde eller fra it, og lærer resten undervejs.

De typiske uddannelsesveje

• Cand.it. eller cand.merc.it., 5 år
• Cand.merc. i økonomistyring, strategi eller marketing, 5 år
• Datamatiker, 2,5 år, eller professionsbachelor i softwareudvikling, hvis man kommer fra den tekniske side
• Professionsbachelor i økonomi og informationsteknologi, 3,5 år, som rammer krydsfeltet direkte
• Cand.polyt. i software eller digitalisering, 5 år
• Cand.scient.pol. eller cand.soc., hvilket er almindeligt i offentlige udviklingsteams

Adgangskravene til erhvervsakademi- og professionsbacheloruddannelserne er normalt en gymnasial eksamen eller en relevant erhvervsuddannelse. De aktuelle krav for den enkelte uddannelse fremgår af Uddannelsesguiden fra Uddannelses- og Forskningsministeriet.

Uddannelsen betyder mindre end domæneviden. Skal du være product owner på et pensionssystem, tæller det tungere, at du forstår pension, end at du har læst datalogi.

Certificeringer

Dette er et af de områder, hvor certificeringer reelt efterspørges i danske stillingsopslag, især i det offentlige.

• PSPO I fra Scrum.org, som tages som en online-eksamen uden kursuskrav. PSPO II og III findes til de mere erfarne
• CSPO fra Scrum Alliance, som kræver deltagelse i et todages kursus
• SAFe Product Owner/Product Manager, hvis virksomheden kører SAFe, hvilket mange store danske organisationer gør
• PRINCE2 Agile, som ses i offentlige udbud

En certificering gør ingen til en god product owner. Den viser, at du kender begreberne og rammerne, og den åbner døre. Det er alt.

Alternative veje ind

• Fra fagområdet. Den mest almindelige vej i Danmark. En sagsbehandler, en økonomimedarbejder eller en pensionsrådgiver bliver product owner på det system, hun selv har brugt i årevis
• Fra udvikling eller test. Man kender teamet og teknikken, men skal lære prioritering og interessenthåndtering
• Fra forretningsanalyse. Kravarbejde er allerede kernen, og skridtet er kort
• Fra projektledelse. Man kan styring og interessenter, men skal aflære trangen til at planlægge alt på forhånd
• Fra support eller kundeservice. Man ved præcis, hvad brugerne render ind i, hvilket er undervurderet

Karriereveje videre

Den typiske rute er senior product owner og derefter product manager, hvor ansvaret flytter sig fra hvad teamet bygger til hvorfor produktet findes. Derfra kan vejen gå til head of product eller chief product officer.

Andre veje er programledelse, hvis man arbejder i store systemprogrammer, eller en rolle som agil coach eller scrum master, hvis man er mere optaget af processen end af produktet. Nogle går tilbage til deres eget fagområde med en digital lederrolle.

Realistisk tidshorisont

Du kan køre et sprint efter få uger, hvis du kender domænet. Der går et til to år, før du kan prioritere en hel backlog med modstridende interessenter og stå fast på det.

Hvis du skal hyre

Afklar mandatet, før du slår op. Må personen beslutte selv, eller skal alt godkendes? Uden mandat får du ikke en product owner, men en referent.

Bed kandidaten fortælle om noget, hun har sagt nej til, og hvordan det gik. Bed hende beskrive en konkret brugerhistorie, hun har skrevet, med acceptkriterier. Spørg til noget, teamet byggede, som viste sig ikke at blive brugt — svaret afslører, om hun følger op. Og spørg til domæneviden: en product owner uden indsigt i faget bliver et postkontor mellem forretning og udviklere.

Backlog og planlægning

Jira er langt det mest udbredte værktøj i danske udviklingsteams. Alternativerne er Azure DevOps, som er almindeligt i Microsoft-tunge organisationer, samt Linear, Shortcut, Trello og monday.com i mindre teams.

Her lever backlogget: epics, brugerhistorier, opgaver og fejl. Product owneren opretter, prioriterer og lukker punkter dagligt. Sprintboardet er teamets fælles billede af, hvad der er i gang.

Dokumentation

Confluence bruges sammen med Jira til produktbeskrivelser, beslutninger og mødereferater. Alternativer er Notion, SharePoint eller en wiki i Azure DevOps. Nogle skriver acceptkriterier i Gherkin-format med given, when og then, især hvor der køres automatiseret test.

Design og brugerinddragelse

Figma bruges til at se løsningen, før den bygges, og product owneren deltager typisk i gennemgangene. Brugertest arrangeres ofte sammen med en UX-designer. Feedback fra kunder samles i Productboard, Canny eller bare i et regneark.

Data

Brugsdata er det, der gør prioritering til andet end mavefornemmelse. De hyppigste værktøjer er Google Analytics eller GA4, Amplitude, Mixpanel, Hotjar og Power BI. SQL er en stor fordel, fordi du så selv kan tjekke, om en funktion bliver brugt.

Test og drift

Du skal kunne læse en fejlrapport og forstå, hvor alvorlig den er. Fejl kommer typisk ind via Jira Service Management, ServiceNow eller supportsystemet. Overvågning i Grafana, Datadog eller Application Insights bruges til at se, om noget er gået i stykker efter en release.

Møder

Retrospektiver og planlægning faciliteres ofte i Miro eller Mural, især for teams med hjemmearbejde. Estimering foregår i Planning Poker-værktøjer eller direkte i Jira.

Krav og fortrolighed

Bygges der løsninger, der behandler personoplysninger, skal databeskyttelse tænkes ind fra begyndelsen. EU's databeskyttelsesforordning, GDPR, kræver privacy by design, og Datatilsynet lægger vægt på dataminimering og sletning. Offentlige løsninger skal desuden leve op til webtilgængelighedsloven og WCAG-standarden, hvilket Digitaliseringsstyrelsen fører tilsyn med. Begge dele er product ownerens ansvar at få i backlogget — ikke noget der kan tilføjes bagefter.