Aan de slag met Open Badges en microcredentialing Proof of concept Foto: CC BY Girl Guides of Canada via Flickr 8 juni 2017

Wat gaan we doen vandaag? 10.00 Opening 10.05 Stand van zaken architectuur SURFnet 10.15 Wat is nodig om pilots tot een succes te maken? 11.15 Koffiepauze 11.30 MoSCoW 12.15 Lunch 12.30 Volgende stappen: pilots & naar het hoger liggende doel 13.00 Einde Voorstellen instellingen > bij punt 3.

Doel proof of concept SURFnet Doel van de PoC SURFnet Aantonen dat open badges in de HO praktijk toegepast kunnen worden en microcredentialing mogelijk kunnen maken (de keten inrichten en werkend krijgen). Op basis van de uitkomsten van de PoC zal SURFnet mogelijk een open badge dienst ontwikkelen voor het NL HO en op termijn dienstverlening hiervoor aan het HO aanbieden. Hogerliggend doel Met elkaar tot een standaard komen over hoe je badges waardeert (bestuurlijke borging van het bredere gebruik van microcredentialing).

Stand van zaken architectuur SURFnet 10.00 Opening 10.05 Stand van zaken architectuur SURFnet 10.15 Wat is nodig om pilots tot een succes te maken? 11.15 Koffiepauze 11.30 MoSCoW 12.15 Lunch 12.30 Volgende stappen: pilots & naar het hoger liggende doel 13.00 Einde Voorstellen instellingen > bij punt 3.

Stand van zaken SURFnet architectuur Update PoC omgeving: waar lopen wij tegenaan? Omgeving niet zo compleet als gewenst, overgestapt op een nieuwe versie. Contact Badgr op korte termijn volgt nieuwe omgeving met nieuwste code/ applicatie (die nog niet open source). Ongeveer in juni. ontwikkelingen zullen in stappen gaan, er volgen aantal updates. Nog geen roadmap ontvangen (nog niet). we werken nu met V0.5. De nieuwe omgeving gaat stap voor stap naar V2.0. (juni stap 1, dec laatste stap) Linked data, embedded critera, rich evidence Full support for import (alle 2.0 specs moeten geimporteerd kunnen worden, kunnen getoond worden in de backpack) Extra issuer options (onder een issuer, hangt een extra issuer) Federatieve login Endorsement (laat dec), blockcerts (hoe je met blockchain om kunt gaan). Nog te bepalen: Canvas koppeling

Pilots 10.00 Opening 10.05 Stand van zaken architectuur SURFnet 10.15 Wat is nodig om pilots tot een succes te maken? 11.15 Koffiepauze 11.30 MoSCoW 12.15 Lunch 12.30 Volgende stappen: pilots & naar het hoger liggende doel 13.00 Einde

MoSCoW analyse The MoSCoW method is a prioritization technique to reach a common understanding with stakeholders on the importance they place on the delivery of each requirement - also known as MoSCoW prioritization or MoSCoW analysis. The term MoSCoW itself is an acronym derived from the first letter of each of four prioritization categories (Must have, Should have, Could have, and Won't have), with the interstitial Os added to make the word pronounceable.

All requirements are important, but they are prioritized to deliver the greatest and most immediate business benefits early. Developers will initially try to deliver all the Must have, Should have and Could have requirements but the Should and Could requirements will be the first to be removed if the delivery timescale looks threatened. Must have Requirements labeled as Must have are critical to the current delivery timebox in order for it to be a success. If even one Must have requirement is not included, the project delivery should be considered a failure (note: requirements can be downgraded from Must have, by agreement with all relevant stakeholders; for example, when new requirements are deemed more important). MUST can also be considered an acronym for the Minimum Usable SubseT. Should have Requirements labeled as Should have are important but not necessary for delivery in the current delivery timebox. While 'Should have' requirements can be as important as 'Must have', they are often not as time-critical or there may be another way to satisfy the requirement, so that it can be held back until a future delivery timebox. Could have Requirements labeled as Could have are desirable but not necessary, and could improve user experience or customer satisfaction for little development cost. These will typically be included if time and resources permit. Won't have Requirements labeled as Won't have have been agreed by stakeholders as the least-critical, lowest-payback items, or not appropriate at that time. As a result, 'Won't have' requirements are not planned into the schedule for the delivery timebox. 'Won't have' requirements are either dropped or reconsidered for inclusion in later timeboxes. (Note: occasionally the term Would like is substituted for Won't have, though this is incorrect). MoSCoW analyse

Pilots - inventariseren wensen en eisen 10.15-10.25: 10 min per pilot wat ik wil met mijn pilot en wat mis ik in PoC omgeving? schrijf wensen en eisen op & plak op wand (nb: schrijf naam instelling erbij!) 10.25-11.15: toelichting per pilot (plakken op wand, 50 min) in 1 zin: wat wil je bereiken met de pilot licht wensen en eisen (issues/ requirements) toe. Nb: clusteren indien mogelijk, onderscheid SURFnet vs Instelling Einde: wand met requirements

MoSCoW 10.00 Opening 10.05 Stand van zaken architectuur SURFnet 10.15 Wat is nodig om pilots tot een succes te maken? 11.15 Koffiepauze 11.30 MoSCoW 12.15 Lunch 12.30 Volgende stappen: pilots & naar het hoger liggende doel 13.00 Einde

MoSCoW analyse 11.30-12.00 uur [30 min] per pilot Elke pilot krijgt 5 sticky notes in 3 kleuren (blauw, wit, roze). Elk team identificeert requirements: 1 Must have (blauw), 2 Should have (wit), 2 Could have (roze). Rest is ‘won’t have’. (nb: noteer naam instelling op sticky note!) 12.00-12.15 [15 min] plenair telling per cluster en verduidelijking (starten met Must have. Etc.) Einde: potentiele development agenda

Volgende stappen 10.00 Opening 10.05 Stand van zaken architectuur SURFnet 10.15 Wat is nodig om pilots tot een succes te maken? 11.15 Koffiepauze 11.30 MoSCoW 12.15 Lunch 12.30 Volgende stappen: pilots & naar het hoger liggende doel 13.00 Einde

Volgende stappen Pilots – hoe verder Naar het hoger liggende doel: Uitzoekwerk voor instellingen? Evt werkgroepen generieke onderwerpen of gewenste expertsessies? Waar kan SURFnet helpen? Naar het hoger liggende doel: ‘Met elkaar tot een standaard komen over hoe je badges waardeert (bestuurlijke borging van het bredere gebruik van microcredentialing)’ Waar moeten we consensus over bereiken? Kunnen we hier al stappen in maken? (sessie OWD – over badges algemeen of het hogerliggende doel? Wie kan bijdragen) Vervolgafspraken & communicatie

Communicatie Communicatie Edubadges@googlegroups.com Voortgang: via openbare wiki 1 x per maand korte update door alle partijen Tussentijds: via besloten discussiegroep. Uitnodiging volgt. Edubadges@googlegroups.com ‘Standby uur’: elke week in Jitsi kamer https://meet.surfcloud.nl/edubadges tps://meet.surfcloud.nl/edubadges

Het projectteam Open Badges Alexander Blanc: alexander.blanc@surfnet.nl Frans Ward: frans.ward@surfnet.nl Ronald Ham: ronald.ham@surfnet.nl Jenny de Werk: jenny.dewerk@surfnet.nl Wil je meedenken over de vervolgstappen? Laat het ons weten!