Bronhouderportaal BRO sprintreview

Transcriptie

1 Bronhouderportaal BRO sprintreview Sprint 17 Meer info Verslag

2 Welkom vandaag Henk Ferkranus (SvB-BGT, coördinator regio Noord) GP Gooiker (ICTU, front-end-ontwikkelaar) Theo Gülcher (ICTU, softwareontwikkelaar) Jippe Holwerda (ICTU, softwareontwikkelaar) David de Jonge (Gemeente Amsterdam, coördinator BRO) Henk Koster (TNO, programmamanager BRO) Tom Moesker (ICTU, product owner en projectmanager) Anneke Spijker (Provincie Flevoland, coördinator ondergrond, IPO) Johan Stöver (ICTU, scrum master en softwareontwikkelaar) Henriëtte Villevoije (Rijkswaterstaat, coördinator ondergrond) Ria Volkers (Programmabureau BRO, ketenmanager) Rosan Wilgenburg (Gemeente Amsterdam, coördinator BRO)

3 Agenda 12.00u Inloop en welkom en lunch 12.15u Releasedoelen en voortgang 12.30u Terugblik afgelopen Sprint - Demonstratie opleveringen - Bespreking van het resultaat 13.15u Vooruitblik komende Sprint(s) - Prioriteiten bepalen -Uitwerking belangrijkste wensen 14.30u Afsluiting - Samenvatting conclusies & afspraken - Korte evaluatie van deze review Kalender di 06 mrt Sprintreview nr.18 di 27 mrt Sprintreview nr.19 di 17 apr Sprintreview nr.20 di 08 mei Sprintreview nr.21 di 29 mei Sprintreview nr.22 (laatste) 15.15u Ruimte voor nabesprekingen Tussendoor: korte koffiebreaks. Tijd 12-16u Locatie Amersfoort, Utrecht, Den Haag

4 1 DOELEN KOMENDE RELEASE DOOR DE PRODUCT OWNER

5 Voorlopige indeling Doelen Release 1.22 (voorheen: Release 4) Release 4 Algemeen doel Oplevering Basale invulling van alle nu nog openstaande wensen 1 juni 2018 (met tussenreleases in februari en april) week datum locatie sprintnr. hoofdsprintdoel (naast andere opleveringen) 04 di 23 jan Amersfoort #16 Aanleveren in bulk mogelijk maken 07 di 13 feb Utrecht #17 Meer informatie op het scherm 10 di 06 mrt #18 Tussenrelease 1.18: Bulk & Info 13 di 27 mrt #19 Nieuwe koppelingen 16 di 17 apr #20 Notificaties via de mail 19 di 08 mei #21 Tussenrelease 1.21: Koppelingen & notificaties 22 di 29 mei #22 Zoeken, rapporteren en archiveren 22 vr 01 jun Finale release 1.22: Finale oplevering Elke derde sprint gaat er een (tussen)release in productie

6 Doelen Release 1.22 Voorlopige indeling Nr. hoofdsprintdoel (naast andere opleveringen) Wat zit daar onder anderen in? #16 Aanleveren in bulk mogelijk maken Bulk upload én download #17 Meer informatie op het scherm Voorpagina, leveringshistorie, berichtenbanner, betere teksten #18 Tussenrelease: Bulk & Info Gerealiseerde verbeteringen in productie brengen #19 Nieuwe koppelingen Automatische koppelingen met (indien beschikbaar): de nieuwe syntax-validatieservice, een 1 e gegevensleverancier, AAT, grafische viewer. #20 Notificaties via de mail Validatie van mailadres, mailnotificatie bij uit te voeren taak en als termijn verloopt. #21 Tussenrelease: Koppelingen en notificaties Gerealiseerde verbeteringen in productie brengen #22 Zoeken, rapporteren en archiveren Zoeken naar, rapporteren over en archiveren van: organisaties, projecten, leveringen, bestanden, accounts, machtigingen en autorisaties.

