De ultieme checklist voor elke product owner - 18 tips voor een succesvol scrum project

Als beginnend product owner heb je een uitdagende taak voor de boeg. Je bent verantwoordelijk voor het definiëren en prioriteren van de product backlog, het bepalen van de productvisie en -strategie en het werken met het ontwikkelingsteam om de gewenste functionaliteit te leveren. Het kan overweldigend zijn om al deze verantwoordelijkheden op je te nemen, maar gelukkig zijn er manieren om deze taken makkelijker te organiseren en te vereenvoudigen. In deze checklist vind je een aantal nuttige tips die je helpen om je te concentreren op de belangrijkste taken en om een succesvolle product owner te worden. 

1# Weet wat Scrum is en wat jouw rol als product owner inhoudt. 

Dit is een vrij logische tip, maar in de praktijk wordt deze stap nog geregeld overgeslagen terwijl het essentieel is dat je weet hoe scrum werkt en wat termen zoals sprintplanning, sprintreview, retrospective of backlog betekenen. Naast de betekenis moet je als product owner goed begrijpen waarom bepaalde scrumevents bedacht zijn en wat het doel is zodat je als leider van het scrumteam weet wat er gedaan moet worden. 
 
Dit zijn enkele bronnen die je helpen om je verder te verdiepen in het scrum framework: 

• De Agile Alliance.
• Scrum.org.

2# Zorg ervoor dat je de productvisie begrijpt en communiceer de visie duidelijk naar het team. 

Als product owner leidt je het development team en vertaal je de wensen en behoeften van de stakeholders naar een uiteindelijk product. Breng daarom goed in kaart wat die wensen en behoeften zijn zodat je ze kunt overdragen aan het developmentteam.  

3# Zijn je stakeholders collega’s of managers?

Soms heb je te maken met directe collega’s of managers die gaan werken met de applicatie die jij ontwikkelt. Inventariseer hun wensen door bijvoorbeeld een brainstormsessie te organiseren. Heb je dit nog niet eerder gedaan, hier zijn een paar tips:

• Stel een doel vast: Bepaal vooraf het doel van de brainstormsessie, zoals het genereren van ideeën voor de nieuwe website of het verbeteren van de gebruikerservaring.
• Selecteer de juiste deelnemers: Nodig mensen uit met verschillende achtergronden en expertisegebieden om een breed scala aan perspectieven en ideeën te krijgen.
• Bereid de sessie goed voor: Stuur voorafgaand aan de sessie een agenda met het doel en eventuele achtergrondinformatie, zodat de deelnemers zich kunnen voorbereiden.
• Creëer een comfortabele omgeving: Zorg voor een ontspannen en uitnodigende omgeving waarin deelnemers zich op hun gemak voelen om hun ideeën te delen.
• Houd het positief: Moedig een open en positieve sfeer aan waarin alle ideeën welkom zijn, zonder directe kritiek of afwijzing.
• Bepaal een tijdslimiet: Stel een tijdslimiet in voor de sessie om de energie hoog te houden en gefocust te blijven op het doel.

4# Zijn je stakeholders klanten of gebruikers?

Als de stakeholders klanten of andere gebruikers van een applicatie zijn, is juist een gebruikerstest of enquête een goede manier om te achterhalen waar de behoeften liggen. Dat kun je zo klein en groot maken als je zelf wilt. Mensen die dit onderzoek vaak doen geven aan dat slechts een handjevol klanten of gebruikers ondervragen al voldoende zijn. En heb je hier geen ervaring mee, dan zijn er genoeg bureau ( zoals Emble ) die dit onderzoek voor je kunnen doen.

UX industry leader Jakob Nielsen has advocated using five users for years, saying: “Testing with five people lets you find almost as many usability problems as you’d find using many more test participants.

Bron: uxdesigninstitute.com

5# Creëer mandaat! 

