Workshop User Story mapping

Deze workshop leer je eindopdracht kennen, maar leert ook de User Story Mapping (USM) techniek kennen. Je past deze toe voor de opdracht komende twee weken. Deze techniek gebruik je ook in het eindproject om (meer) structuur aan te brengen

User Stories: Falling leaves?

Figuur 1: De oorspronkelijke analogie van van Jeff Patton de grondlegger van USM (Patton, 2008)

Voorbereiding

  1. Lees het verhaal over User Story Mapping en kijk de video van 6 minuten van Atalassian op de website van de Open Practice Library ().
  2. Kies een van onderstaande mogelijke 'Functionele uitbreidingen van PitStop' op, of verzin of genereer er zelf
  3. Verzin voor deze casus zes (6) user stories in de standaard vorm Als <gebruikersrol> wil ik <functionaliteit> zodat ik <businesswaarde>. Hierbij:
  • a. Minstens drie verschillende gebruikers(rollen) of persona's.
  • b. Zoek op wat een persona is in Agile (bijvoorbeeld op Wikipedia of interaction-design.org).
  • c. Zorg dat je user stories uniek zijn, anders dan die van je klasgenoten.
  • d. Post je 6 user stories in Slack (eindopdracht-kanaal).
  • e. Na het posten van unieke user stories kun je een casus claimen voor je groep. Overleg met je team; bij discussie beslist de docent.

NB: Het is geen gegeven dat je zelf ingediende/bedachte user stories ook mag implementeren, dit gaat in overleg met team, en hier houdt de docent veto recht.

Lesinhoud

  • Maak een aantekeningen/tekening (concept map)
  • The 8 Fallacies
  • Intro User Story Map
  • Lesopdracht: Maak met je team een user Story map van je eigen casus/user stories

Een 'Concept map' van 'User Story Map'

Opdracht studenten: Maak n.a.v. lesinhoud vandaag een concept map van User Story Mapping

Relevante termen voor deze concept map zijn o.a.:

  • Value slices, prioritering
  • User story map, backbone
  • User stories, acceptatiecriteria en backlog/code management tool

Einde les maakt de docent een foto hiervan.

User Story Map

User Stories: Falling leaves?

Figuur 2: User Story map, leeg template van miro.com

Doel van de les is een goed beeld te hebben wat een User Story Map is en waar dit voor dient, en hoe je er een kunt maken voor een concrete business case (of functionele uitbreiding). Als Figuur 2 een plaatje van een USM stond hoef je zelf geen beeld meer te maken. Dit is een leeg template van op Miro, een mooie tool.

De richtlijnen op Open Practice Library geven aan minstens 3 sprints te maken. Ook de term 'MVP' in het template is belangrijk. Dit is een soort abstract 'sprintdoel'. Maar in true 'DDD practice' moet je hier in je eigen template een concrete invulling voor maken in de 'Ubiquitous language' die je deelt/gaat delen met business experts. In plaats van hen uit te leggen wat een 'MVP' is. Want dat moeten zij uiteindelijk zelf beoordelen: wat is 'viable' in hun business? Wat levert waarde op? Wel kun je eens nadenken over varianten op MVP als 'Minimally Marketable Product' (MMP) en 'Minimal Loveable Product' (MLP).

Lesvraag: Is er een vaste volgorde in het maken van MVP, MMP en MLP? Minimally Viable Product, Marketable Product en Lovable Product!?

Intro over 'Fallacies' in algemeen

Ter overpeinzing/bespreking:

“The trouble with the world is not that we know so little. It’s that we know so much, that just ain’t so.” - Mark Twain (or is it.. ;)

  • Toetsvraag fallacies of distributed computing bespreken/bekijken
    • Dit was een tricky vraag. Waarom is het nuttig te denken in termen van 'fallacies'?
  • Terzijde: Toetsvraag over Autonomy over authority bekijken
    • Wat betekent hierin het (Engelse) woord over?
    • Is authority hier op meta niveau, over development team, of basisniveau, de microservice zelf? Snap je het onderscheid?

The 8 Fallacies of User stories

Hier zijn 3 fallacies. Verzin met de klas er nog 5. Bekijk de lijst die de docent toont.

Invest principes

Een beetje het tegenovergestelde van deze zelf bedacht 8 fallacies is het INVEST principe van Bill Wake (Wikipedia, 2024). Deze geldt voor PBI's, maar User stories is daar een vorm van. Deze moet je hanteren in het project bij het maken van sprint planningen, of bij het nadenken van value slices in je User Story Map. Hieronder de korte definitie van Wikipedia, maar het artikel van Philip Rogers op logrocket.com is wat toegankelijker met plaatjes en meer toelichting (2018).

