En Product Owner er en essentiel del af et Scrum Team. Rollen er skabt til at maksimere værdien af det arbejde som teamet leverer. Det kan implementeres på mange måder, men hvordan sikrer man at rollen skaber mest værdi i sig selv?

Sædvanligvis er Product Owner rollen besat af enten en forretningsudvikler fra udviklingsorganisationen eller en medarbejder fra forretningen/kunden. Denne person bliver en aktiv del af hverdagen i Scrum teamet og er drivende i arbejdet med Product Backloggen: Sikrer at der kontinuert forefindes user stories klar til næste sprint, prioriterer user stories, indhenter viden fra forretningen, m.v.

I mange tilfælde deltager Product Owner på alle Scrum events – Daily Standup, Planning, Review, Retrospektiv – og er faciliterende på Refinement.

Fordelen ved ovenstående er at teamet har en “goto guy” i forbindelse med afklaring af spørgsmål angående opgaver og prioritering som konstant er til rådighed.

En af ulemperne ved denne konstellation er at der sjældent følger tilstrækkeligt mandat med rollen og der tit bruges energi på at skabe alignment omkring beslutninger udenfor teamet. I tillæg kommer Product Owner væk fra kunden/forretningen i en længere periode hvilket påvirke evnen til at træffe beslutninger med afsæt i forretningensbehov uden at være farvet af teamets omstændigheder.

Man kan med stor succes forsøge sig med en alternativ konstellation og arbejdsform. Formålet er at skabe mandat, ejerskab af produkt og kort tid fra tanke til produkt. For at opnå det indføres 3 tiltag:

1. Direkte ejerskab
2. Fjernet refinement sessioner
3. Indført Story kickoff

Direkte ejerskab

Skab direkte og øget ejerskab ved at indsætte en direktør fra forretningen/kunden som Product Owner. For ikke at skabe begrebsforvirring hos personen, rammesættes hans involvering ikke med rollen “Product Owner” da det i realiteten er ligegyldig information for ham (bemærk: Scrum . I stedet laves en grundig forventningsafstemning med direktøren i forhold til vigtigheden af hans input.  Hans hierarkiske position i organisationen gør at han har mandat til træffe beslutning om hvilken retning han ønsker at produktet skal tage samt prioritering af de ønsker der skal udvikles. Teamet mødes med ham og en gruppe af andre interessenter på Sprint Review. Her præsenteres teamets arbejde og teamets forslag til ønsker i det næste Sprint.

Fjernet refinement sessioner

Mange teams arbejder med dedikerede timeboxes til refinement af stories til kommende sprints hvor der tales om løsning, design og arkitektur. Det kan med fordel fjernes. I stedet arbejdes der med hurtig tildeling af story points og business value for at skabe fornemmelse for værdien af arbejdet og størrelse af opgave/kompleksitet.

Indført Story kickoff

For at sikre at teamet er klar over løsning, design og arkitektur anvendes en “whole team approach” ved opstart af opgaven – et såkaldt “story kickoff”. Her samles teamet og aftaler hvordan arbejdet skal forløbe sig og ”hvor lidt er nok” for at skabe fremdrift på produktet.

Hvorfor er det interessant?

Det spørgsmål vil jeg tillade mig at besvare med et retorisk mod-spørgsmål: Hvor mange Product Owners har reelt mandat til træffe beslutninger om retning for produkt?

Hvis du kan bekræfte een af følgende hypoteser – så bør du overveje din Product Owner opsætning:

• Product Owner har behov for en styregruppe til bekræftelse af prioritet
• Product Owner har ikke direkte kontakt med kunder/brugere af produktet
• Product Owner sidder dagligt med teamet, løser koordinerende og administrative opgaver
• Product Owner er udførende på backlog håndtering, skrivning af user stories, m.m.

Det kan være et radikalt skifte at gå fra en Product Owner der er tæt på Development Team til en som er tættere på beslutningerne. Prøv evt. at lave et tidsbegrænset eksperiment og evaluer internt om I får leveret mere værdi hurtigere til kunden. Hvis det er tilfældet, så ved I også hvad der skal arbejdes på fremadrettet. I kan med fordel genbesøge ovenstående liste periodisk for at se om ændringerne fungerer.