071 - 576 13 23
Sprintje trekken? Eerst even tot vijf tellen.

Sprintje trekken? Eerst even tot vijf tellen.

door Onno van der Heiden op 02 april 2016


Vijf vragen die je als scrum product owner altijd moet stellen.

De product owner is spin in het web

Als je websites ontwikkelt met de agile methode scrum, sprint je flexibel naar het beste resultaat. Binnen scrum heeft de product owner een belangrijke rol. Hij of zij is de spin in het web tussen stakeholders en het scrum team. De product owner weegt belangen af, prioriteert de activiteiten en stemt af met alle betrokkenen vanuit de klant. Als product owner wil je graag de dynamiek van het proces vasthouden, maar toch moet je soms even stilstaan om het probleem helder te krijgen. Vijf vragen om bij stil te staan als scrum product owner.

Wat is het probleem nu echt?

po1Een aanname is snel gemaakt, maar niet altijd juist. Daarom is het belangrijk om eerst door te vragen over het probleem voor je naar oplossingen gaat kijken. Voor wie is het een probleem? Waarom? Zijn er statistieken die wijzen op een probleem? Soms is het verleidelijk af te gaan op de beste argumenten van degenen met wie je op dat moment om de tafel zit. Toch is het belangrijk om het probleem vooral vanuit je gebruiker te bekijken. Zet een onderzoek naar het probleem op de backlog. Dan kun je op basis van de resultaten een userstory maken. Als je het probleem goed kent, dient de oplossing zich veel gemakkelijker aan. Dit kan even tijd kosten, maar dat is het waard. Als je te snel van start gaat, gooi je juist tijd én geld weg als blijkt dat je de verkeerde weg bent ingeslagen.

Wat zou je doen als de sky de limit was?

po2Welke oplossing zou je kiezen als alles mogelijk was? Verken de oplossing uitgebreid in een brainstorm. Welke ervaringen zijn er met dit type oplossing? Vraag dit vooral ook aan het scrum team. Hebben ze zoiets al eerder ontwikkeld voor een andere website of applicatie? Werkte het daar? Waarom wel of niet? Ook nu geldt, dat te snel gaan uiteindelijk misschien tegen je werkt. Kies niet meteen voor een quick fix. Een echt probleem verdient een echte, gedegen oplossing.

Is dit een tijdelijke oplossing of de definitieve?

po3Soms is het lastig om de definitieve oplossing direct te realiseren en moet er een tijdelijke oplossing komen. Bedenk dan wel wat daarvan de consequenties zijn. De snelle tijdelijke oplossing is misschien niet optimaal. Verwacht je daardoor bezoekers te verliezen? Wek je er verkeerde verwachtingen mee? En bedenk je ook wat het kost in tijd en geld om de tijdelijke oplossing op een later moment te vervangen. Door zulke afwegingen bewust te maken, kom je later niet voor onaangename verrassingen te staan.

Kan je organisatie deze oplossing aan?

po4Stel je wilt klanten de mogelijkheid geven om een proefproduct te ontvangen. Fijn voor de klant, toch? Een nieuwe functionaliteit in een website bouwen kan altijd. Maar bedenk goed welke impact dit heeft op het proces in je organisatie. Als klanten een proefproduct kunnen aanvragen, krijgt de backoffice hiermee een nieuwe taak. Kunnen ze dat aan? Als je nieuwe beloftes doet, moet je die wel waar kunnen maken. Anders is het bouwen van de functionaliteit zonde van de tijd en het geld. Wees dus voorzichtig met functionaliteiten die impact hebben op het proces in je organisatie.

Hoe kunnen we het effect van deze oplossing meten?

po5.pngGaat de oplossing die je bedacht hebt, werken zoals je wilt? Niet alles is te voorzien. Gelukkig zijn er veel mogelijkheden om online effectmetingen te doen. Stel bij twijfel bijvoorbeeld een A/B test op. Zo kun je twee verschillende versies naast elkaar uittesten bij echte gebruikers. Bepaal de KPI's van het probleem en zorg dat je deze ook daadwerkelijk goed kunt meten. Zo leer je meer over je gebruiker en kies je eerder de juiste oplossing.

Door als scrum product owner altijd deze vragen te stellen, sluit je veel risico’s uit. Want op de juiste momenten stil durven staan, is pas echt sprinten naar het beste resultaat.