Workshop för PO-rollen

Igår hade vi en heldag med alla som arbetar i rollen som PO. PO är vår benämning på stora delar av den gamla projektledarens roll, han eller hon som ansvarar för att vi bygger rätt saker till kunden. Product Owner är den officiella termen som Scrum använder men det går även bra med Produktägare, projektägare eller likande. Vi nöjer oss primärt med PO.

Vi inledde med att placera in rollen och dess ansvar i vår verklighet. Vad finns för förväntningar och vilka krav har vi på denna roll? Vi enades om dessa punkter som en första iteration av dessa delar.

  • PO är kundens förlängda arm
  • Tar reda på och samlar in krav samt förmedlar dessa till teamet
  • Prioriterar backlog
  • Rapportering av status till kund
  • Ambassadörer hos kund (säljare)
  • Förbereder backlog
  • Äger backlog
  • KOMMUNIKATION (mellan team, användare, kund, ledning osv)
  • Godkänner och är mottagare av produktinkrementet eller produkten, teamets leveranspunkt
  • Fakturering
  • Projektekonomiskt ansvarig, att vi håller ramarna i projektavtalet
Vi pratade vidare om dessa viktiga möten som måste genomföras och där PO:n spelar en huvudroll. Utan denna är mötet ogenomförbart.

Backlog Grooming eller även kallat Backlog Refinement meeting är det tillfälle då PO kan ta hjälp av teamet att förbereda och sköta sin backlog. Det är mycket viktig att göra dessa regelbundet och normalt bör man hålla ett sådan möte per vecka, en timme långt. Under detta möte tittar man gemensam på nya stories, delar stora stories eller klargör så att man kan estimera stories. Teamat för mötet varierar under projektets livslängd men det måste genomföras för att hålla backlog i bra skick.

Nedan är en bild på hur detta kan se ut men här har man valt ett möte i två timmar, jag föredrar två möten i en timme.


Alla är överens om att PO:n måste vara väl förberedd till Spintplaneringen och ha en plan klar att presentera för teamet. Det som vi har saknat i de sprintplaneringar som hittills genomfört är överblicken över hela projektet. Att göra en snabb genomgång av hela projektet, vision med projektet och hur långt har vi kommit nu är nödvändigt för att inte tappa helheten. Att även löpande uppdatera teamet statusen som mer formellt rapporteras genom den veckovisa projektrapportering till ledningen är viktigt.


Efter detta ägnande vi resten av dagen till att slipa på vår förmåga att skriva User Stories och lade mycket fokus på vad en bra story kräver:
  • Fristående - inga beroenden av andra stories
  • Förhandlingsbar - ska inte vara skriven i sten, måste gå att hitta olika lösningar för att uppnå resultatet
  • Värdefull, för kund eller användare
  • Estimerbar - lagom i storlek och så tydlig att det går att estimera insatsen som krävs för att omsätta storyn till fungerande kod.
  • Liten - lagom storlek på en story är att den tar en fjärdedels sprint, i vårt fall 2-3 dagar.
  • Testbar - ett absolut nödvändigt krav är att storyn går att testa, hur ska vi annars veta att vi är klara?
Dessa krav brukar på engelska sammanfattas som INVEST - Independent, Negotiable, Valuable, Estimatable, Small, Testable

Skapar man User Stories som följer dessa riktlinjer har man kommit långt så vi övande oss i detta och lyckades öka vår skicklighet högst påtagligt. Bra investerad dag och mycket nyttigt att få en samsyn kring rollen och våra förväntningar på den.