”The Product Owner is not an Agile Project Manager. There is some overlap between the role of Product Owner and the position of Project Manager, however, being a Product Owner is very different from being a Project Manager. ”
Product Owner vs Project Manager
Ovan artikel går på ett bra sätt igenom de viktigaste skillnaderna mellan agila produktägare och projektledare.
Även om det finns likheter finns det även skillnader mellan dem som de projektledare som vill gå över till produktägarrollen och börja jobba med agila team måsta ha koll på.
Denna video är en 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.
Utskriften av det som sägs i videon hittar ni här:
Agile Product Ownership in a nutshell
Det viktigaste ni som är traditionella projektledare måste förstå är att det inte finns några projektledare i scrum.
Det helhetsansvar en traditionell projektledare tillsammans med styrgruppen har delas i scrum upp mellan produktägaren, scrum mastern och utvecklingsteamet, där teamet som helhet har ett gemensamt ansvar, men produktägaren är huvudansvarig för att se till att produkten levererar bästa möjliga värde till kunden.
Om det behövs en övergripande projektledare för att sköta planering, koordination och budget för mer än ett scrum team/delprojekt vid väldigt stora projekt, så är denne inte heller den som har arbetsledningsansvaret över teamen utan är en av intressenterna som i första hand produktägaren kommunicerar med.
En projektledare kan gå över till rollen produktägare om denne vill eftersom den är mest lik, men måste inse att det ni då i huvudsak ansvarar för är hanteringen av backloggen, releasehantering och hantering av intressenterna.
”The key responsibility, or the purpose of the Product Owner role is to “maximize the value of the Product”. The Product Owner is one person (not a committee) responsible in the Scrum Framework for maximizing the value. The way the Product Owner maximizes value, is by continuously making choices about what to built and what not to built in the Product. In order to do so, the Product Owner is also responsible for the product vision and for managing the Product Backlog and stakeholders.”
”The Project Manager manages a project on a day-to-day basis and is the only one with this day-to-day focus on the project. As a result, this role can never be shared. The Project Manager runs the project on behalf of the Project Board within specified constraints and liaises throughout the project with the Project Board and Project Assurance.”
Product Owner vs Project Manager
En artikel som på ett överskådligt och kortfattat sätt går igenom skillnaderna och likheterna mellan agila produktägare och projektledare som ni som funderar på att byta från att vara projektledare till agila produktägare för att ni ska börja jobba med agila team kan ha nytta av att läsa.
”Say you are a product owner in the sense discussed above. Then that’ great. But to which extend to you own the product? Are you responsible for the tactical and strategic decisions, or do you focus on the tactics?”
The Agile Product Owner Responsibilities
Roman Pichler har skrivt en bra artikel om olika sorters produktägare och deras ansvar och befogenheter för scrum guiden definierar idealfallet där en produktägare äger hela produkten, medans det i verkligheten finns både stora och små produktägare som kan jobba antingen med en hel produkt, en feature eller en komponent.
Detta tar Romans artikel upp på ett bra sätt så ni förstår hur olika sorters produktägare kommer jobba i praktiken beroende på vilka förutsättningar dessa ges.
Produktägaren arbetsleder inte utvecklarna utan samarbetar med dem
Produktägare arbetsleder inte utvecklingsteamet och bestämmer vem som ska göra vad och när utan förhandlar med teamet om vad som kan göras i sprintplaneringen som görs i starten på varje sprint, där utgångsbudet är att det som är högst upp i backloggen ska tas med först om det är möjligt och redo att genomföras den sprinten, men det är ibland inte möjligt av olika skäl.
Produktägaren tar alltså fram och bestämmer över kraven genom att kommunicera med intressenterna och teamet, bestämmer deras inbördes prioritetsordning i form av en backlog och tar fram acceptanskriterierna som avgör om en uppgift är färdig och redo att releasas.
Denna ska även samarbeta med resten av teamet vid framtagande och förfining av kraven till genomförbara uppgifter innan en sprintplanering, och är bara en av medlemmarna i teamet med specialansvar för kravframtagningen, acceptanskriterierna och prioriteringen av backloggen.
Det är sedan utvecklingsteamet som bestämmer vem som tar en viss uppgift, hur de på bästa sätt ska implementera dessa krav, testa, deploya och jobba under en sprint.
Detta eftersom utvecklingteamet är de som vet mest om sitt jobb, och är bäst lämpade att styra över den biten.
Produktägaren och scrum teamet
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.
Scrum fungerar bäst när hela scrum teamet jobbar i samma projekt mot en produktägare och ett projekt i taget och är att föredra.
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.
I det mötet förhandlar de tillsammans 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.
Innan dess bör de olika produktägarna i samråd med scrum teamet har gått igenom sin egen produktbacklog och förfinat de user stories det tänker försöka få med på det gemensamma produktbacklogmötet, så dessa är tillräckligt bra och förstådda innan det gemensamt produktbacklogmötet för alla produktägare.
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ömer 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 samarbetar 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.
Produktägaren bör även delta på teamets standups så ofta som det behövs för att hålla sig ajour med vad som händer, för då behövs inga veckovisa projektmöten i det syftet.
Läs även mitt inlägg:
Instruktionsvideos om scrum för nybörjare
och se de rekommenderade videorna där med, så ni får en grundförståelse för hur hela scrum teamet jobbar och inte bara er egen roll.
Skillnaden mellan agil utveckling och vattenfallsmetodiken
”Instead of executing entire project in a pure linear way, we can break it into multiple iterations. Conduct all analysis in iteration one, design in iteration two and then coding and testing in next iteration/s that is iterative waterfall but that is not agile.”
”An Agile approach combines an iterative and incremental approaches by building each feature, one by one, with minimum feature richness, and then both gradually adding features and increasing feature richness until the right combination is achieved. ”
Agile is iterative and incremental, but iterative waterfall is not agile!
Den viktigaste skillnaden att förstå mellan agilt och vattenfallsmetodiken är att man jobbar både iterativt och incrementellt samtidigt inom agil metodik, vilken man inte gör inom vattenfallsmetodiken.
Det förändrar väldigt mycket i sätten man måste arbeta på för det innebär att man under hela projektets gång arbetar med alla faser i vattenfalls modellen itterativt, samtidigt / parallellt för varje increment för att bit för bit bygga produkten.
I agilt kan man inte ha både ett fastställt scope och en fastställd timeframe
People change their minds for many reasons, and do so on a regular basis. This happens because:
- They missed a requirement. A stakeholder will be working with an existing system and realize that it’s missing a feature.
- They identified a defect. A bug, or more importantly the need to address the bug, should also be considered a requirement.
- They realize they didn’t understand their actual need. It’s common to show a stakeholder your working system to date only to have them realize that what they asked for really isn’t what they want after all. This is one reason why active stakeholder participation and short iterations are important to your success.
- Politics. The political landscape within your organization is likely dynamic (yes, I’m being polite). When the balance of political power shifts amongst your stakeholders, and it always does, so do their priorities. These changing political priorities will often motivate changes to requirements.
- The marketplace changes. Perhaps a competitor will release a new product which implements features that your product doesn’t.
- Legislation changes. Perhaps new legislation requires new features, or changes to existing features, in your software.
The bottom line is that if you try to ”freeze” the requirements early in the lifecycle you pretty much guarantee that you won’t build what people actually need, instead you’ll build what they initially thought they wanted. That’s not a great strategy for success.
Agile Requirements Change Management
Det är viktigt att som produktägare förstå är att man i agilt inte kan ha både ett fastställt scope och en fastställ timeframe så man får välja antingen det ena eller det andra, och detta är en fundamental skillnad mot vattenfallmetodiken.
Har man t.ex. en faställd timeframe och budget så hinner man kanske inte göra klart exakt all önskad funktionalitet, men man kommer hinna göra klart den funktionalitet kunden värdera högst som fungerar exakt så som kunden vill och har behov av.
Vill man ha ett fast scope så kan man inte ha en fast timeframe eftersom de detaljerade kraven i agilt tas fram allteftersom och kan ändras i takt med att man gör upptäckter och får feedback på det som görs.
Även om ni skulle ta fram alla detaljerade krav innan implementationen börjar enligt traditionellt sätt så innebär det faktum att ni jobbar agilt med detaljerad design och kodning i implementationsfasen att krav ändå kommer förändras då.
Därför tar man inom agilt fram de detaljerade kraven allteftersom så man minimerar onödigt arbete.
Agila roadmaps och agil planering
”Roadmaps assist agile teams in defining the big chunks of work they want to do and when. It is a tool to communicate with the team, with customers, and with stakeholders throughout the business.”
”A roadmap isn’t fixed. Dependencies may exist, yet there will be loose coupling. Learning and adaptability are favoured over rigidity.”
The Difference Between Roadmaps and Gantt Charts
Traditionella projektledare är oftast vana att göra väldigt detaljerade Gantt charts för sina projekt och tycker det känns osäkert med agilt och tror ingen planering alls görs, men i agilt gör man också en sort översiktlig planering i form av roadmaps som ofta liknar Gantt charts men mindre specifika.
I ett Gantt chart har man oftast start och stop datum för allt, alla features som ska göras, alla beroenden mellan features och vilka personer som ska göra dessa och när, och dessutom innan genomförandefasen börjar så allt är specificerat från ax till limpa.
Sen tillkommer oftast andra detaljstyrande dokument, checklistor, standards och rutiner för att försöka säkra kvaliteten vilket kan göra det onödigt tungrott i många fall när man jobbar på det traditionella sättet.
”To build a roadmap, product owners take into account market trajectories, value propositions, and engineering constraints. Once these factors are reasonably well-understood, they are expressed in a roadmap as initiatives and timelines.”
What is an agile product roadmap?
Inom agilt gör produktägaren som sagt översiktlig planering av en produkt som kallas för roadmaps som kan göras på lite olika sätt varav vissa är lite lika ett Gantt chart där man i stora drag anger vad man vill göra på lite längre sikt.
Man kan använda Powerpoint som i videon ovan men videon är mer avsedd som ett pedagogiskt exempel på hur man gör en roadmap.
Excel eller t.o.m ett traditionell Gantt verktyg kan vara ett enklare val att göra det i, men man håller sig på en översiktlig nivå och har man start och stopdatum måste man komma ihåg att dessa är preliminära.
”A well-crafted agile product roadmap illustrates how your product or technology will evolve — with a lot of flexibility. Unlike time-based product roadmaps, which focus on dates, an agile roadmap should center around themes and progress.”
Här en video som visar hur man gör en Gantt-aktigt roadmap i online verktyget roadmunk som ni kan testa om ni vill för det ser rätt användarvänligt ut och har en fri provperiod.
Deras sida om Agila roadmaps rekommenderas också att läsa för man kan göra product roadmaps på lite olika sätt.
”In the same way that epics are made up of stories, initiatives are made up of epics. Initiatives offer another level of organization above epics.”
Epics, stories, themes, and initiatives
Sen är roadmaps är tänkta för riktigt stora saker som initiatives och ska visa hur en produkt är tänkt att utvecklas över tid.
Agil kravhantering
”The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.”
I en backlog för en board ska user stories relaterade till en produkts epics och features och ligga och inte saker på högre nivå som initiatives.
En viktig skillnad mot scrum guidens beskrivning om ni jobbar enligt kanbans continious flow är att ni inte behöver brytar ner user stories till storlekar som kan göras inom en sprint av den utvecklare som tar en story, vilket ofta kan vara rätt bökigt.
När man sen påbörjar utrednings/genomförandecykeln av av ett specifikt system, feaure eller komponent så kan man allteftersom lägga upp saker i backloggen för det, för då ligger man på rätt nivå.
Man behöver inte heller specificera upp varenda sub-task man eventuellt kommer göra när man implementerar en user storie utan det är upp till varje utvecklare att själva avgöra vad denne har behov av, och i de flesta fall räcker de olika status kolumnerna på boarden som en user storie flyttas mellan.
Fördelen med en fysik kanban board är att det inte ens är möjligt att börja specificera varenda enskilt sub-task som ska utföras för en user storie eftersom det inte får plats på post-it lappen.
På en digital kanban board är det tyvärr möjligt så man ska vara försiktigt med det så man inte i gammal ineffektiv vattenfallanda börjar överbyråkratisera och detaljstyra för mycket, för det är motsattsen till ett agilt arbetsätt och syftet med en kanban board inom agilt.
”Here’s a look at a fully fleshed out product requirements document that we created using Confluence. Remember, no two product requirements will be exactly the same. Use this example to understand the different elements that should be included in your PRD, but not as the definitive way to do it.”
Product requirements documents, downsized
Inom agilt jobbar man med krav och planering mer lättviktigt, rätt ö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 överens med terrängen.
Sen kan man bedriva kravfångst enligt många olika metoder men det viktiga är att man gör det iterativ och inkrementellt när man jobbar agilt.
I artikeln via länken ovan kan ni se hur lättviktigt kraven för ett epic som gäller anpassning av en webbsajt till visning på en mobiltelefon är jämfört med det traditionella sättet, och består i princip bara av lite övergripande information, user stories och en mock-up som är avsedd att visa ungefär hur webbappen ska se ut på en mobil.
Detta har en eller flera utvecklare oftast varit med och förfinat i ett backlog refinement möte innan sprint planeringen så user storyna ska vara tillräckligt bra för att kunna tas med i en sprint, och en utvecklare kan även vara med på kravfångstmöten med kunden.
Man även ha med eventuella tekniska eller lagkrav en webbapp måste upfylla, men i detta fall är det frågan om mobilanpassning av en befintlig webbsajt.
Sen gör utvecklarna eventuell ytterligare design som en eller annan UML artefact eller annan specifikation de anser behövs innan de påbörjar implementationen, så djupare än ovan behöver inte produktägaren gå för resten sköter utvecklarna ihop med ev. arkitekt efter behov när den väl hamnat i sprintens backlog.
Man gör inte en detaljerad från ax till limpa kravspecifikation med en extremt detaljerad projektplan i form av ett Gantt chart som tar upp allt som ska göras, exakt hur det ska göras, vilka beroenden som finns och vem som ska göra vad och när, och tar fram 10 olika extremt detaljerade UML artefakter som försöker förutsäga exakt hur systemet ska se ut och fungera ur alla aspekter innan genomförandefasen.
Från början (när sprint 1 startar) har man bara en övergripande produktvision om ungefär vad man vill åstadkomma så man har slutmålet klart för sig, eventuellt en översiktlig roadmap, och sedan tar man fram förfinade user stories så det räcker för ungefär 2-3 sprintar framåt innan utvecklingen dras igång om det är ett längre och större projekt.
Sen gör man klart den viktigaste funktionaliteten först efter produktägarens prioriteringar av backloggen och utökar steg för steg en applikation med funktionalitet så länge tid och ytterligare krav fortfarande finns, i stället för att i sann vattenfall anda göra en big bang design, hoppas på att man fick till allt rätt och att tiden räcker till för att få allt att fungera.
Detta för att det inte ens är säkert att big bang designen blir 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.
Slutresultatet när man jobbar agilt blir att man får en applikation som innehåller den funktionalitet kunden anser är viktigast 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.
Mer om agila epics
”Breaking initiatives into epics helps keep the team’s daily work — expressed in smaller stories — connected to overall business goals”
Agile epics: definition, examples, and templates
Beskrivningen av epic’et eller featuren och user stories kan man även nöja sig med att bara lägga upp på boarden där de ingående user story’na är kopplade till epicet om ni använder Jira eller Azure DevOps.
Stories, bugs, and tasks describe a single piece of work, while epics are used to describe a group of issues that all relate to the same, larger body of work. Epics are typically completed over several sprints, or a longer time frame if you don’t use sprints.
I Jira så är motsvarigheten till features i Azure DevOps Issues utom för basic processen där de är samma, men Issues kan även användas till annat än features i Jira så inte direkt en 1:1 mappning.
Man knyter oftast en user story direct till ett Epic och använda mellannivån features om man jobbar med stora system där det finns en nytta med det och man i stället beskriver initiativet med Epics i Azure DevOps.
När man bara använder Epics så motsvarar det mer eller mindre en feature enlig nedan beskrivning och är nog den vanligaste nivån att lägga Epics på.
Har ni t.ex valt den agila processen i Azure Devops kan ni oftast strunta i Epics som kanske borde kallats initiatives i stället för den processen, och i stället använda features som Epics.
För större saker kan man använda dem till initiatives i Azure DevOps, men oftast är det kanske enklare och renare att inte göra det och hålla initiatives på sin egen roadmap i de fall det behövs.
Features
Add view options to the new work hub
Add mobile shopping cart
Support text alerts
Refresh the web portal with new look and feelEpics
Increase customer engagement
Improve and simplify the user experience
Implement new architecture to improve performance
Engineer the application to support future growth
Support integration with external services
Support mobile apps
Define features and epics in Azure DevOps
För varje kanban board man skapar i Azure DevOps kan man välja att följa en viss process och även ändra den i efterhand, där vissa är enklare än andra och har lite olika namn för det vi kallar user stories.
Basic kallar dem för Issues, Agile kallar dem för User Stories och i Scrum processen kallas de för Product Backlog Items.
I Azure DevOps får du en kanban board som inte är kopplad till sprintar och en task board som är kopplad till sprintar så följer man kanban kan man strunta i sprintar och taskboarden.
I Jira kan du skapa antingen en Scrum board som följer sprintar eller en Kanban board som inte följer sprintar.
Utöver default kolumnerna till en board så kan man konfigurera den efter behov och lägga till och ta bort kolumner och swimlanes.
Atlassians Jira och Azure DevOps är advancerade plattformar för professionella agila team så de kan ta lite längre tid för er att lära er göra epics, features och sköta backloggen där jämfört med Trello.
Allt beror på behoven ni har och ni kan mjukstarta med Trello och gå över tilll någon av den andra två senare om ni vill.
Vill ni använda Trello för epics kan gratis power-upen Epic Cards by Screenful vara användbar.
Introducing the Epic Cards Power-Up!
Organisationen bör utbilda nya produktägare
Varje ny produktägare i en organisation bör informeras om hur systemet med att ta fram en produktbacklog och ev gemensam produktbacklog 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.
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å arbetsmetodiken 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 relativt 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 verklighetsanpassat, dynamiskt och tillfredsstä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.
Ytterligare produktägarresurser
Atlassian som gör det agila teamverktyget Jira för att skapa och hantera agila boards för agila team har rätt bra introduktionssmaterial till agilt, och här några för agila produktägare.
Robert Forsström's Blogg 
[…] Introduktionsvideo för agila produktägare i scrum […]
GillaGilla