Zeker wanneer de stakeholders je directe collega's of managers zijn is het belangrijk om duidelijk te maken dat jij de product owner bent en het mandaat hebt om keuzes te maken. Bijvoorbeeld welk onderdeel in welke fase wordt ontwikkeld. Je werkt uiteraard in samenspraak met het developmentteam dat jou van feedback voorziet over de mogelijkheden en opties, maar je titel is niet voor niets product owner. Wat ook kan helpen is om je organisatie bewust te maken van wat scrum eigenlijk is. Je kan dat doen door video’s zoals Scrum in under 5 minutes te delen en vragen te beantwoorden. Je stakeholders moeten soms nog wennen aan het idee dat in stappen gewerkt wordt en dat er vaste scrumevents zijn. 

6# Blijf communiceren met stakeholders en houd ze op de hoogte van de voortgang en het product. 

Je kunt stakeholders uitnodigen bij sprint reviews, maar houd ze ook tussentijds op hoogte van de voortgang. Het helpt bij het geruststellen dat er progressie is, vooral als stakeholders erg betrokken zijn bij het project of veel belang hebben bij het uiteindelijke product. Daarnaast is het telkens weer een kans om te herhalen hoe het scrumproces werkt en wat jouw rol als product owner is. 

7# Gebruik de sprint review om draagvlak, betrokkenheid en feedback te stimuleren bij de stakeholders. 

De sprint review heeft niet als doel om het geleverde werk te controleren. Als product owner ben je al continu aan het testen en feedback geven. De sprint review is in principe bedoeld om als scrumteam aan de stakeholders te laten zien waar het product op dat moment staat. Welke ontwikkelingen zijn succesvol doorgevoerd? Hoe kijken de stakeholders hier tegenaan? En hoe zien zij de verdere ontwikkelingen in de komende sprints? Uiteraard moet je als product owner hierin de leiding nemen en bewaak je de balans van feedback vragen en verwachtingen scheppen. Maar door de stakeholder periodiek mee te nemen in de ontwikkelingen zien ze de progressie en ontstaat er draagvlak voor komende ontwikkelingen én extra mandaat voor jou als product owner.  

8# Wees niet bang om features of wensen weg te gooien. 

64 percent of features in products are “rarely or never used.

Bron: Standish Group Research

Wanneer je alle wensen van alle stakeholders laat ontwikkelen is de kans groot dat je niet alleen een zeer complex project krijgt, maar ook een product dat lastig in het gebruik wordt. Dit wodt ook wel “bloated” genoemd: een applicatie is opgezwollen en zit vol met elke denkbare functie, met alle nadelen van dien. Communiceer hier wel open over naar je stakeholders. In sommige gevallen kun je aangeven dat hun wensen mogelijk in latere versies wel aan bod komen. Wanneer duidelijk is dat dat absoluut niet gaat gebeuren is het beter om de pleister er maar direct af te trekken en nee te verkopen.  

9# Maak duidelijke en beknopte user stories. 

Wanneer je helder hebt hoe het product eruit moet gaan zien of gaat werken kun je user stories maken. User stories zijn eigenlijk gebundelde wensen/eisen die beschreven worden vanuit een gebruiker. Een gebruiker kan bijvoorbeeld een klant zijn of een collega die de administratie doet. Door duidelijk te beschrijven wat de gebruiker moet kunnen doen of zien richt je je vooral op het einddoel in plaats van hoe je ergens komt. Dat heeft als voordeel dat het developmentteam de ruimte heeft om invulling te geven aan de user story waardoor er sneller ontwikkeld kan worden. Zolang de user story goed beschreven is en het doel wordt behaald, ontstaat er een goed product.  

10# Bereid een roadmap voor bij grotere projecten. 

De meeste projecten bestaan uit meerdere sprints. Een roadmap kan je dan overzicht geven wanneer wat wordt ontwikkeld.  

Dat kan in een lijstje: 

• Maand 1:  
• Sprint 1: Werken aan de databasestructuur en API. 
• Sprint 2: Klantenportal bouwen met de functionaliteiten die daarbij horen. 
   
• Maand 2: 
• Sprint 3: UX-designtraject waarbij een nieuw design gemaakt wordt met aandacht voor toegankelijkheid (WCAG 2.1). 
• Sprint 4: Frontend development (design wordt omgezet naar functionele website). 
   
