Soms rol je ergens in zonder goed en wel te weten waarin. Zo ben ik per ongeluk in mijn rol als PO terechtgekomen. En eerlijk is eerlijk, ik had nooit een fijnere rol. Ik heb genoten van mijn jaren als beheerder, als project manager en recruiter. Maar zoveel voldoening als dat ik uit mijn huidige rol haal heb ik niet eerder gehad. Maar wat doet een PO nu gedurende de werkweek? Dus niet de theorie maar de praktijk. En die is natuurlijk bij ieder bedrijf weer anders. Overigens is het voor een product owner wel belangrijk om de papiertjes te hebben. Uit onderzoek blijkt namelijk dat het salaris van een gecertificeerde PO (met 4 papiertjes) het maandsalaris tot wel €1100 per maand hoger ligt. De onderzoeken: HIER en HIER
Stakeholder management
De producten of platformen waar ik verantwoordelijk voor ben (Integratie Services, Microsoft Dynamics 365 en het Microsoft Power Platform) hebben natuurlijk gebruikers. Vaak heb je per afdeling of beroepsgroep (sales, hr of it) een stakeholder. Dat is de persoon om mee te overleggen wat je wil gaan doen. En eerlijk gezegd is stakeholder management het lastigste wat er is. Het gaat namelijk om communicatie met mensen. En verschillende mensen, verschillende wensen. Mijn stakeholder management houdt meestal in dat ik met mensen in discussie moet. Iedereen vindt zichzelf belangrijk (wat ze binnen hun gebied ook zeer zeker zijn) maar ik heb natuurlijk maar een beperkte ontwikkel en test capaciteit. Daarom is het schipperen met tijd.
Een ander veel voorkomend probleem is dat stakeholders vaak niet weten wat ze exact willen als eind product. Tijdens het vaststellen van de wensen (die uiteindelijk de userstory worden) wordt er vaak iets anders geroepen dan wanneer je het laat zien aan de stakeholder. Mijn tip aan alle P.O.’s is dus het goed vastleggen van de wensen, deze doornemen met de stakeholder en dan de stakeholders akkoord vastleggen. Op die manier krijg je achteraf geen gezeur over de functionaliteit. Wij leggen dit vaak in de mail vast en vervolgens in TFS (Azure DevOps).
In de rode rechthoek leggen we de naam van de Stakeholder vast en leggen we de datum van goedkeuring vast. Dit is even wat meer werk maar voorkomt discussie achteraf.
Backlog management
Dit vind ik persoonlijk het mooiste wat er is in mijn werk. Ik weet dat er een hoop PO’s zijn die het schrijven van user stories en het beheren van de backlog het minst leuke vinden. Call me weird ;-). Maar ik hou er van om de vragen van de stakeholder uit te schrijven en dat zo te doen dat mijn developers weten wat ze moeten doen en voor mijn stakeholder duidelijk is dat ik hun vraag heb begrepen.
Mijn werk als PO bestaat meestal uit het schrijven van user stories en het prioriteren van deze user stories. Wij maken bij ons gebruik van Projects, EPICS, Features en PBI’s in TFS. Omdat ik 3 platformen heb met een gezamenlijke backlog heeft ieder platform een Project. Binnen die projecten hebben wij EPICS. Bijvoorbeeld bij het Project Power Platform hebben wij EPICS voor bijvoorbeeld APP1 – MVP, APP2 – V3. de eerste app wordt gebouwd als MVP (minimum viable product) en app 2 is inmiddels aan versie 3 toe. Binnen de EPICS hebben we features. Dat zijn opzichzelfstaande functionaliteiten. Bijvoorbeeld in versie 3 van app 2 moet er een extra scherm komen voor het aanmaken van een sales mogelijkheid. Omdat dit een losstaande functionaliteit is behandelen we dit als een feature. Binnen de features schrijf ik PBI’s (product backlog items). Daarin beschrijf ik per onderdeel van een feature wat de developers functioneel moeten bouwen
Overleg, overleg en overleg
Communicatie is key. Daarom maak ik er een gewoonte van dagelijks aan te sluiten bij de dailies van de teams. Daar hoor je het laatste nieuws over alle ontwikkelingen. Soms kan je daar ook meteen een aanstaande uitdaging de kop indrukken. Ook met mijn Roemeense scrum master heb ik dagelijks contact. Hij zorgt voor de dagelijkse gang van zaken en faciliteert het team in wat ze nodig hebben. Couldn’t do it without him.
En natuurlijk heb ik zoveel mogelijk contact met de developers, architect en consultants. Zij zijn mijn SME (subject matter experts), de mensen die technisch veel meer kennis hebben dan ik. Zo ontzettend belangrijk.
Wees duidelijk en een vraagbaak
Naast deze werkzaamheden is het mijn taak vragen van de developers beantwoord te krijgen. Soms kan ik dat zelf en soms moet ik een stakeholder raadplegen. Ook zorg ik voor het uitleggen van het werk dat gedaan kan worden in een volgende sprint. Dat is “de refinement”. Hierbij leg ik uit wat ik aan functionaliteit wens en kunnen de developers inschatten hoe lang het duur.
Let op “inschatten“. Binnen Scrum plannen we namelijk niet hard vooruit. We doen guesstimations. Dat zijn onderbouwde aannames maar met de kanttekening dat zaken nog niet helemaal duidelijk kunnen zijn. Wij werken met een aantal statussen in TFS. Deze geven aan of er werk gedaan kan worden, gedaan is of dat iets on hold staat bijvoorbeeld.
Totaal niet boeiend voor jou maar wat ik er mee wil zeggen is dat je een verbinder moet zijn tussen de klant (stakeholder) en je team (developers etc). Zorg dat je een persoon bent waar de stakeholders het gevoel bij krijgen dat ze gehoord worden.
Dat wil niet zeggen dat de klant altijd gelijk heeft. Soms kan een klant het echt wel mis hebben. Serieus, ik ken ze.
Tot slot
niets is wat het lijkt. Als PO ben je niet alleen PO. Ik ben ook vaak deels project manager, people manager en omdat het grootste gedeelte van mijn team in het buitenland zit ben ik vaak ook de spokesman met het management. Daarnaast heb ik het geluk te beschikken over een architect en consultants in het team. En sinds kort hebben we ook een Business Analist. Al met al mooi werk dat met vlagen ook erg hectisch en stressvol kan zijn. Maar ik zou het niet anders willen.