De rol van de PO

In elk Scrum-project wordt er aan de klantzijde een Product Owner (PO) aangewezen. Hij/zij speelt gedurende het hele traject een cruciale rol. Als onderdeel van het team is de PO namelijk degene die bepaalt waar het team aan werkt en op welk moment. Scrum-master Erik van Eeuwijk schreef hier al eerder een blog over. INFO doet er alles aan om de PO zo goed mogelijk te ondersteunen. Iedereen in het team doet dit op zijn of haar eigen manier. Paul van Putten is Product Designer bij INFO en legt aan de hand van voorbeelden bij de Stadsbank van Lening uit hoe een designer de PO kan ondersteunen om een nóg beter product te maken.

Verbetering vs. verbouwing

Een mogelijk risico bij het opnieuw bouwen van een product, zoals bij de Stadsbank het geval was, is dat de huidige functionaliteiten het uitgangspunt zijn. Gebruikers willen dat deze functionaliteiten één-op-één worden overgenomen in het nieuwe product, terwijl herbouw juist kansen biedt om het systeem echt beter te maken met andere functionaliteiten. De PO moet dan wel zicht hebben op waar deze verbeteringen gedaan kunnen worden en de huidige gebruikers zullen moeten accepteren dat er wellicht wat wijzigingen aangebracht worden in een systeem waar ze inmiddels vertrouwd mee zijn.
Om ze beter te begrijpen, wilden we bij het Stadsbank-project eerst zien hoe de medewerkers met het bestaande systeem werkten. Het begrijpen van de gebruikers is voor de PO ook belangrijk, omdat die verantwoordelijk is voor het eindproduct wat uiteindelijk waarde moet gaan toevoegen voor de eindgebruiker. Wij hadden het geluk dat ‘onze’ PO dagelijks met het oude systeem werkte en wij daardoor makkelijker toegang tot de eindgebruikers hadden.

Job shadowing

Een doeltreffende manier om te weten te komen wat de eindgebruiker bezighoudt, is job shadowing, wat betekent dat iemand een bepaalde periode wordt geschaduwd terwijl zij haar reguliere werkzaamheden uitvoert. Dit hebben we aan het begin bij de Stadsbank veel gedaan. Hierbij observeerden we de taxateurs tijdens hun dagelijkse werkzaamheden. Job shadowing heeft twee belangrijke voordelen. Ten eerste is het de meest objectieve manier om een eindgebruiker aan het werk te zien. Daarnaast begeef je je dichtbij de gebruikers, zodat ze meteen weten wie je bent. Dit is belangrijk als je te maken hebt met een doelgroep die al jarenlang op dezelfde manier met elkaar werkt: je creëert draagvlak. Wij observeren, noteren en stellen achteraf vragen over interessante zaken die of gedrag dat we gezien hebben.

Eén van de zaken die ons opviel tijdens de ‘schaduwperiode’ bij de Stadsbank was dat een taxateur zijn scherm liet zien aan de klant. Toen we hiernaar vroegen kwamen we erachter dat het voor de klant helpt om te weten wat hij of zij precies bij de Stadsbank in onderpand heeft staan. Deze behoefte aan transparantie is voor ons een belangrijk inzicht geweest en heeft een belangrijke rol gespeeld in de vernieuwde online omgeving van de Stadsbank.

Testen met gebruikers

Naast job shadowing testen we de belangrijkste flows van het systeem met de eindgebruikers. Vroeg testen met eindgebruikers heeft een tweeledig doel: enerzijds wil je feedback hebben op je concept en anderzijds wil je de gebruikers in een vroeg stadium alvast kennis laten maken met het product. Het is aan te raden om de PO zo veel mogelijk te betrekken bij het testen, zodat de PO zich nog beter bewust wordt van de behoeften van de eindgebruikers.

Elk softwareontwikkelingstraject kent per definitie onzekerheden en je kunt nu eenmaal niet alles van te voren weten. Tijdens het testen van ontwerpen bij gebruikers bleek al gauw dat bepaalde eisen die de Stadsbank vooraf had opgesteld niet aansloten bij de behoeftes van de gebruikers. Doordat de PO bij de testen aanwezig was, kon deze dit terugkoppelen aan de stakeholder die de eis had ingebracht. Hierdoor zijn uiteindelijk deze eisen aangepast. Testen met gebruikers biedt de PO dus argumenten om de discussie aan te gaan met stakeholders.

Hoe kun je goede user stories schrijven?