7 Doelen Release 1.22 Wat kost de realisatie? In antwoord op en vraag in de evaluatie van de vorige sprintreview: Het is lastig om in te schatten wat je als gebruiker het beste prioriteit kunt geven. Dat hangt ook af van de kosten. Dus de vraag is: Wat kosten de nog resterende gebruikerswensen (user stories) om te realiseren? Alle nu bekende wensen zijn in de nog resterende vier maanden te realiseren. Maar eigenlijk is het de verkeerde vraag. Want vragen om een kostencalculatie veronderstelt een in detail uitgewerkte behoeftestelling en ontwerp. En die zijn er niet. We werken Agile en dat betekent dat we werkende software belangrijker vinden dan uitgebreide documentatie. Hoe werkt dat dan? Aan elke wens die prioriteit kreeg wordt eerst een basale invulling gegeven. De realisatie wordt zo klein en simpel mogelijk gehouden. Dan heb je snel resultaat en kun je sneller ervaren of de praktijk oplevert wat je er van verwachtte. Daar waar nodig wordt de nieuwe functionaliteit in stapsgewijs verbeterd en uitgebreid. Wat is dan wél de juiste vraag? De vraag die je zou moeten stellen: Welke wensen vinden we op dit moment het belangrijkst? Want die wensen realiseren we in de eerstkomende Sprint(s). Zo borg je dat de beperkte capaciteit altijd effectief wordt ingezet.

8 Doelen Release 1.22 Hoe kun je helpen? In antwoord op een vraag in de evaluatie van de vorige sprintreview: Wat kunnen we zelf doen om te helpen borgen dat alles op tijd af komt? Dat zijn in hoofdzaak drie dingen: 1. Maak de aan te koppelen systemen via internet beschikbaar Er is nu veel vraag naar koppelingen met omliggende systemen. Als dat belangrijk is, maak die systemen dan vandaag nog beschikbaar. Een via internet te benaderen testopstelling is voldoende. Voorstellen om koppelingen te bouwen met nog niet bestaande systemen parkeren we op de backlog. Ook dat is Agile. 2. Baseer verbeterwensen op de dagelijkse praktijk Vorig jaar moesten we vanaf Whiteboard en flip-over gaan bedenken wat er nodig was. Maar inmiddels is de applicatie zeven weken live. De statistieken laten zien dat alles écht werkt. In de praktijk zie je pas waar de échte knelpunten liggen. Ga daarom aan de slag met demo-omgeving. 3. Voorkom prioriteitswisselingen tijdens een lopende Sprint Een Sprint wordt in detail voorbereid. Eventuele spoedklussen doorbreken dit proces en zorgen voor wijzigingen waarvan de impact minder goed is doordacht. Meld wensen en bevindingen daarom tijdens de Sprintreview. Of meld ze aan de Product Owner via: Ze komen dan op de Backlog (zie verderop in deze presentatie). Daar blijven ze geparkeerd totdat: (1) duidelijk is wat de bedoeling is, (2) eventuele belemmeringen voor realisatie zijn weggenomen en (3) ze in een Sprintreview prioriteit hebben gekregen.

9 2 TERUGBLIK AFGELOPEN SPRINT DOOR HET ONTWIKKELTEAM

10 Bronhouderportaal in cijfers Sprint Peildatum 19 jan 13 feb 6 mrt 27 mrt 17 apr 8 mei 29 mei Maximum Aangemelde organisaties # gemeenten # waterschappen # provincies # andere bronhouderorganisaties 4 4 ±150 # organisaties die geen bronhouder zijn Actieve gebruikers # gebruikers met eherkenning # gebruikers met lokaal account Inrichting en gebruik - # projecten # autorisaties van gebruikers # machtigingen van bedrijven # leveringen gedaan # leveringen gelukt 0 1 -