"..the characteristics of a good quality Product Backlog Item (commonly written in user story format, but not required to be) or PBI for short. Such PBIs may be used in a Scrum backlog, Kanban board or XP project."

LetterMeaningDescription
IIndependentThe PBI should be self-contained.
NNegotiablePBIs are not explicit contracts and should leave space for discussion.
VValuableA PBI must deliver value to the stakeholders.
EEstimableYou must always be able to estimate the size of a PBI.
SSmallPBIs should not be so big as to become impossible to plan/task/prioritize within a level of accuracy.
TTestableThe PBI or its related description must provide the necessary information to make test development possible.

Agile: GEEN WaterScrumFall

Agile wordt wel eens foutief aangegrepen als excuus om 'gewoon aan de slag te gaan' zonder verder te plannen of na te denken. Het is belangrijk om aan de slag te gaan en niet verstrikt te raken in 'analysis paralysis'. Maar met een beetje nadenken vantevoren kun je vaak veel verspilde tijd later voorkomen. En nadenken over een Road map voor je product samen met opdrachtgever en andere stakeholders. Dit kan in de vorm van een User Story Map. Hiermee zet je ook wat 'sprint goals' uit voor de 1e paar Sprints. Dit Requirements Engineering' stukje kun je ook iteratief aanpakken, in plaats van waterfall. Zodat je niet in de val trapt van 'WaterScrumFall' zoals Jez Humble het noemt:

"After witnessing a handful of Agile transformations, oftentimes the system of Waterfall isn’t entirely replaced by Agile, merely paved over. The DevOps group might have embraced it, but the rest of the business is still operating in a “Non-Agile”, project-that-starts-and-ends, style." - Steven Prutzman (2023)

C4 grondlegger Simon Brown predikt 'Just enough upfront design'

Figuur 2: Simon Brown predikt 'Just enough upfront design' (YouTube/Brown, 2022)

Naast Humble's WaterScrumfall concept benadrukt ook C4 creator ook Simon Brown's praatje 'The lost Art of Software Architecture' hoe enige INVESTering zich kan uitbetalen in tijdsbesparing later. Dit is zeker een kijktip! Je software architectuur uitdenken met het C4 model is hier een vorm van. Maar aan de domein-/functionele kant is User Story Mapping hier een goede vorm voor.'

Quiz

Test je kennis met deze korte multiple choice quiz.

Leerdoelen

Check met onderstaande leerdoelen of je de stof beheerst en User Story mapping en gerelateerde kennis in de vingers hebt.

  • Je kunt uitleggen wat User Story Mapping (USM) is en waarom het belangrijk is voor projectplanning.
  • Je kunt beschrijven hoe USM helpt bij het prioriteren van user stories in DevOps projecten.
  • Je kunt het INVEST-principe uitleggen en toepassen op het maken van sterke user stories.
  • Je begrijpt wat fallacies zijn (algemene misvattingen) en kunt misvattingen in user stories herkennen als ze worden gegeven.
  • Je kunt het verschil uitleggen tussen user stories en andere Product Backlog Items (PBI’s), zoals taken, bugs en epics.
  • Je kunt een backbone en value slices beschrijven in een User Story Map.

Casussen Uitbreiding Pitstop

Kies een van onderstaande casussen of maak er zelf een.

Casus 1. Klant 'in the loop'

Customer 'in the loop' - Stemmingsplaatje

Notificatie systeem naar gebruikers dat reparatie gestart is, of reparatie klaar, of evt. input tussentijds nodig is Image(goedkeuren reparatie a.d.h.v. kosten) (huidige notificatie systeem in het systeem is alleen naar klanten dat een onderhoudsbeurt nodig is).

Doel is vooral de response tijd van klanten te verkleinen, wachttijden verkleinen voor efficiënter gebruik van garage werkplaatsen.

Casus 2. Leenauto’s: geluk bij een ongeluk

Leenauto's - Stemmingsplaatje

Klanten kunnen tijdens reparatie ook een leenauto krijgen. Hiertoe moeten zij digitaal kunnen aangeven dát ze dit willen, zo ja met wat soort auto, en iets kunnen vinden over voorwaarden, inleverdatum etc.

Hierbij werkt PitStop samen met een Leasemaatschappij, en richten zich op klanten die wel eens een ‘leuke/andere’ auto willen uitproberen als ‘geluk bij een ongeluk’ als ze een (al dan niet geplande) reparatie hebben.