De PO is verantwoordelijk voor de Product Backlog. Deze bestaat uit user stories: verhaaltjes waarin beschreven staat wat de gebruiker wil en waarom. Idealiter zijn user stories een communicatiemiddel waarbij het team samen naar een oplossing zoekt.
Mogelijke valkuilen bij het schrijven van user stories zijn dat er teveel een oplossing wordt beschreven en teveel in details wordt getreden. Zo valt er weinig meer te onderzoeken, omdat alles al vastligt. Een PO is expert op het gebied van de business; het wat en waarom van de organisatie. De PO doet de voorzet van de invulling van de user story, maar doet er daarbij goed aan om deze zo snel mogelijk met het team te delen.

Tijdens het schrijven van de user stories, wordt een PO ondersteund door ons. De designer gaat op zoek naar de achterliggende vraag van een user story, om zo in samenspraak met de PO tot een goede user story te komen. Dit geeft het development team houvast en context, en zorgt ervoor dat de story waarde oplevert, zonder dat er te veel gebouwd wordt.
Een andere valkuil is het gebrek aan focus tijdens het schrijven van user story. Een user story moet eenduidig zijn. Alles wat niet bijdraagt aan het gebruiksdoel hoort thuis in andere stories. De designer kan de PO helpen met het onderscheiden van hoofd- en bijzaken en focus aanbrengen in de story. Weinig focus betekent vaak ook veel details. Soms zijn details belangrijk, maar meestal is dit iets wat in de sprint of bij verdere refinement wel wordt opgelost. Bij de Stadsbank werden de oplossingen bijvoorbeeld veelal tijdens de sprint bedacht. Een gebrek aan focus vermindert ook de leesbaarheid van een user story, het maakt de story groter en draagt niet bij aan het toevoegen van waarde.

Hoe kun je de stakeholders meekrijgen?

Stakeholders zijn de belanghebbenden in een project. Eén van de verantwoordelijkheden van de PO is om de input van stakeholders te krijgen in een project en daarmee draagvlak te creëren. Dit is meteen een uitdaging. Wij nemen een deel van dit werk uit handen door de samenwerking tussen stakeholders en PO te faciliteren .
We nodigen stakeholders meteen aan het begin van een traject uit voor verschillende sessies die we organiseren in de beginperiode. Daardoor betrekken we stakeholders bij de ontwikkeling van de productvisie, de technische visie en de samenwerkingsvisie.

Designers houden zich vooral bezig met de productvisie. We hebben bij de Stadsbank de flow van de medewerker in kaart gebracht. Door met verschillende stakeholders tegelijk de huidige flow in kaart te brengen ontstaan er vanzelf interessante discussies. Het is interessant om te horen hoe een manager het beleid uitlegt, en dat vervolgens een medewerker vertelt hoe het er daadwerkelijk op de werkvloer aan toe gaat. Het resultaat is een compleet beeld van de ervaringen, pijnpunten en kansen.
Ook hebben we door middel van co-creatie oplossingen bedacht voor de belangrijkste pijnpunten. Dit biedt iedereen de mogelijkheid om mogelijke oplossingen te schetsen voor de pijnpunten. Het visueel maken van ideeën helpt hierbij in de communicatie. Bovendien worden stakeholders gehoord en kunnen ze concreet bijdragen aan het product.

Tijdens het sprinten is de sprint review hét moment om stakeholders te betrekken en voortgang te laten zien. Je geeft een idee van wat er gebouwd is door het team en is er de gelegenheid om feedback te geven. Dit is belangrijk, omdat het voor stakeholders lastig kan zijn om een voorstelling te maken van waar een development team mee bezig is. Omdat de PO ambassadeur van het product is, is het fijn als de PO de sessie ook leidt. Het is hierbij slim om als PO een context te geven: waar staan we in het project en wat wordt er de komende sprint opgepakt? Op deze manier neemt de PO verantwoordelijkheid voor het werk wat gedaan is en versterkt het zijn positie ten opzichte van de stakeholders.

Hoe kun je het team optimaal ondersteunen?

Het is belangrijk dat de PO tijdens de sprint beschikbaar is voor het team om vragen te beantwoorden, hoewel dat door de pandemie en de daaropvolgende lockdown(s) wel lastiger was. Voor ons is Slack het primaire communicatiekanaal en het is dan ook vanzelfsprekend dat de PO’s hier toegang tot hebben.

Wij adviseren PO’s om op vaste tijden een overleg te plannen met de designer, om stories door te nemen en vragen te beantwoorden. Dat helpt de PO met vooruit kijken. Designers zijn hiervoor de ideale sparringpartners, omdat ze nooit volledig bezig zijn met de huidige sprint en vaak het meest complete beeld van de context en de business hebben. Samen met de PO schetst de designer ideeën, werkt flows uit en schrijft user stories. Daardoor is hij/zij op momenten dat de PO niet beschikbaar is de aangewezen persoon om vragen over het product te beantwoorden.