Det er tit svært at systematisere og forklare konkret hvad en product owner laver. Jeg har forsøgt at opsummere mine erfaringer fra en bunke coaching seancer med product owners og sammenholde det med hvad teorien foreskriver.

I teorien

Den officielle definition på en product owner er dejlig løs og fri til fortolkning:

“Product Owner er ansvarlig for at maksimere værdien af produktet og arbejdet i Development
Teamet.”

Yderligere er der angivet en række opgaver som kan indgå i arbejdet

• Klart udtrykte Product Backlog items
• Ændring på rækkefølgen af Product Backlog items således, at de bedst opfylder mål og
  missioner
• Sikrer værdien af det arbejde, Development Teamet udfører
• Sikrer at Product Backloggen er synlig, transparent og klar for alle, og samtidig viser, hvad
  Scrum Teamet arbejder på som det næste; og
• Sikrer, at Development Teamet forstår Product Backlog items på det nødvendige niveau.

Det lyder alt sammen meget flot og let, men i realiteten er det en opgave der kræver meget høj disciplin og samarbejde med personer på flere planer.

I praksis

I min erfaring er product owner den person som hjælper teamet med at tage en abstrakt ide og forme den ind til en række opgaver som, i prioriteret rækkefølge, skal laves. Det matcher meget godt med teorien, så alt er godt.

Det betyder således at jeg har observeret følgende arbejdsopgaver:

• Indsamling af ideer og visionære ønsker; også kaldet epics
• Nedbrydning af epics til brugernære user stories i tæt samarbejde med development team, kunder, forretning og andre interessenter
• Udformning af accept kriterier for de enkelte user stories til afgrænsning af opgaven samt detaljering af specifikke krav
• Udformning af ready-to-sprint kriterier i samarbejde med development team til afklaring af eventuelle afhængigheder til andre opgaver
• Ved brug af relativ estimering afgrænses user stories således at de kan implementeres af development teamet i løbet af et enkelt sprint
• Definiering af minimum viable product og minimum marketable product til brug ved prioritering og release planlægning
• Afklaring af spørgsmål fra development team vedrørende user stories i forbindelse med sprint planning og generel udvikling af produktet
• Godkendelse af inkrementer leveret af development team ved udgang af sprint

Lidt definitioner

• Epics er det højeste niveau indenfor ønsker og krav i Scrum. En epic dækker en større feature og kan udmønte sig i flere user stories fordelt over mange sprints
• User story er en brugernær måde at definere krav og ønsker på. Det essentielle i en user story er at det tilvejebringer kontekst til et ønske i form af modtager, rationale samt ønske
• Accept kriterier afgrænser omfanget af en opgave og beskriver i brugernært sprog hvilke handlinger der forventes at kunne udføres efter implementering af user story – i bund og grund en måde at beskrive, fra en bruges synspunkt, hvilke tests der skal kunne udføres ved sprint demo
• Ready-to-sprint kriterier bruges til at beskrive hvilke forudsætninger der skal være tilvejebragt før en user story kan inkluderes i et sprint; altså en måde at beskrive afhængigheder til andre opgaver eller leverancer fra andre teams
• Relativ estimering er en effektiv måde at give et estimat i “træskolængder” tallet bruges både i forhold til prioritering af backlog men bestemt også til planlægning af fremtidige sprints
• Minimum viable product er et koncept der basalt set beskriver hvor lidt der er nødvendigt for at kunne afklare om ideen er gangbar eller om den skal kasseres
• Minimum marketable product er et koncept der basalt set beskriver et minimum af features der er nødvendige for at kunne lave et kundevendt release
• Inkrement er summen af software leveret fra et sprint

Opsummering

Husk at ovenstående blot er en opsummering af observerationer fra den virkelige verden. Hvordan din product owner arbejder – og om han burde følge mine instrukser kan jeg svare på i en artikel, men tag en snak med ham og få det bedste ud af situationen.

Øvrige indlæg i serien “hands-on”:

• https://qed.dk/rasmus-kaae/tag/hands-on/