Casus 3. Doe het zelf avonden

Doe het zelf avonden - Stemmingsplaatje

Module voor inplannen en aanmelden voor informatieavonden, waarbij klanten in de garage kunnen mee sleutelen onder leiding van reparateur. Dit doet PitStop vooral voor klantenbinding. De workshops richt zich vooral op wat klanten met wat oudere auto’s, wat een aantal reparateurs leuk vindt, en ook onder klanten animo voor is. En ook vanwege moeilijk te krijgen personeel, en dat de garage in de avonduren nu toch ongebruikt is.

Casus 4. Andere eigen functionaliteit

Wie is creatiever - ChatGPT of jij? - Stemmingsplaatje

Figuur 3: Wie is creatiever; mens of machine? Bron: Dean Long (2023)

Studentengroepen kunnen ook zelf een functionaliteit plannen, mits passend bij Pitstop, en niet te groot en niet te klein. Wees zelf creatief. Of gebruik desgewenst ChatGPT als 'assistive technology' of 'creative technology' om een suggestie. Kader deze wel met de nodige informatie. Geef hem de beschrijving huidige functonaliteit zoals Edwin van Wijk die opgeeft in documentatie in zijn github repo. Geef hem daarna de drie voorbeeld casussen/functionaleiten als eh.... voorbeeld. Maar itereer (prompt) ook wel door op wat ChatGPT je geeft krijgt. Onderstaand is een - vrij uitgebreide - start prompt die deze zaken bevat:

"Genereer een context- en opdrachtbeschrijving voor een nieuwe PitStop uitbreiding Zie de opdrachtbeschrijving en 3 voorbeelden op de minordevops.nl site. Concreet:

  1. Raadpleeg de bestaande functionaliteit van Microservice applicatie PitStop over 'Garage Maintenance' op https://github.com/EdwinVW/pitstop/wiki/Application%20functionality. Vertaal dit naar het Nederlands voor de introductie (onderdeel C hieronder)
  2. Raadpleeg dan de sectie "Voorbeelden van functionele uitbreidingen" op </week-7-8-beroepsproduct/opdracht-beschrijving.html#voorbeelden-van-functionele-uitbreidingen>
  3. De 4e optie beschrijft daar al het 'zelf verzinnen' eventueel met hulp van ChatGPT. Voor de gewenste functionele uitbreiding van PitStop genereer je 7 zaken:
  • a. een coole project naam a la "Leenauto's" of "Klant in the loop", maar dan voor een nieuwe/andere functionele uitbreiding
  • b. En ook een creatieve ondertitel, hierbij zoals "Geluk bij een Ongeluk"
  • c. Een Nederlandse vertaling en parafrasering van de standaard functionaliteit van PitsStop via de eerder gegeven URL op github.com/EdwinVW als context beschrijving en introductie in een h2 kopje 'Context'.
  • d. Een korte opdrachtbeschrijving waarin je minstens 2 gebruikersgroepen noemt en ook wat details qua 'working objects' als 'lijstjes', 'notificaties', 'overzicht', 'start ticker' of 'go/no beslissing' en functionaliteit en domeintermen uit PitStop zoals 'reparatie', 'doorlooptijd' en nieuwe termen uit de uitbreiding (dit zijn voorbeelden, gebruik deze NIET letterlijk, tenzij ze voor de door jou bedacht uitbreiding ook toevalllig relevant zijn)
  • e. Genereer ook direct een afbeelding bij de opdracht, in lijn met de andere 3 (tekening rondom het thema, met liefst hierop een of meer personen in beweging (een beetje 'in actie').
  • f. Geef tot slot een disclaimer dat dit een fictieve casus is, en dat genoemde API's en partijen niet per se echt zijn.
  • g. Geef de bronnen, de 2 URL's op github.com en minordevops.nl van hierboven

Geef dan aan dat je graag door itereert op wat je hebt gemaakt. "Want één prompt is geen prompt..."

Maak van al bovenstaande een duidelijke zakelijke tekst, dus GEEN marketing tekst. Schrijf actief. Wees spaarzaam met bivoegelijke naamwoorden. Bewaar marketing voor het plaatje ;). Schrijf de hele tekst in b2 niveau Nederlands en in active vorm (dus NIET lijdend e.g. met 'word/worden' of 'is/zijn' + voltooid deelwoord). Laat ook de a, b, c t/m g indeling weg uit je gegenereerde input. Dit is hierboven enkel voor het structureren van de prompt zelf. Graag 1 kopjes 1 met de Titel en dan dubbele punt en erachter de subtitel. Dan eronder direct het gegenereerde plaatje (afbeelding), liefst rechts uitgelijnd."