• Maand 3:  
• Interne en externe test afronden.  
• Feedback verzamelen en verwerken. 
   
• Maand 4:  
• Sprint 5: Verbeteren en livegang.  
• Sprint 6: Google Analytics, Search Console, Adwords, E-marketingcampagne inrichten. 

Maar je kunt het ook visueel maken: 

Het doel is in ieder geval om iedereen buiten het scrumteam een globaal idee te geven wanneer wat gemaakt wordt. Zo kun je stakeholders precies laten zien hoe het traject eruitziet en externe partijen laten weten wanneer ze klaar moeten staan om bij te springen. Houd er natuurlijk wel rekening mee dat een agiletraject altijd in beweging is en dat een roadmap meestal na elke sprint bijgewerkt moet worden. Soms gaan bepaalde ontwikkelingen sneller dan verwacht of ontstaan er nieuwe inzichten waarvan jij als product owner bepaalt dat die voorrang krijgen.

11# Prioriteer de product backlog op basis van waarde voor de klant en zakelijke behoeften. 

Als product owner bepaal jij waaraan gewerkt wordt en in welke volgorde. Deze volgorde kun je aanpassen naar aanleiding van feedback vanuit het developmentteam. Bijvoorbeeld dat het verstandiger is om eerst story 1 op te pakken in de eerste sprint om zo meer inzicht te krijgen en story 4 beter te kunnen definiëren. Bij de start kun je de prioriteiten bepalen op waarde voor je stakeholders. Bij welke onderdelen zijn ze het meeste gebaat? Die krijgen voorrang op andere stories die minder waarde vertegenwoordigen. 

12# Maak tijd vrij voor het team om vragen te stellen en feedback te geven. 

Het developmentteam kan met goed opgestelde user stories en een duidelijke sprintplanning zelfstandig aan de slag. Op het moment dat er toch vragen ontstaan is het belangrijk om als product owner snel antwoord te kunnen geven. Soms kan bijvoorbeeld het developmentteam niet verder zonder bepaalde informatie waardoor het behalen van sprintdoelen in gevaar kan komen. Hoeveel tijd je vrij moet maken is altijd lastig in te schatten. Over het algemeen zien we dat hoe beter de user stories uitgewerkt zijn, hoe minder vragen en feedback nodig zijn.  

13# Geef feedback op een duidelijke manier en voorkom scope creeping.  

Wanneer je een story test en ontdekt dat dingen anders of beter kunnen is het belangrijk om dit op een heldere en duidelijke manier te verwoorden zodat het developmentteam het probleem niet alleen begrijpt, maar ook kan reproduceren en testen.  

Daarnaast is het belangrijk te voorkomen dat de feedback begint over een story maar uiteindelijk eindigt in een afgeleide nieuwe story. Dit wordt scope creeping genoemd en is gevaarlijk binnen elk project, maar zeker in scrum. Het vormt een onzichtbaar lek dat tijd opeet waardoor andere doelen niet behaald worden.  
 
Wees als product owner daarom altijd alert op scope creeping. Met name bij het geven van feedback is het belangrijk om na te gaan of de feedback betrekking heeft op de originele story of dat het eigenlijk gaat om een nieuwe story of scopewijziging, waardoor de story weer terug moet naar de backlog. 

14# Werk samen met het team om haalbare sprintdoelen te stellen. 

Eigenlijk is dit een tip voor het gehele scrumteam. Bij elke sprint moet duidelijk zijn waaraan wordt gewerkt en wanneer het doel behaald is. Een goede scrummaster zal hier altijd op hameren en een developmentteam heeft ook de verantwoordelijkheid om niet te starten met werk dat vaag of niet helder is. Als product owner kun je hieraan bijdragen door na te denken over duidelijke criteria. Een voorbeeld: 

Je zit in een designsprint en je wilt een overzicht van diensten. Voor jouw helder, maar is dat ook helder voor de ontwerpers en developers die hiermee aan de slag gaan? 