11 Nieuwe functies In productie Mailadres als gebruikersnaam kunnen gebruiken voor lokale accounts Story: Als Administrator wil ik mailadressen van gebruikers als accountnaam kunnen gebruiken zodat gebruikers hun accountnaam beter onthouden en ik beter grip houd op wie precies de gebruikers zijn. Status: Dit is nu mogelijk. We spreken nu niet meer van Inlog met een lokaal account maar van Inloggen met je mailadres. Het is de tegenhanger van Inloggen met eherkenning. Inloggen met je mailadres is in de productieomgeving mogelijk voor medewerkers van bronhouderorganisaties. Beheerders van bronhouderorganisaties en medewerkers van leveranciersorganisaties dienen in de productieomgeving in te loggen met eherkenning Adres van de productieomgeving: -- Een aparte, volledig werkende demo-omgeving van het Bronhouderportaal Story: Als Gebruiker wil ik van het Bronhouderportaal een aparte versie zodat ik zelf kan oefenen, presenteren en testen zonder dat oefen-, demonstratie- en testbestanden per abuis in de basisregistratie terechtkomen. Status: Deze omgeving is sinds eind januari beschikbaar voor organisaties die zijn aangemeld bij de BRO en die direct of indirect bij de Sprintreviews betrokken zijn. De eerste gebruikers maken er al gebruik van, bijvoorbeeld voor demo s en voor praktijkproeven. De demo-omgeving ondersteunt niet het inloggen met eherkenning. In de Demoomgeving log je daarom altijd in met je mailadres. Een account kun je aanvragen bij: bronhouderportaal-bro@ictu.nl. -- Adres van de demo-omgeving: demo.bronhouderportaal-bro.nl -- N.B.: Om te onthouden: In de demo-omgeving logt iedereen in met zijn of haar mailadres. In de productieomgeving is deze mogelijkheid er alleen voor medewerkers van bronhouderorganisaties.

12 Nieuwe functies Ter acceptatie BBRO-414 Tonen leveringshistorie bij leveringsdetails Story: Als Product Owner wil ik op het scherm laten zien wie wanneer welke stap heeft uitgevoerd in de afhandeling van een levering zodat gebruikers zelf kunnen zien of deze informatie voor hen genoeg is zodat we eventueel ontbrekende informatie snel kunnen toevoegen nu de database nog vrij leeg is, want achteraf kan dat niet meer. BBRO-949 Op de startpagina verwijzen naar meer informatie Story: Als Ketenmanager voor de BRO wil ik contactgegevens van de BRO Servicedesk (mail en telefoon) en de link naar de BRO-website tonen op de startpagina van het Bronhouderportaal zodat gebruikers die niet weten wat ze met het Bronhouderportaal moeten doen sneller de weg naar informatie en ondersteuning vinden. BBRO-919 Asynchroon maken aanlevering in bulk Story: Als Bouwer wil ik bulkaanleveringen meer achter de schermen kunnen afhandelen zodat de applicatie minder afhankelijk is van wat een browser aankan en daardoor beter bestand is tegen zeer grote aanleveringen. BBRO-951 Een informatiebalk tonen in de applicatie Story: Als Administrator van de applicatie wil ik actuele meldingen op het scherm kunnen tonen zodat ik gebruikers kan waarschuwen voor naderend onderhoud of snel het antwoord kan delen op een veelgestelde vraag. BBRO-954 Mogelijkheid om testmails te versturen Story: Als Product Owner wil ik zien of mails uitsturen technisch al mogelijk zodat ik kan beginnen aan de vervolgstappen die nodig zijn om straks vanuit de applicatie mailnotificaties te kunnen gaan uitsturen.