ChatPUG: PitStop Uitbreiding Generator

Er is per oktober 2024 ook een kant en klare 'custom GPT', een zogenaamde 'GPTs' beschikbaar. Deze bevat een uitgebreide variant van bovenstaande prompt. Hier de link naar chatgpt.com:

ChatPUG

Dit is een service aan jou, maar geeft geen garantie op dat de output goed is (e.g. 'garantie tot de deur', oftewel de plek waar jij begint met gebruiken is al GEEN ENKELE garantie meer). Dat is ter eigen beoordeling. Je kunt dit ook gebruiken 'zolang de voorraad strekt' (want Open AI kan deze feature ook betaald maken e.d.)).

ChatPUG: PitStop Uitbreiding Generator

Figuur 4: ChatPUG: PitStop Uitbreiding Generator

NB Een Generative AI is dus NIET betrouwbaar. En je zou het een 'slappe afspiegeling' van een echte opdrachtgever kunnen noemen. Maar het is wel een opdrachtgever met - waarschijnlijk - meer kennis dan welke 'echte' opdrachtgever ter wereld dan ook. En ook is een Genearative AI gebruiken als 'opdrachtgever' beter dan als developer zelf je eigen opdrachtgever zijn. Omdat je dan opdracht en/of requirements snel bij stelt op basis van wat makkelijk te implementeren is. Of zelf leuk lijkt.. Een bekend gezegde is "You are NOT your user". Dit gaat over UX/UI, maar is ook iets breder toepasselijk.

"User-Centred Design is surprisingly difficult. One of the biggest issues, certainly for those with no HCI or usability experience, is a lack of appreciation of how users think and work.Their assumption is that users will approach and solve problems in the same way as the designers and developers of an interactive solution." - ixDF, 2016

Maar nogmaals wel is AI en zeker LLM's (Large Language Models) structureel unexplainable en onbetrouwbaar. Daarom hieronder een belangrijke disclaimer en waarschuwing bij gebruik.

Disclaimer/waarschuwing

In essentie is het gebruik van ChatPUG niet wezenlijk anders dan bovenstaande 'handmatige' prompt gebruiken. Je hoeft nu alleen maar 'Go' in te typen o.i.d. Maar omdat de Prompt nu netjes verpakt is in een (GPTs) doosje, vergeet je wellicht dat ChatGPT fouten maakt. En dat de maker eran mogelijk ook fouten of onvolkomenheden in de prompt achter de GPTs heeft achtergelaten. Dus we raden aan om verder werken hierop en de GPTs zelf bekijken en aanpassen. En vooral zelf alle output te controleren, door te prompten en handmatig verder te werken met wat je van ChatGPT krijgt. Want als engineer kun je de gebruikte tool niet de schuld geven; je bent zelf verantwoordelijk voor je werk.

Sowieso moet je NOOIT persoonlijke gegevens of IP (Intellectual property) gevoelige gegevens in ChatGPT of andere online tools/AI's invoeren!

Ook moet je GEEN gevoelige gegevens in ChatGPT stoppen. Sowieso geen persoonsgegevens als namen of locatiegegevens. Maar onder gevoelig gegevens hoort bijvoorbeeld ook de opdracht(beschrijving) die je van de echte opdrachtgever in blok 2 van de minor DevOps krijgt.

Voor die opdracht teken je mogelijk ook een NDA (Non Disclosure Agreement). Maar ben je zonder dat ook in algemene zin een 'professionele houding' verplicht en voorzichtigheid met gevoelige gegevens. Dus vraag altijd eerst toestemming voor gebruik van AI van een opdrachtgever. Een leg deze daarbij goed uit wat je wilt doen, wat de meerwaarde kan zijn, maar ook welke alternatieven. En wat de risico's zijn. Het zelf in controle blijven, en Generative AI de (minder gevoelige) details laten verbeteren is ook vaak een betere aanpak:

"You start to rely on AI to generate content that you realistically should be ashamed to be letting a robot generate for you" (Panagis, 2024).

Hoogstens kun je als tegenmaatregel je prompt eerst zwaar anonimiseren. Of een custom AI model gebruiken in plaats van een van de tech giants. Want bij tech giants en ook in het algemeen moet je altijd bedenken dat:

"If you're not paying for the product, you ARE the product." - Andrew Lewis (Shaikh 2018)

Bronnen

Last change: 2025-01-13