Hoewel we in Nederland gelijkheid voor iedereen nastreven is het belangrijk was je voor werk doet. In de meeste gesprekken met nieuwe mensen is de vraag meestal: “en wat doe jij in het dagelijks leven?”. Mijn antwoord is dan steevast dan ik Product Owner. Binnen de IT zijn Product Owners vaak de laughing stock van het geheel. Developers kunnen iets bouwen, testers werken er aan om te zien of ze het kapot krijgen. De SCRUM-Master faciliteert het team tot hij/zij er bij neervalt. En de Product Owner? Die doen toch de hele dag niets? Niet helemaal waar.
De Product Owner volgens SCRUM
Binnen de SCRUM methodiek is de product owner de persoon die de backlog beheert. Dat is de voorraad van werk waar nog niet aan gewerkt wordt op dat moment. Je hebt dus een grote verzameling van werk en het is de taak van de product owner om te bepalen wat echt van waarde is voor het product waar je als PO verantwoordelijk voor bent. Daarnaast zorg je er voor dat de juiste prioriteiten gesteld worden. Dat is volgens de SCRUM methodiek.
De rol van Product Owner in het echt
Hoe de rol van Product Owner wordt ingevuld hangt natuurlijk ook heel erg af van het bedrijf waar je werkt. Bij het ene bedrijf mag je je eigen toko runnen bij het andere bedrijf volg je de Product Manager. In mijn geval geldt het eerste. Ik run mijn eigen toko. Ik haal zelf werk op, zorg dat de prioriteiten juist zijn en dat mijn “klanten” tevreden zijn.
Als ik echter aan mensen moet uitleggen wat ik precies doe leg ik dat uit als een verhalenverteller die eerst nog even de hoofdstukken in de juiste volgorde moet leggen.
In mijn dagelijks werk zit ik vaak met klanten (stakeholders) aan tafel. Dit zijn de mensen die of een nieuw product willen of aanpassingen aan een van onze bestaande producten willen.
Iedereen die wel eens met product ontwikkeling of klanten te aken heeft weet dat je enerzijds door moet vragen om te weten wat de klant écht wil. Dus niet: ik wil een knopje om te printen! Maar: waarom wil je een knopje om te printen? Er zit al een printfunctionaliteit in het product. Werkt die niet goed?
Anderzijds is het ook aan de product owner om te bepalen of iets echt van toegevoegde is voor het product. Bij meerdere verzoeken bepaal je als PO ook de prioriteit. Al dat werk in de backlog met de wensen in de juiste prioriteit maakt jouw roadmap voor de toekomst.
En dan komt het echte werk. Als product owner moet je nu functioneel beschrijven wat je klant wil. Veel PO’s maken de fout een technische oplossing op papier te zetten. Aan de ene kant belemmer je zo creativiteit en anderzijds kan je vaak als PO niet alles overzien.
Hoe ik dat doe?
Mijn team bestaat uit zeer ervaren en vakvolwassen developers en testers. Dus mijn taak bestaat uit het functioneel beschrijven van de klantwensen. Dit doe je in een PBI (product backlog item). Daarin beschrijf ik per kleinste zelfstandig onderdeel van de ontwikkeling wat er moet gebeuren. Dus bijvoorbeeld:
Als manager van de financiële afdeling wil ik de dagelijkse bestanden uit het facturatie pakket geïmporteerd hebben in het boekhoudpakket. De bestanden worden iedere nacht om 0:00 klaargezet in een gedeelde map en moeten vóór 7:00 geïmporteerd zijn. Dit heeft voor ons als voordeel dat we een hoger first time right percentage bereiken en zo onze klant tevredenheid groeit.
Voor de testers is het belangrijk wanneer iets goedgekeurd kan worden. Dit is beschreven in de acceptatie criteria. Dat kan bijvoorbeeld zijn:
Het werk aan deze PBI is gedaan als iedere ochtend voor 7:00 de gegevens van de vorige dag zijn geïmporteerd in het boekhoudpakket en aan de juiste klant hangen.
Als al dit werk is uitgeschreven begeleid je als Product Owner de estimation. Dit is de fase waarin de developers bepalen hoeveel tijd zij nodig hebben voor dat stukje werk (het PBI). Die schattingen kunnen op verschillende manieren gedaan worden. Wij hanteren een Fibonacci reeks. 1-2-3-5-8-13. Een 1 is een paar urtjes werk en 8 is een week. Aan ieder PBI hangt dus het aantal verhaal punten.
Wij werken in sprints van 3 weken dus aan het einde van de sprint plannen we de nieuwe sprint waarbij de PO het laatste woord heeft in wat er daadwerkelijk in de sprint gaat. Aan iedere sprint hangt een “velocity” wat je kunt zien als de capaciteit in verhaalpunten. Als je weet hoeveel werk je kunt verzetten in een sprint in punten kun je dus plannen hoeveel en welke stukjes van het werk je kunt doen in 3 weken.
Conclusie
Het werk van een product owner is heel breed maakt verschilt ook per bedrijf. Bij mijn werkgever ben je naast eigenaar van de toko ook business analist, eerste punt van contact voor de klanten, troubleshooter, schild voor het development team en dus ook verhalenverteller. En hoewel ik mijn dagen als systeembeheerder en project manager ook nooit zal vergeten denk ik dat ik momenteel gelukkiger ben in mijn rol als PO dan ooit tevoren in mijn werk.
Wil jij nou ook prettig werken bij een bedrijf waar je verantwoordelijkheid krijgt en waar technische vooruitgang voorop staat? Kijk even op de Centric Careerpage. En laat vooral even weten dat je via mij kwam 🙂