Items op waarde schatten
Het prioriteren van de Product Backlog* vormt een vast onderdeel van mijn takenpakket als Product Owner. Een uitdaging want het is van groot belang de waarde van items goed in te schatten. Ze moeten immers aansluiten bij de wensen vanuit de stakeholders. Om zo te blijven zorgen voor een hoge klanttevredenheid. Vandaar dat we het ontwikkelen van een nieuw product én het doorontwikkelen van een bestaand product altijd doen samen met klanten.
Realiseer je overigens dan wel dat iBurgerzaken eigenlijk bestaat uit heel veel verschillende producten of apps zoals we ze vaak noemen; iGeboorte, iHuwelijk, iVerblijf & Adres, iBegraafplaats etc. Daarom ben ik dan ook erg blij dat we deze prioritering samen doen! Hierbij betrekken we intern diverse collega’s, waar mogelijk externe partners en altijd specialisten bij gemeenten (gebruikers).
Extra aandacht voor een specifiek product
Om het prioriteren van de Product Backlog te vereenvoudigen heeft elke app een eigen dashboard waarop snel te zien is welke signalen er zoal zijn. Deze dashboards in combinatie met de vele klantgesprekken die we organisatie breed hebben en de klanttevredenheidsonderzoeken die we 2x per jaar uitvoeren zijn een goede graadmeter om de waarde nog beter in te kunnen schatten. Enerzijds per signaal en daarnaast ook per app.
Vervolgens nemen we regelmatig een app in Special Care; daarmee leggen we focus op het doorvoeren van structurele verbeteringen voor één product. Fijn voor de gebruikers want dat zorgt voor een flinke boost van dit product. Daarnaast is deze focus erg fijn voor de developmentteams. En wie mijn laatste blog “Regel het goed voor elkaar” heeft gelezen weet dat we na iVerblijf & Adres, iVerzoek, iNzicht Burgerzaken (voorheen iRapportage) en iOnderzoek nu gekozen hebben voor iBegraafplaats.
Nieuwsgierig naar deze dashboards? Stap voor stap gaan we ze ook met jullie delen via TOPdesk. Je kunt zelfs alvast de eerste sneakpreviews bekijken van de dashboards met marktsignalen van iBegraafplaats & iOnderzoek; inderdaad de apps die het meest recent in Special Care zaten. Daarin hebben we namelijk al extra tijd gestoken om het ook voor ‘de buitenwereld’ goed te beschrijven.
Prioriteren van geoormerkte marktsignalen
Vrijdag 8 mei organiseerden we de kwartiermakerssessie Special Care iBegraafplaats. Uiteraard deden we dat ditmaal online, via Teams. Hoewel even wennen voor alle betrokkenen bereikten we wel het gewenste resultaat. Na een korte kennismaking deelden we de verschillende procesflows met elkaar; een schematische weergave van alle processtappen die nodig zijn om een proces uit te voeren. In het geval van iBegraafplaats bespraken we dus 4 processen: begraven, aanvraag vergunning gedenkteken, verlengen/afstand graf én bijhouden rechthebbenden. Leuk en leerzaam, temeer omdat we hier en daar direct al een aantal verspillingen konden benoemen.
Daarna pakten we door naar de geoormerkte marktsignalen. Eerst bespraken we ze, simpelweg om zeker te weten dat iedereen hetzelfde beeld heeft bij elke wens. Vervolgens kreeg elke deelnemende gemeente de mogelijkheid om te stemmen; exact 55 punten toekennen aan diverse marktsignalen, dus cijfer 1 tot en met 10 neerzetten achter de geoormerkte marktsignalen, waarbij de 10 staat voor de meeste punten en dus de hoogste prioriteit.
Nieuwsgierig naar het resultaat? Onderstaande tabel is gesorteerd op de laatste kolom waarin het aantal punten wat een marktsignaal kreeg staat. (Voor de volledigheid: Er waren maximaal 60 punten per marktsignaal te vergeven.) Logischerwijs beginnen we dus met het ontwikkelen van het marktsignaal wat bovenaan staat in dit overzicht. Hoever we komen? Dat zal de tijd uitwijzen…
Binnenkort een eerste filmpje met nieuwe functionaliteiten
Om het plaatje compleet te maken: Als Product Owner heb ik de items opnieuw geprioriteerd op de Product Backlog. De stemmen zijn immers geteld en de prioriteit is duidelijk, nogmaals dank aan de kwartiermakers! Nu kan het developmentteam bepalen hoeveel van deze items zij oppakken in de Sprint; hoe groot zijn de verschillende items, welke expertises zijn hiervoor nodig en wat past binnen de capaciteit van het team – naast de andere ‘verplichtingen’? De items gaan dus van de Product Backlog naar de zogenaamde Sprint Backlog. En in dit geval ligt deze vraag voor aan 2 teams want Team Care en Team Core dragen hun steentje bij.
We verwachten de kwartiermakers dan ook snel een eerste filmpje te kunnen sturen met de nieuwontwikkelde functionaliteit; GAAS-67283 ‘Verlengen graf binnen het proces begraven toestaan’… En hopelijk wordt dat in deze release zelfs meer dan één filmpje? Uiteraard is het resultaat daarna ook zichtbaar in de releasenotes van iBurgerzaken release 3.6. Dus houd je oren en ogen open om binnenkort het resultaat van Special Care iBegraafplaats te kunnen bewonderen!
-------------------------
*) Voor de volledigheid een korte uitleg: De Product Backlog is een lijst met alle taken (items) die nodig zijn om tot het eindproduct te komen. Het is de enige bron van requirements voor veranderingen en vernieuwingen die worden toegepast op het product. In deze Product Backlog vind je features, functies, requirements, aanpassingen en fixes die gezamenlijk de wijzigingen vormen die in toekomstige releases van het product worden toegepast. Om items structuur te geven, worden ze vaak gegoten in de vorm van een User Story. Een User Story is een korte beschrijving (Story) van wat een eindgebruiker (User) wil. Zo staat erin wie de eindgebruiker is, wat deze wil en waarom.