13 Verbeteringen Ter acceptatie BBRO-946 Bronbestanden ongewijzigd naar de Landelijke Voorziening sturen Door een misverstand over de beoogde werking die nog dateert uit de beginperiode van de applicatie werd niet het oorspronkelijk aangeleverde bestand doorgestuurd, maar werd het door het Bronhouderportaal uitgepakte bestand weer opnieuw ingepakt en verstuurd. Daardoor kunnen (kleine) technische verschillen ontstaan ten opzichte het origineel. Dat is een fout: De afspraak is om het origineel wel uit te lezen maar niet aan te passen. Dit is hersteld. BBRO-1000 Zipbestanden aanleveren werkend maken in Windows 10 Een niet werkende afhandeling van zipbestanden in Windows 10 is hersteld door metagegevens die Windows 10 meelevert aan de browser beter door het Bronhouderportaal te laten accepteren. Herstel van kleine testbevindingen, specifiek voor Beheerders en Bronhouders in bronhouderorganisaties: Zogeheten systeemrollen die je niet hoeft te zien worden ook niet meer getoond. Het is niet meer mogelijk om als Beheerder zelf (per ongeluk) je eigen beheerrechten te verwijderen. De benaming van de verschillende rollen is verbeterd zodat je sneller snapt welke rol je iemand moet geven. Herstel van kleine testbevindingen voor alle gebruikers: Allerlei lijsten door de applicatie heen worden - nu ze steeds langer worden - netjes alfabetisch gesorteerd. Verstoringen in de webpagina bij het tonen van extreem lange organisatienamen wordt nu afgevangen. Enkele fouten in de styling c.q. de naleving van de Rijkshuisstijl zijn hersteld. Enkele spelfouten zijn verwijderd. N.B.: De acceptatietest loopt nog. Zie je iets vreemds? Meld het bij bronhouderportaal-bro@ictu.nl. Bij voorkeur met een screenshot en vermelding datum, tijd en gebruikte browser.

14 Nieuwe functies en verbeteringen Verdaagd BBRO-953 Aanmaken en tonen van deelprojecten Story: Als Bronhouder wil ik een hiërarchie met deelprojecten kunnen opzetten zodat ik projecten kan groeperen per afdeling of per hoofdproject. Status: Deze wens is besproken en vooralsnog teruggeplaatst op de backlog. Want de meerwaarde is nog niet helder. In de demo-omgeving wordt nu eerst getoetst of de huidige functionaliteit hiervoor voldoet of dat er écht wat mist. BBRO-961 Handleiding bijwerken Story: De handleiding moet in lijn zijn met de nieuwe versie in de applicatie. Status: Verdaagd naar de volgende Sprint, dit in afwachting van het opleveren en accepteren van de laatste verbeteringen zodat in de Handleiding de juiste schermvoorbeelden kunnen worden opgenomen.

15

16 Reacties op de demo Waarom is de asynchrone afhandeling van bulkaanlevering nodig? 1. Dat is om te voorkomen dat de browser een foutmelding gaat geven als die bij afhandeling van een groot aantal bestanden op de server té lang moet wachten. Dat dit op een gegeven moment gebeurt werd al eens gedemonstreerd. 2. Om robuust te zijn tegen verstoringen; Het proces werkt straks zo dat afhandeling na onderbreking automatisch verder gaat als de applicatie na storing weer in bedrijf komt. 3. Dezelfde techniek is de basis om straks ook de doorlevering van grote aantallen bestanden aan LV BRO robuuster te maken tegen eventuele storingen in de verbinding. Hetzelfde geldt later ook voor eventuele andere koppelingen, als die erbij komen. Waarom willen we de doorlooptijden zien in de uitgevoerde stappen bij de afwikkeling van een levering? 1. Voor inzicht. En om een basis te leggen voor de bewaking van leveringstermijnen. 2. Om statistieken te kunnen maken over gemiddelde doorlooptijden (totaal of per stap). 3. Om harde cijfers te hebben bij een melding van een gebruiker van traagheid van het systeem, bij handelingen die door de applicatie op de achtergrond automatisch zijn uitgevoerd.

17 4 BACKLOG SORTEREN ALLEN

