Lesprogramma
Deze week gaan we aan de slag met een groter probleem domein dan in de voorgaande weken. Een van de bijkomende problemen als het domein groter wordt (zoals in de week casus) is dat je niet meer alles tegelijk kunt oppakken/uitwerken. Dan wordt het belangrijk om werk te kunnen prioriteren, maar daarmee helpt DS (domain storytelling) ons niet zoveel verder. De techniek van DS helpt bij het vinden van de eisen en wensen en is met name behulpzaam bij gesprekken over requirements. Om de requirements die voortkomen uit de DS op te kunnen breken in kleinere brokken werk kijken we in deze les naar USM (User Story Mapping) als gestructureerde manier om requirements te specificeren, te ordenen en te prioriteren.
1. Backlog management met een User Story Mapâ
We bespreken het recept voor het komen tot een USM en de criteria aan een goede USM.
đ đ Lees het Gesprek over de koffieautomaat voor een voorbeeld hoe een USM ontstaat.
2. User Story Map - Backboneâ
2.1. Vinden van activiteitenâ
Klassikaal bespreken hoe de activiteiten die ondersteund zouden moeten worden door het bestelsysteem uit de restaurant casus af te leiden zijn uit de gegeven coarse-grained domain story "Restaurant bezoek zonder reservering" uit de casus beschrijving; zie <jouw repo>/documentatie/stap 0/casusbeschrijving.md
Wanneer een activiteit ondersteunt moet worden door een IT systeem, schrijf je hiervoor een kite-level requirement. Deze requirements (in de vorm van high-level user stories) vormen gezamenlijk de backbone van de User Story Map backlog.
2.2. Backbone opstellen User Story Mapâ
đ Maak in groepjes de backbone voor de User Story Map van het bestelsysteem uit de restaurant casus o.b.v. activiteiten uit onderdeel 2.1 en fine-grained domain stories uit de casus beschrijving; zie <jouw repo>/documentatie/stap 1/scenario.md
3. User Story Map - Ribsâ
Klassikaal bespreken van een mogelijke invulling van de ribs in de User Story Map o.b.v. fine-grained domain story en bijbehorende user stories uit de casus beschrijving; zie <jouw repo>/documentatie/stap 1/scenario.md
Check altijd voordat je een USM gaat vullen of de input (user stories) voldoet aan de INVEST criteria en scherp aan waar nodig.
â ī¸ User story vs Domain story
Het risico is dat je user story en domain story op ÊÊn hoop gooit, want beiden zijn manieren om requirements duidelijk te krijgen. Maar er zijn belangrijke verschillen. Het is een beetje als Java en JavaScript...
4. Prioriteren van het werkâ
We bespreken wat belangrijk is bij het prioriteren van werk in een USM.
Maak bij het inplannen van user stories in releases/iteraties continu de afweging tussen features die de meeste waarde opleveren voor de stakeholders en welke sturend zijn voor de oplossingsrichting.
5. User Story Map - Releasesâ
đ Geef in je groep invulling aan 3 releases en plaats de rest in een backlog op de User Story Map van het bestelsysteem voor de restaurant casus.
Geef bij user stories met een kleurtje aan of het core domain (groen) of wellicht supporting/generic domain (blauw) zou kunnen zijn als visuele indicator van impact op de prioritering.
Er kunnen afhankelijkheden zijn tussen user stories wat maakt dat deze in een bepaalde volgorde ingepland moeten worden, omdat deze anders niet voldoen aan INVEST.
đŖ Uitwerking
Aan het eind van de les bespreken we de USM van het bestelsysteem plenair en kan docent voorbeelduitwerking tonen/delen na de les.
Het is goed om te realiseren dat alles wat buiten het core domain te plaatsen is wellicht ook een bijbehorende rol speelt in de prioriteitstelling.