15# Begrijp globaal hoe je website wordt gebouwd en wat de technische termen inhouden die gebruikt worden. 

Je hoeft natuurlijk geen programmeertaal te leren als product owner, je hebt genoeg andere zaken te doen. Maar het is wel praktisch wanneer je globaal een idee hebt van bepaalde technische zaken die invloed hebben op je website. Wat is bijvoorbeeld een OTAP-omgeving en wat moet je met een acceptatie- en testomgeving? Hoe zit het met aanpassingen op de livewebsite? Wordt je website met React/Next.js ontwikkeld? En wat zijn dan de voor- en nadelen?  
 
De communicatie met het developmentteam wordt hierdoor makkelijker, en omdat je de spil bent tussen het scrumteam en de stakeholders kun je ook beter uitleggen waarom de dingen gaan zoals ze gaan. Het maakt je positie als product owner sterker.  

16# Wees flexibel en pas de backlog aan op basis van nieuwe informatie en feedback. 

Het komt vaak voor dat nieuwe ontwikkelingen ook nieuwe inzichten met zich meebrengen. Een van de grootste voordelen van scrum is dat die nieuwe inzichten direct toegepast kunnen worden. Omdat je dit als product owner zelf moet kunnen beslissen is het belangrijk om genoeg mandaat te hebben binnen je organisatie. Wanneer je manager vereist dat story 1 bij de eerste sprint klaar is, maar uit alles blijkt dat dit niet slim is om te doen, dan heeft de rol als product owner weinig waarde. 

17# Houd rekening met het niet behalen van sprintdoelen 

Vrijwel alle stappen binnen het scrum framework zijn erop gericht om de sprintdoelen te behalen. Een goede voorbereiding, duidelijke user stories, een sprintplanning waarin alleen haalbare doelen worden opgenomen en daily’s om af te stemmen en tijdig obstakels te signaleren kunnen niet wegnemen dat externe factoren of onvoorziene problemen roet in het eten gooien. Als product owner is het zaak om in dit soort situaties snel te schakelen. Krijg inzichtelijk waardoor de doelen niet behaald kunnen worden, maak dit duidelijk aan de stakeholders en haal waar mogelijk obstakels uit de weg. 

Je kunt als product owner vooraf ook verschillende scenario’s klaarmaken zodat je in het geval van het niet behalen van een sprintdoel snel kunt schakelen. Neem bijvoorbeeld de ontwikkeling van een API-koppeling waarbij je applicatie data uitwisselt met een extern systeem. Deze koppelingen vormen altijd een zeker risico omdat meerdere partijen hun systemen op elkaar moeten afstemmen. Wanneer de API-ontwikkeling voor sprint 2 gepland staat, maar al snel blijkt dat de ontwikkeling niet snel genoeg gaat doordat een van de partijen niet of niet tijdig reageert, dan kun je als product owner de sprint  

18# Werk samen met de scrummaster om eventuele obstakels op te lossen. 

De scrummaster heeft als taak om het proces binnen een scrumproject zo soepel mogelijk te laten verlopen. Hij organiseert de scrumevents zoals de sprintplanning, daily’s, sprintreview en retrospective. Hij houdt de vinger aan de pols als het gaat om de progressie en het succesvol behalen van de sprintdoelen. Jij als product owner hebt baat bij een goede scrummaster en het loont om zo nu en dan even contact te hebben buiten alle officiële overleggen om. Hoe gaat het? Zijn er obstakels? Of mogelijke obstakels? Waar kun jij als product owner helpen? Bijvoorbeeld door externe expertise in te schakelen, specificaties bij te stellen of door alternatieven voor te stellen. Het is en blijft uiteindelijk een teameffort. Door samen met de scrummaster de plooien glad te strijken voor het developmentteam kan er meer worden gecreëerd, worden doelen behaald en krijg je een beter resultaat. 

Heb je vragen naar aanleiding van een van deze tips? Of heb je zelf een tip? Ik lees en beantwoord je reactie graag hieronder in het reactiegedeelte.