Många företag och organisationer kämpar med att få till en bra dialog kring prioriteringar och kravdetaljer med beställare och verksamhet.
I större organisationer som inte i mål med att forma om sig för att stötta agila projekten i sina leveranser blir ofta just produktägaren (och verksamhets- experter) en flaskhals.
För några dagar sedan fick jag detta mail:
.
Hej Jimmy!
Tack för en bra blogg. Såg att du gärna mottog frågor om Scrum så tänkte maila om det jag funderar på.
Vår nuvarande Product Owner har inte varit närvarande och han har haft massa sidouppgifter. Tanken är nu att han ska blir Chief Product Owner med underordnade Product Owner för olka delar av vårt system då det är stort och komplext. Till detta så kommer det även för stories att finnas kravägare som man får för sig att varje team ska vända sig till med frågor. Mina funderingar om detta:
1. Om vi har en huvud produktägare, visst borde denna kallas Chief Product Owner istället för Product Manager?
2. De under ordnade produktägarna bord väl kallas Product Owner of Function A och inte Functional managers vilket ger associationer till något helt annat?
3. Ska verkligen kravägare vara den som teamet pratar med? Bör det inte vara produkägarna som teamet kommunicerar med i det? För som jag förstått det så ska produkägaren/ägarna har väldigt god koll på alla stories?
Mvh #####
Hej #####,
Roligt att du tycker om bloggen! Och tack också för din fråga.
Såhär tänker jag…
.
1. Om vi har en huvud produktägare, visst borde denna kallas Chief Product Owner istället för Product Manager?
Jag håller med om att Chief Product Owner är ett lämpligare namn. Det är vedertaget och har en betydelse inom den agila litteraturen och inom Scrum-metodiken. Viktigare än namnet är dock såklart rollens syfte och förväntad roll i projektet.
.
2. De under ordnade produktägarna bord väl kallas Product Owner of Function A och inte Functional managers vilket ger associationer till något helt annat?
Personligen gillar jag beteckningen ”Area Product Owner <Functional Area>” fast ”Product Owner of Function A” tror jag säkert fungerar lika bra. Dock blir jag lite fundersam över begreppet ”Function” här. Det låter som om risken finns att det blir ett för smalt område, men å andra sidan har jag ju ingen insikt i ert system.
Men jag håller med om att ”manager” ger helt fel associationer. Att vara produktägare handlar inte om ”management”, det handlar om att representera kunden och förmedla en vision, roadmap och kunskap kring features och funktioner till teamet. Produktägaren är en del av teamet, inte en av teamets managers.
Vidare, om man har en hierarki med produktägare (vilket man bör ha när man skalar upp Scrum till flera team) så är det viktigt att definiera och farankra vilket mandat produktägarna har över sin egen produktbacklogg. På sätt och vis utgör produktägarna ett virtuellt team vars förmåga och vilja att samarbeta kring roadmaps och prioriteringar är centralt. Varje team ska inkludera en produktägare som bistår teamet i diskussioner kring vision, roadmaps och prioriteringar – på daglig basis, aktivt och proaktivt. Vidare ska varje team ha sin egen produktbacklogg. Om flera team delar samma produktbacklogg anser jag att man hamnar man i flera trassliga situationer.
I detta virtuella ”Product Owner Team” är det viktigt att diskutera och enas kring vilket mandat Chief Product Owner förväntas besitta? Vilket mandat och ansvar blir över till Area Product Owner?
.
3. Ska verkligen kravägare vara den som teamet pratar med? Bör det inte vara produkägarna som teamet kommunicerar med i det?
Jag kan ju bara gissa vad ”kravägare” betyder hos er.
Alt 1. Kravägaren är personen som beställt en viss funktion av produktägaren (alt. produktägarteamet). Personen har ingen detaljerad åsikt kring exakt hur funktionen ska implementeras men är väldigt mån om att få funktionen levererad.
Alt 2. Kravägaren har på uppdrag av produktägaren ett ansvar att konkretisera funktionen och har mandat att utforma detaljerna i kravet.
Alt 3. ?
Oavsett vad – om det finns någon utanför teamet som har speciell verksamhetsexpertis eller kunskap om vad användarna vill ha som inte produktägaren besitter ska denna person vara en del av teamet, åtminstone under den period man jobbar med det kravet.
Han eller hon ska stötta produktägaren i att konkretisera kravet till PBI:er (Product Backlog Items/User Stories), splittra upp det i flera beståndsdelar och sedan förklara affärsvärdet för var och en av de mindre delarna så att produktägaren kan göra en bra prioritering av produktbackloggen.
Vidare, när det är dags att förvandla kravet till värdefull fungerande mjukvara ska personen göras till en teammedlem som på deltar på det dagliga mötet, designworkshoppar och diskussioner samt kan vara med och diskutera de sista detaljerna med testare och utvecklare när kravet faktiskt överstätts till fungerande kod. Teamet (med eller utan ”kravställare”) har inte mandat att utöka/minska omfattningen av funktionen utan att rådgöra med produktägaren – teamets uppgift är att förvandla tydligt definierade och avgränsade krav (User Stories) till fungerande värdefull mjukvara efter produktägarens prioriteringar.
Har inte produktägaren tid till detta (dvs formedla kunskap eller ha åsikt kring kravdetaljerna), eller inte sitter inne med den verksamhetsexpertis eller kundkunskap som behövs, ja då ska teamet utökas med en person som faktiskt har det. Återigen, titeln är inte det viktiga – fokusera på syftet och samarbetsformen.
.
Jag hoppas dessa kommentarer och reflektioner ger dig något av värde och kan hjälpa er i ert arbete och diskussioner.
Jag kan också rekommendera en bra bok som bland annat adresserar dessa frågeställningar och utmaningarna när man skalar upp till flera Scrum team som tillsammans bygger en produkt/ett system.
Den heter ”Scaling Lean & Agile Development – Thinking and Organizational Tools for Large-Scale Scrum” och är skriven av Craig Larman och Bas Vodde.
Får vi valuta för pengarna? Är förväntad Return Of Investment (ROI) högre än sprintens kostnad? När ROI/Sprint sjunker under en viss gräns är det kanske dags att vara nöjd och avrunda projektet… eller se över Produktbackloggen, dvs. ta ett kreativt omtag och klura ut nya funktioner som kan skapa högre affärsvärde än de som ligger i produktbackloggen just nu.
Project Success Sliders är ett enkelt men kraftfullt sätt för stakeholders och produktägaren att förmedla sina förväntningar till teamet. I projektets inledande fas defineras ett antal ”sliders” som var och en ger uttryck för hur projektets framgång kommer betygsättas och bedömas.
Det vanligaste källan till dysfunktionella Scrum projekt är problem kring och rörande Produktägaren. 
På 2010 Shanghai Scrum Gathering höll Monica Yap från SolutionsIQ ett seminarie som vackert listade upp sex stycken Produktägar anti-patterns. Gillar själva uttrycket ant-pattern, på sätt och vis en vacker omskrivning för ”gör inte så här”.
Likaså tar Roman Pichler upp sex stycken vanliga bekymmer rörande produktägaren i sin nya bok ”Agile Product Management With Scrum – Creating Products That Customers Love”. Vissa snarlika, andra nya:
Fram tills i tisdags betraktade jag prototyping endast som ett verktyg för teamet och produktägaren för att flytta en funktioner och features från ”Anarchy” or ”Complex” space ner mot ”Complicated” eller ”Simple” space.
Dras dit team med en person som fått rollen som produktägare och som envisas med att sätta ”Måste”-prioritering på allt? Eller hör du kanske själv till skaran beställare som blir frustrerad när teamet ber dig prioritera ”User Stories” och som inte förstår dig när du försöker förklara för dem att ”alla dom här funktionerna är oerhört viktiga”? 
Jag har prioriterat råden efter den ordning jag tycker man ska följa dem 😉 Vidare, när jag skriver ”Story” i texten nedan syftar jag till User Story/Feature/Funktion.
Teamet hinner bara bygga och leverera ett begränsat antal färdiga funktioner/features per sprint. Att designa, utveckla och testa av funktioner och features tar tid. Hur mycket du som produktägaren än vill så kan inte teamet leverera hela produktbackloggen på en sprint. Att sätta Måste-prio på allt hjälper vare sig teamet eller dig. Det skapar snarare enbart frustration.
För varje råd du följer ovan desto bättre förutsättningar och möjligheter får teamet att lyckas med sin leverans under pågående sprint. Det de bygger blir rätt, behöver inte göras om och håller hög kvalitet. Du ger dem också möjlighet att hålla samma (och förutsägbara) tempo, effektivitet och kvalitet varje sprint.
Om du fick samla nio valfria polare, skulle ni också kunna bygga ett hus på en helg?
En PMI certifierad project manager ställer sig frågan ”Can a ScrumMaster be a project manager — are the positions one in the same?” i en nyligen publicerad artikel. Vidare hävdar hon att ”The project manager is the overarching manager and person accountable at the project level, while the ScrumMaster is the one responsible for the product development.”
Precis som utlovat kommer här min åsikt om vad ”Definition of DONE” bör innehålla. Oavsett innehåll är det viktigt att alla i projektet, dvs. Teamet, Scrum Mastern och Produktägaren, alla är överens om vad den definerar – och vad den utelämnar.
Collaborated & Designed
Sedan kan det vara så att alla kriterier inte är applicerbara eller meningsfull för allt som teamet åtar sig under en sprint. Det kan också självklart vara så att man för vissa typer av User Stories lägger till ytterligare kriterier. Men lägger man till för mycket bör det diskuteras ifall något annat kanske ska tas bort. För många och för höga kriterier kan resultera i överprestation som inte är efterfrågad, a.k.a Waste.
Jimmy Janlén "Den Scrummande Konsulten" 