18 Prio 1. Gewenst en uitvoerbaar 1. Herstel van nog openstaande kleine bevindingen Story: Als Tester wil ik graag eerder gemelde kleine bevindingen zoveel mogelijk opgelost hebben zodat ik ze bij de volgende testronde niet opnieuw tegenkom en opnieuw moet melden. 2. Toelichting kunnen opvoeren bij elke processtap (in plaats van alleen bij aanlevering zoals nu het geval is) Story: Als gebruiker wil ik bij elke stap in de afwikkeling van een levering een toelichtingstekst kunnen toevoegen zodat ik voor mezelf en andere gebruikers relevante opmerkingen kan vastleggen. 3. Doorlooptijden tonen per processtap in de levering Story: Als Product Owner wil ik per stap in de afwikkeling van een levering de doorlooptijd vastleggen en tonen zodat (1) Gebruikers feedback krijgen over knelpunten in de afwikkeling, (2) vermeende traagheid bij automatische processtappen met cijfers is aan te tonen en (3) een basis is gelegd voor het genereren van doorlooptijd-statistieken voor maandrapportages. 4. Bewijs van levering kunnen printen Story: Als Leverancier wil ik van leveringsdetails die ik op het scherm zie vanuit mijn browser een goed leesbare print kunnen maken (in pdf of op papier) zodat ik die buiten het Bronhouderportaal om kan gebruiken als bewijs van geleverd werk. Besluit: Deze wenst krijgt extra prioriteit en een eerste basale implementatie moet zeker mee in de komende release. 5. Verschillende instanties van de applicatie beter van elkaar kunnen onderscheiden Story: Als Tester en als Bouwer wil ik direct kunnen zien in welke omgeving ik werk (in Acceptatie, Demonstratie of Productie) zodat er geen misverstanden ontstaan over op welke instantie mijn testbevinding betrekking op heeft. Doorleveren aan LV BRO robuust maken tegen verstoringen Story: Als Bouwer wil ik de afhandeling van doorleveringen naar LV BRO robuust maken tegen verstoringen zodat een doorlevering na verloop van tijd altijd lukt, ook al ligt de verbinding er tussentijds tijdelijk uit. 6. Mailadres valideren via mailnotificatie met validatiecode (testopstelling) Story: Als Product Owner wil ik dat gebruikers zelf hun mailadres kunnen valideren via een code die ze in hun mailbox ontvangen zodat de basis is gelegd voor het inrichten van notificaties die Gebruikers via de mail wensen te ontvangen. 7. Oplevering van een tussenrelease van de applicatie (De zogeheten: Bulk & Info-release) Story: Als Gebruiker wil ik kunnen beschikken over de nieuwste versie van het Bronhouderportaal met releasenotes en handleiding zodat ik niet tot eind mei hoef te wachten voor ik de verbeteringen en uitbreidingen kan gebruiken.

19 Prio 2. Gewenst zodra realiseerbaar De volgende wensen betreffen gewenste automatische koppelingen met andere systemen. Deze koppelingen hebben prioriteit, maar zijn pas realiseerbaar als de te koppelen systemen ook beschikbaar zijn om mee te testen: Extra prioriteit omdat ze generiek zijn: 1. Aansluiten op een IMBRO/XML-syntaxvalidatieservice (in testopstelling) Story: Als BRO Ketenmanager wil ik dat het Bronhouderportaal de syntax van aangeleverde bestanden bij een gemeenschappelijke validatieservice valideert (en niet in de applicatie zelf zoals nu het geval is) zodat (1) er geen verschillende uitkomsten kunnen zijn bij validaties door de verschillende schakels in de BRO-keten en (2) er minder ingrijpende aanpassingen nodig zijn in het Bronhouderportaal als er nieuwe registratieobjecten worden toegevoegd. 2. Geautomatiseerd GMW-bestanden kunnen aanleveren (in testopstelling) Story: Als Leverancier wil ik vanuit mijn eigen softwaresysteem geautomatiseerd GMW-registraties, mutaties en correcties kunnen aanleveren aan het Bronhouderportaal (in plaats van handmatig via uploads zoals nu het geval is) zodat dit proces voor mij efficiënter wordt voor soorten leveringen die ik heel vaak moet doen. Alleen prioriteit als er generieke oplossingen worden aangedragen: 1. Koppeling met AAT (in testopstelling) Story: Als Grote Bronhouderorganisatie wil ik een koppeling hebben met mijn geautomatiseerde kwaliteitscontrolesysteem zodat ik en deel van de kwaliteitscontrole kan automatiseren zodat mijn specialisten er minder werk van hebben. 2. Koppeling met een grafische viewer (in testopstelling) Story: Als Kwaliteitscontroleur wil ik een koppeling hebben met mijn viewer waarin ik de inhoud van IMBRO/XML-bestanden die ik moet controleren grafisch kan weergeven zodat ik in staat ben om mijn werk te doen. Besluit: Aan wie deze viewer wil het verzoek om met Ria in contact te treden om te bepalen wat er nodig is.

