Belangrijke taken van de product owner zijn onder meer het leveren van een goed product en het onderhoud met/van tevreden klanten.
Een goed product leveren is niet gelijk aan het hebben van een tevreden klant.
Soms kan een strategische user story bijdragen aan deze taken. Het gaat hierbij om een user story wat niet het beste lijkt voor het product, maar wat op een overzichtelijk termijn wel een beter product gaat opleveren, tegen relatief weinig kosten. De meerwaarde die wordt gecreëerd door het introduceren van een, in zekere mate, slechte user story is de kunst van de product owner.
Een voorbeeld uit mijn praktijk gaat over het weergeven van gegevens in een tabelvorm. Op papier werkt men in onze westerse wereld over het algemeen van links naar rechts. De meest recente gegevens staan dus rechts in de papieren tabel. In een digitale tabel – op een computer – is dat vaak andersom. De meest recente informatie staat altijd vooraan links in de tabel.
tabel en grafiek op papier
Wanneer een tabel in een grafiek vorm wordt weergegeven, wordt dit effect versterkt. Daar spreekt men van een trend. Als mensen jaren met een trend van links naar rechts hebben gewerkt, is het heel lastig om een grafiek opeens in spiegelbeeld te interpreteren. Dit kan in potentie een risico vormen.
Om toch de digitale vorm te gaan introduceren in een omgeving waar men papier gewend is, vereist niet alleen acceptatie van de moderne middelen, maar ook een andere denk- en werkwijze. Als product owner moet je in zo’n situatie relevante stakeholders gaan bewerken, boetseren, masseren en continue het doel voor ogen houden. Dit is een omslachtig, tijdrovend en soms ook vermoeiend proces. Helemaal als het om dit soort ‘nuances’ gaat.
Stop dan ook geen energie in user stories, indien je het strategisch heel makkelijk kan oplossen.
Formuleer de user story volgens het ‘oude’ principe, wat je zelf niet wilt, wat indruist tegen de roadmap van het product, wat niet strookt met het advies van interne domain experts, subject matter experts, business analisten en andere mensen die je altijd graag van dienst zijn. Luister dus vooral naar de stakeholders die veelal vallen onder de noemer: eindgebruiker. Zorg ervoor dat de user story met een hele goedkope ingreep om te draaien is, zodat het juist wél voldoet aan je gewenste verwachtingen.
Het goedkope aspect uit zich in een tweede user story, die je nog niet op de product backlog plaatst, maar in je achterhoofd houdt of nog liever, gewoon helemaal vergeet. Deze tweede user story gaat namelijk zich vanzelf aandienen tegen de tijd dat de belangrijkste stakeholder er klaar voor is. En als product owner probeer je je invloed uit te oefen om dat moment van klaar zijn te bespoedigen.
Zo lever je een goed werkend product op, met een tevreden klant, maar wat nog niet voldoet aan je eigen standaard. Zodra de eindgebruiker erachter komt dat het toch anders had moeten zijn, omdat een digitaal apparaat nou eenmaal een andere gebruikersbeleving, – user experience – biedt, komt die goedkope tweede (en eventueel derde, vierde, …) user story tevoorschijn.
In het voorbeeld van de tabel heb ik het team een tabel laten bouwen, waarin bij het tonen van de tabel als eerste de meest recente gegevens worden getoond. De gegevens worden van links naar rechts ingevuld. Indien de tabel niet binnen één scherm past, scrollt de tabel dus automatisch naar rechts, zodat de meeste recente gegevens in beeld zijn. Mocht de gebruiker dan oudere gegevens willen zien, zal hij terug moeten scrollen. Alles is nu door het team gebouwd en klaar om echt gebruikt te worden. Nog voordat het door acceptatie heen gaat, heeft de klant al beseft dat ze de tabel in deze vorm toch graag andersom zien. En daar komt mijn tweede user story: toon de gegevens niet van links naar rechts, maar andersom. En daardoor heb je ook de code van het automatisch afstellen van de view op de tabel op de meest recente gegevens niet meer nodig. Dit uit zich in relatief ontzettend weinig werk, inclusief documentatie aanpassen, screenshots aanpassen, code productierijp maken en alles wat erbij komt.
Deze refactor slag is voor mij als product owner vele malen goedkoper dan één of meerdere meetings te organiseren. Helemaal in de branche waar ik werk waarbij de eindgebruiker zo sporadisch de tijd heeft, dat hij voor een dergelijke user story zich over het algemeen niet eens beschikbaar opstelt.
Net als het vaak ‘nee’ verkopen, is het juist opnemen van user stories die je eigenlijk niet wilt, veel rendabeler dan je op het eerste gezicht denkt. Keerzijde is dat als je veel mensen hebt die je product backlog bekijken, je geregeld moet verantwoorden waarom je bepaalde user stories opneemt en op die wijze prioriseert. Een decision log kan daar eventueel bij helpen. En toch zal het gros van die mensen niet overtuigd zijn van je aanpak. Doorzetten! En pakt het niet uit? Het is nog steeds een goed werkend product en je hebt nog steeds een tevreden klant.
