Introduktionsvideo för agila produktägare i scrum

Produktägarsidan bestämmer över kraven och acceptanskriterierna och ska samarbeta med och inte styra resten av teamet vid framtagande och implementeringen av dem, och är en av medlemmarna i teamet med specialansvar för kravframtagningen och prioriteringen av backloggen. Det är sedan utvecklingsteamet som huvudsakligen bestämmer vem som tar en viss uppgift, hur de på bästa sätt ska implementera dessa krav, testa, deploya och jobba.

Ovan video är en mycket bra introduktionsvideo för agila produktägare i scrum som på 15 minuter tar upp det viktigaste med att vara en agil produktägare så ni förstår konceptet.

När utvecklarna jobbar enligt scrum innebär det att alla som är någon sorts traditionella projektledare eller produktägare kan betraktas som agila produktägare ur scrum teamets synvinkel, för det är så de bör jobba med scrum teamet för att systemet ska fungera bra och göra det möjligt för scrum teamet att göra sitt jobb på ett bra sätt.

I en organisation där det finns många produktägare med varsin produktbacklog som anlitar samma scrum team så anlitas scrum teamet förslagsvis genom att alla produktägare som har uppgifter de behöver få genomförda inför nästa sprint går till ett gemensamt produktbacklogmöte där de tillsammans förhandlar fram vilka uppgifter som är viktigast för organisationen att få gjorda nästkommande sprint, och rangordnar dessa i en lista som i vissa organisationer kallas för gemensam produktbacklog.

Innna dess bör de i samråd med scrum teamet har groomat produktbackloggen och förfinat de user stories som ska tas med till nästa sprint så dessa är tillräckligt bra och förstådda.

Sedan har scrum teamet ett sprintplanneringsmöte vid varje sprintstart tillsammans med en eller flera produktägare om det behövs, där de utifrån den kapacitet de vet att de har och vilka uppgifter de bedömmer vara möjliga att göra den sprinten väljer ut x antal av de högst rankade från (den gemensamma) produktbackloggen.

Produktägarna som fått med en eller flera uppgifter samarbeter sedan med teamet om dessa och finns tillgänglig för teamet att kontakta för diskussioner och frågor när det behövs tills dess uppgifterna är färdiga.

Varje ny produktägare i en organisation bör informeras om hur systemet med att ta fram en produktbacklog och ev gemensam producktbacklog och scrum fungerar så dessa vet hur de ska jobba med scrum teamet, och samarbetet kan fungerar smidigt och bra.

En organisation där utvecklarna jobbar enligt scrum bör införa någon sorts introduktionsutbildning för de produktägare som aldrig jobbat enligt scrum förut, så dessa får en kickstart och inte behöver återuppfinna hjulet själva varje gång och lära sig den hårda vägen.

För fler frågor om produktägararollen och hur den skulle kunna säkerställas hos er kan ni lämpligen kontakta scrum mastern för ert scrum team.

Scrum mastern är ansvarig för att se till att scrums ritualer och procedurer följs av alla involverade parter, och att coacha folk i scrum så systemet fungerar som det ska, och även den som kan bestämma om enstaka undantag från dess regler och procedurer får göras i akuta fall.

Scrum mastern fungerar även som teamets proxy i de flesta fall så de ska få jobba ostört och produktivt, för teamet i sig är självstyrande och sin egen arbetsledare till skillnad från traditionella team, så en agil produktägare är ingen arbetsledare utan i huvudsak en kravhanterare som samarbetar med teamet.

Jag tror inte det skulle vara allt för svårt för dem som redan är traditionella projektledare att bli agila produktägare i stället, för ni jobbar fortfarande med krav och planering men på ett agilt sätt i stället.

Sen är det precis som allt annat i livet en läroprocess, en resa och ett äventyr för man blir aldrig fullärd, men agilt är ett mer dynamiskt och tillfredställande sätt att jobba på som även traditionella projektledare kommer gilla när de lärt sig the tricks of the trade och sett hur bra det kan fungera.

Utskriften av det som sägs i videon hittar ni här: Agile Product Ownership in a nutshell

Även Atlassian som gör det agila teamverktyget Jira för att skapa och hantera scrum boards för agila team har rätt bra introduktionssmaterial till agilt, och här för produktägare/”projektledare”.

Läs gärna igenom detta så ni får en grundförståelse för hur man jobbar med krav och plannering inom agilt, för skillnaden är att man gör det mer lättviktigt, övergripande på lång sikt och detaljerat på kortare sikt för att snabbt kunna anpassa sig till nya erfarenheter och verkligheten när kartan inte stämmer överrens med terrängen.

För att ta ett exempel så hade man i ett projektet för en viss typ av applikation börjat med att göra klart enklast möjliga grundversion som fick jobbet gjort.

Sen utökar man den steg för steg och gör den mer avancerad så länge tid fortfarande finns, i stället för att i sann vattenfall anda göra en big bang design och hoppas på att tiden räcker till för att få allt att fungera.

Det inte ens är säkert att big bang designen blev helt rätt då man inte har alla fakta på hand i det läget, så även om man fick allt att fungera kan man ha byggt fel sak på rätt sätt och kastat bort en massa jobb i onödan.

Inom agilt gör man klart de viktigaste featuresen först och sen utökar man steg för steg en applikation med nya features så länge tid och nya ideer fortfarande finns.

Slutresultatet blir att man får en applikation som innehåller de features kunden anser är viktigast och som fungerar precis så som kunden vill och har behov av, så man bygger rätt sak på rätt sätt och minimerar overhead och waste.

Från början har man bara en övergripande produktvision om ungefär vad man vill applikationen i fråga ska göra.

Waterfall versus agile

Agile Project Management

What is an agile product roadmap?

Product requirements documents, downsized

Agile User Stories

Product Management