20 Prio 3.Te verhelpen zodra uitvoerbaar De volgende verzoeken zijn voor realisatie uitgezet bij de hostingprovider: 1. Onterechte foutmeldingen bij inloggen voorkomen Bevinding: Als Gebruiker wil ik af zijn van cryptische en onterechte foutmeldingen die ik af en toe krijg bij het inloggen zodat ik me daaraan niet meer hoef te ergeren. 2. Inlogpagina logischer indelen Bevinding : Als Gebruiker wil ik de inlogpagina logischer van opzet met alleen relevante informatie bevat zodat ik minder fouten maak tijdens het inloggen en minder vaak mijn account hoef te laten deblokkeren na teveel mislukte inlogpogingen. Besluit: Herstel van deze bevinding krijgt prioriteit voor omdat veel gebruikers hier verkeerd inloggen. 3. Performancemonitoring aanzetten Bevinding : Als Administrator wil ik de prestaties van de applicatie kunnen volgen zodat ik overbelasting tijdig zie aankomen en maandelijks objectieve cijfers kan rapporteren over de beschikbaarheid van de applicatie binnen en buiten kantooruren. 4. Zelf je wachtwoord kunnen wijzigen Bevinding : Als Administrator wil ik dat een Gebruiker die inlogt met mailadres zelf het wachtwoord kan (en periodiek moet) wijzigen zodat ik kan voldoen aan de informatiebeveiligingsrichtlijn van de overheid. 5. Zelf je wachtwoord kunnen resetten Bevinding : Als Gebruiker die inlogt met mailadres wil ik zelf op een veilige manier mijn wachtwoord kunnen resetten zonder tussenkomst van de Servicedesk zodat ik niet dagen op mijn nieuwe wachtwoord hoef te wachten als ik het vergeten was. 6. Eigen maildomein inrichten voor mailnotificaties Bevinding : Als Administrator wil ik gebruik kunnen maken van (in plaats van een generiek mailadres van de hostingprovider zoals nu het geval is) zodat de Gebruiker die mailnotificaties ontvangt sneller snapt wie de afzender is en ik meer grip heb in het voorkomen dat mailnotificaties bij de Gebruiker in de spambox komen.

