Product backlog management is één van mijn verantwoordelijkheden als Product Owner van team Newton. Hieronder vertel ik je meer over wat dat is. Verder neem ik je mee in de iBurgerzaken release 4.6. De teams lichten tekstueel allemaal een item binnen de release uit, de afbeelding laat zien waar verder nog aan gewerkt wordt.
De product backlog is een geordende lijst met dat wat nodig is om een product (in ons geval iBurgerzaken) uit te breiden. Deze lijst bevat datgene wat voorgesorteerd staat om binnen 3-6 maanden op te pakken door een ontwikkelteam. Het is de enige bron van werk dat door een ontwikkelteam wordt gedaan waarbij de inhoud en ordening continu aan verandering onderhevig is.
De product backlog bevat onder andere marktsignalen, te analyseren incidenten, op te lossen bugs, te implementeren niet-functionele verbeteringen, te organiseren kwartiermakersessies en uit te voeren onderzoeken voor complexe nieuwe functionaliteiten. Hoe houd je dit allemaal op orde en doe je de juiste dingen op het juiste moment? Daar komt ‘product backlog management’ bij kijken. Eén van de verantwoordelijkheden van een Product Owner. Maar dat de Product Owner hier verantwoordelijk voor is, betekent niet dat de Product Owner dit in zijn of haar eentje doet. Eigenlijk draagt iedereen hier (in)direct een steentje aan bij. In mijn volgende blog zal ik daar wat voorbeelden van geven.
Lees hieronder waar de 3 teams momenteel hard aan werken.
Sinds een maand of twee heeft team Newton een nieuwe app onder de vleugel: iVerblijfsobject. Deze app heeft afgelopen najaar zowel in een losse webinar als in de GV najaarsoverleggen veel aandacht gekregen. En natuurlijk willen we dat de al meer dan 100 gemeenten die met iVerblijfsobject aan de slag gaan, zo goed mogelijk gebruik gaan maken van deze nieuwe app.
Daarom besteden we in deze release onder andere tijd aan het beter ondersteunen van meerdere BAG-gebeurtenissen onder één documentnummer. Iets wat in de praktijk regelmatig voorkomt. Door iVerblijfsobject steeds meer uit te breiden met automatische analyses en afhandelingen blijft er steeds minder handmatig werk over. Waardoor je voor de overige analyses meer tijd overhoudt. Bovendien komt het de kwaliteit van de BRP ten goede.
‘Wij doen de pitch, maak jij de switch", is een onderwerp waar we onder andere tijdens de GV najaarsoverleggen dieper op in zijn gegaan. Het omvat alle acties die jouw gemeente kan ondernemen om over te stappen van de oude werkwijze (Cipers) naar de nieuwe werkwijze (iBurgerzaken). Een van die acties is (meer) gebruik maken van de app iBijhouding. Het zorgt voor meer overzicht, wijzigingen zijn makkelijker aan te brengen en de kwaliteit kun je vooraf controleren. Er is natuurlijk altijd ruimte voor verbetering, want één van de opmerkingen over iBijhouding tijdens de overleggen was dat het registreren van een huwelijk of geregistreerd partnerschap in de BRP met iBijhouding omslachtig is. Het 2x uitvoeren, voor iedere partner apart, draagt daar niet aan bij...
Reden genoeg voor ons om aan de slag te gaan, zodat het eenvoudiger is om een huwelijk of geregistreerd partnerschap te registeren in de BRP. We hebben daarom op aanraden van de kwartiermakers gekozen voor een apart proces genaamd 'Registreren huwelijk'. Door een los proces te maken zijn de gegevens die je moet invullen en de controles, specifiek voor het registeren van een huwelijk of geregistreerd partnerschap. Bovendien verwerk je categorie 05 voor beide partners in één keer in de BRP.
Weer een extra reden om iBijhouding te gebruiken! aldus Frank van Baren, Product Owner van team Bonaparte.
Met de ontwikkelingen en innovaties binnen OPENburgerzaken zet Team Galileo altijd een stap vooruit. Dit team werkt momenteel hard aan ontwikkelingen op het gebied van ‘notificering bij een levensgebeurtenis in de keten’. Een voorbeeld: Bij het registreren van een geboorte blijkt dat de vader in een andere gemeente staat ingeschreven. Op dit moment zal de ene gemeente de andere gemeente handmatig (bijvoorbeeld via een formulier of vrij bericht) informeren. Het kind dient namelijk ook op de persoonslijst van de vader te worden opgenomen. Met behulp van het systeem van notificeren wordt dit geautomatiseerd. Er wordt een notificatie verzonden aan de gemeente waar de vader is ingeschreven. Bij ontvangst van deze notificatie wordt vervolgens direct een zaak gestart waardoor de gegevens van het kind worden bijgeschreven bij de vader.
Het creëren van een fundament om deze gebeurtenissen en data ordelijk vast te kunnen leggen is een onderdeel van de huidige werkzaamheden van het team. Deze basis wordt momenteel door het team gelegd. En met behulp van API-management, wat ook een belangrijke pijler is binnen de werkzaamheden, wordt ervoor gezorgd dat de benodigde data (zoals de gegevens van het kind in het voorbeeld) op een verantwoorde en vooral veilige manier bij de andere gemeente terecht komt.
"We kijken in deze werkzaamheden naar bestaande componenten voor notificeren van VNG Realisatie en sluiten niet uit dat we mogelijk een Common Ground component gaan ontwikkelen!", zegt Dylan Kusters, Innovatiemanager en Product Owner van team Galileo.
P.S. Check ook eens deze blog van onze collega, leuk om te zien dat we hier vanuit meerdere businessunits op inzetten, toch?
Wil jij het optimale uit de iBurgerzaken release halen? Haak dan eens aan op een online iRelease sessie. Je neemt samen met een consultant de nieuwe iBurgerzaken release uitgebreid door. Acties voer je onder begeleiding van onze consultant vervolgens direct door binnen jouw eigen iBurgerzaken systeem. Meer info en data vind je hier.
Ik hoor het graag van je! Neem ook gerust contact met mij op als je vragen hebt over mijn blog. Ik ben te bereiken via: Michelle.Meekes@PinkRoccade.nl
