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/Workshop

  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 (Takane, 2017).
  2. Kies een van de PitStop casussen 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). Voor empathisch design en UX, zie ook IxDF (2016).
  • 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 of USM
  • 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). Je kunt het best een whiteboard gebruiken voor vrijheid en eenvoud, zodat iedereen in team input kan leveren. Bij een brainstorm vertragen tools alleen maar. Voor overnemen als je opzet hebt, kun je bv. Miro template gebruiken. Moderne aanpak is 'diagrams as code'. Check de TextUSM tool en repo: textusm.com · GitHub repo. Deze heeft ook VS Code plugin met live preview. Het is even puzzelen hoe je ook meer releases/sprints maakt (alles werkt met tab).

Toon Miro instructie (screenshot, groot) Miro – User Story Map templates zoekscherm

Voorbeeld uitgewerkte USM (Voorraadbeheer)

Zie de uitgewerkte user stories en USM voor de casus "Voorraadbeheer":

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.. ;)

Eerder leerde je de 8 fallacies of distributed computing.

En algemeen: waarom is het nuttig te denken in termen van 'fallacies'?

The 8 Fallacies of User stories

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

USM als 'functional spike' (onderzoek)

In deze week maak je ook een USM voor je casus. Zie USM als onderdeel van een 'functional spike': een kort, afgebakend onderzoek om interacties en scope van een feature te verkennen. Vergelijk dit met een 'technical spike' die je ook uitvoert om technische risico's te onderzoeken. Zie ook Spike (software development).

Technology push vs demand pull

Bij het kiezen van je te onderzoeken technologie (technical spike) en het aanscherpen van je casus (functional spike) helpt het onderscheid tussen 'technology push' en 'demand pull'. Let op dat technologie zoals AI niet altijd de beste startpunt is voor een project (Panagis, 2024).

"Compared to demand pull, technology push companies are in the reverse situation. They have developed a solution, but need to figure out what problem it solves. In this case, their potential customers are not already looking for a solution. Therefore, technology push companies need to figure out, which population in the market will benefit from their product and then convince them that the product is better than the status quo." — Kristi Bradford (2024)

Anti‑patterns in user stories (en hoe te voorkomen)

  • Lege ‘zodat’: herhaalt het middel/doel (“…zodat ik ingelogd ben”).
    • Beter: benoem meetbare waarde en wie profiteert.
    • Voorbeeld: Slecht “Als gebruiker wil ik kunnen inloggen, zodat ik ingelogd ben.” → Beter “Als klant wil ik kunnen inloggen, zodat ik mijn geplande reparaties en facturen kan zien.”
    • NB: ‘Inloggen’ is vaak geen gebruikersdoel maar een beveiligingsmaatregel. Een betere story benoemt de stakeholder en waarde van security:
      • “Als security‑officer wil ik dat gebruikers zich authenticeren, zodat kwaadwillenden geen toegang hebben en gebruikers alleen bij eigen gegevens kunnen.”
  • Implementatie‑verhaal: beschrijft oplossing i.p.v. behoefte (“JWT zetten”).
    • Beter: outcome/waarde; oplossing laat je vrij voor het team.
  • Zombie user story: blijft liggen, geen eigenaar/waarde, te groot.
    • Aanpak: slice volgens INVEST, duidelijke acceptatiecriteria, eigenaar + deadline; anders archiveren.
  • Vage waarde: ‘zodat het beter werkt’.
    • Aanpak: expliciteer KPI/DoD (bijv. doorlooptijd −20%, foutpercentage <1%).

Heuristiek: vervang 'zodat …' door "omdat dat … waarde oplevert voor …". Kun je geen stakeholder/waarde noemen? Story herformuleren of schrappen. Denk ook na over wie de echte klant is: als een product gratis lijkt, ben jij waarschijnlijk het product (Shaikh, 2018).

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 3: Simon Brown predikt 'Just enough upfront design' (YouTube/Brown, 2022)

Naast Humble's WaterScrumfall concept benadrukt ook C4 creator 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.

Bronnen

Last change: 2025-10-23