21 Prio 4. Nog nader te prioriteren De volgende zaken worden regelmatig genoemd, maar zijn nog nader te specificeren en/of te prioriteren: 1. De status Ingenomen door LV BRO graag corrigeren zodat je direct ziet of die tot goed- of afkeuring heeft geleid. 2. Als Coördinator alle projecten, leveringen en bestanden van de eigen bronhouderorganisatie kunnen inzien. 3. Controleren op dubbele bronbestanden zodat ze niet dubbel in de LV BRO terechtkomen. 4. Archivering van organisaties, projecten, leveringen, accounts en bestanden als ze niet meer actueel zijn. 5. Rapportage over organisaties, projecten, leveringen, accounts en bestanden per organisatie en per periode. 6. Een zoekfunctie voor het terugvinden van organisaties, projecten, leveringen, accounts, bestanden en BRO-IDs. 7. Mailnotificatie ontvangen zodat je weet dat er een nieuwe taak voor je klaar staat. 8. Mailnotificatie ontvangen als de afhandelingstermijn voor een taak dreigt te verstrijken. 9. Mailnotificatievoorkeuren kunnen instellen per account en per project. 10.BHR-p brondocumenten kunnen verwerken zodat ook die via het portaal naar LV BRO kunnen gaan. 11.Brondocumenten van registratieobjecten uit komende tranches kunnen verwerken. 12.Deelprojecten kunnen aanmaken zodat een hiërarchie kunt aanbrengen in de weergave en in het rechtenbeheer. 13.In een project kunnen instellen dat goedkeuren en/of accorderen van leveringen automatisch mag gebeuren. 14.Statusinformatie over een project op de projectbalk afbeelden zodat je daarvoor het project niet hoeft te openen. 15.Bij aanlevering een referentiecode van de eigen administratie kunnen opvoeren om de link daarmee te bewaren. 16.Beter onderscheid maken tussen de keuze Afkeuren bij Controleren en Afkeuren bij de stap Accorderen. 17.In het leveringsoverzicht tonen wie er geacht wordt de volgende stap in de afhandeling te doen. 18.In het leveringsoverzicht statusinformatie ook grafisch weergeven zodat je sneller ziet wat de status is. 19.Alle leveringen in een project in één keer kunnen downloaden. 20.Nieuw: Anoniem gebruik ondersteunen om bestanden via het Bronhouderportaal te kunnen laten valideren.

22 5 AFSLUITING

23 Besluiten en actiepunten 1. Datum komende tussenrelease: vrijdag 23 februari of de week daarna (noot: het is vrijdag 2 maart geworden). De gebruikers krijgen vooraf bericht. 2. Te accepteren opleveringen: Deelnemers wordt gevraagd de Demo-omgeving uit te proberen en bevindingen te verzamelen. Het concept voor de nieuwe Startpagina met helpinformatie en links wordt gedeeld met BRO Servicedesk en deelnemers van de Sprintreview met het verzoek verbetervoorstellen terug te sturen. 3. Te realiseren wensen in de komende sprint 18 en op te nemen in de eerstkomende release (2 maart): Sheet Gewenste en direct realiseerbare wensen. Het printbaar maken van leveringsdetails krijgt de komende sprint extra prioriteit. 4. Prioriteiten voor de komende sprints tot de volgende volgende release (13 april): Sheet Gewenst zodra uitvoerbaar. ICTU treedt hierover in contact met de behoeftestellers. Zodra een testopstelling maakbaar is wordt een demonstratie ingepland voor in een volgende Sprintreview. Sheet Te verhelpen zodra uitvoerbaar De vervanging van de huidige onlogische inlogpagina krijgt daarbij extra prioriteit. Sheet Nader te prioriteren wensen (de top-20) worden rondg d zodat ieder voor zich de prioriteiten kan aangeven. Ze worden dan opgepakt in volgorde van prioriteit. 5. Locaties voor de komende sprintreviews De komende sprint zijn we te gast bij TNO in Utrecht. De sprint daarna zijn we in Den Haag (ICTU of BZK).

24 Evaluatie Wat ging goed? IIII Tevreden over deze sessie. II Reviews beginnen op elkaar te lijken: Er zijn geen verrassingen meer, een groot verschil in vergelijking tot de eerste sprints. II Complimenten vanuit Groningen en omgeving! I We hebben vandaag efficiënt vergaderd. I Wederom goeie sfeer, goeie discussie. I Handen jeuken om aan de sprint te beginnen. Wat kan beter? III Een onzekere factor blijft veel partijen nog I niet zijn aangehaakt, maar die zullen nog komen en wat zullen hun wensen zijn? Deeldiscussies zijn verstorend, houdt het plenair alsjeblieft.