Screenshot Mural board User Story Mapping

User Story Mapping – faciliteer zelf een online workshop

Op 27 mei hebben we een tweede online meetup georganiseerd met als thema ‘User Story Mapping‘. Deze keer voor de leden van de meetup groep Agile Meetup Rotterdam (al maakt in deze tijden van thuiswerken de locatie niet veel meer uit). Een maand eerder hadden we dit onderwerp al besproken tijdens de  Agile Meetup Breda, waarvan je in deze blogpost de samenvatting kunt vinden. In dit artikel beschrijven we wat we anders hebben gedaan dan de vorige keer en wat het effect hiervan was. Kleine teaser: het was een groot succes!

Mocht je zelf een keer deze workshop willen faciliteren: een overzicht van onze aanpak, de stappen die we hebben doorlopen en enkele tips kun je vinden in de Facilitation Guide.

Heb je interesse in een door ons gefaciliteerde Story Mapping workshop voor jouw organisatie en teams? Neem dan contact met mij op via rutger.vandijk@valueminds.nl !

Agile Meetup Rotterdam

Via onze Meetup-site stond de teller op 30 inschrijvingen met een wachtlijst van 17 personen. Uiteindelijk waren er tijdens de sessie 22 deelnemers,  waarvan 4 Valueminds collega’s als facilitators. De meetup was van 15:00u tot 17:00u, met ongeveer 15 minuten ‘digitale inloop’.

Deze keer was de case: het ontwikkelen van een (fictieve) ‘Corona-app’. Ter voorbereiding hebben we enkele onderdelen van de story map uitgewerkt. Het doel was om een app te ontwikkelen die registreert wie, wanneer en waar met elkaar in contact komt. Vervolgens geeft de app aan of er contact is geweest met een persoon die mogelijk besmet is met Covid-19. Daarnaast kon een medewerker van een gezondheidsdienst een Covid-19 test uitvoeren en werden gebruikers geïnformeerd over eventueel te vermijden hotspots.

Tijdens de meetup hebben we in groepen de hoofdstappen van de story map opgesplitst in kleinere stappen, ideeën en mogelijke taken. Voor de Story Map-kenners: de ‘Explore’-fase. De fictieve heren ‘Chris Civilian’ en ‘Harry Health Care’ zijn ingezet als persona’s.

Aanpassingen & Verbeteringen

 

1. Microsoft Teams v.s. Zoom

Voor de bijeenkomst van Agile Meetup Breda hadden we gebruik gemaakt van Microsoft Teams; dat werkte toen niet ideaal. Met name vanwege toegangsproblemen en werkplekinstellingen duurde het 20 minuten voordat iedereen op de juiste plaats was en we konden starten.

Deze keer hebben we Zoom gebruikt en dat bleek een goede keuze. Iedereen kon zonder problemen in bij Zoom aanmelden en was er duidelijk beeld en geluid. De chat functionaliteit in Zoom is wel wat beperkt ten opzichte van Teams. Bij Zoom kan je dan weer alle deelnemers tegelijkertijd zien.

Tip
Het gebruik van de break-out rooms functionaliteit in Zoom werkt eenvoudig. In enkele klikken zijn alle deelnemers verdeeld over verschillende video-chat-groepen!

 

2. Hosting en moderating

Deze keer was een van de facilitators nu dedicated moderator én time keeper. Dat werkte erg prettig en gaf rust bij de overige facilitators. Zo konden eventuele ‘laatkomers’ worden opgevangen in de hoofdsessie en doorgestuurd worden naar de breakout rooms. De vorige keer deden alle facilitators dit erbij, waardoor het voor kwam dat degene die het woord was, ook bezig was om deelnemers toegang te verlenen. Zowel voor de facilitators als de deelnemers leidde dit erg af.

Tip
Zorg voor een apart betaald Zoom-account naast de ‘facilitator’ accounts. Zo kan de moderator alle ‘digitale’ touwtjes in handen houden!

 

3. De ‘digitale inloop’

Onderdeel van de officiële agenda was een kwartier “troubleshooting” en “sandboxing”. Oftewel: zorgen dat iedereen toegang had tot Zoom en de online collaboration tool van Mural.

Ook hebben we de deelnemers de kans gegeven om al even rond te kijken in het Mural-board. Hier kon alvast geoefend worden met het creëren en verslepen van bijvoorbeeld sticky notes.

De eerste keer hadden we een half uur ‘inloop’ voor de eigenlijke start van de meetup gepland. Daar werd toen nauwelijks gebruik van gemaakt. Deze keer was bijna iedereen stipt bij aanvang om 15:00u aanwezig. En omdat we geen problemen meer hadden met het aanmelden en instellen van Zoom, heeft iedereen de tijd gehad om al wat rond te neuzen in Mural.

Tip
Geef iedereen even tijd om de werking van browsers, webcams en microfoons te controleren.
(ondanks dat de meeste thuiswerkers in deze bijzondere periode hun werkplek inmiddels wel op orde hebben)

 

4. User Story Mapping: de ‘Corona-app’

Tijdens Agile Breda meetup hebben we een casus gebruikt met als onderwerp het ‘inspecteren van gevaarlijke stoffen aan boord van zeevaartschepen in de Rotterdamse haven’. Dit bleek toen best een complex situatie. Het was niet voor iedereen even gemakkelijk voor te stellen wat de persona’s nu aan precies aan taken (user actions) zouden kunnen hebben.

Gezien de actualiteit, kozen we voor het (fictief) ontwerpen van een Corona-app. We hebben nog licht getwijfeld of we ons, wat betreft User Story Mapping, wilden richten tot beginners of meer gevorderden. En of we in Mural zouden starten met een nagenoeg leeg canvas om vervolgens samen stap voor stap een story map op te bouwen. Een alternatief was om een uitgewerkte User Story Map neer te zetten, die we dan met de deelnemers zouden doorlopen.

Uiteindelijk hebben we gekozen voor een combinatie:

  • een tweetal persona’s beschreven (Harry Health Care en Chris Civilian)
  • een voorbeeld ‘backbone’ story map per break out groep gemaakt
  • een geheel uitgewerkt storymap met “release slices” en een ontwikkelstrategie.

De voorbeeld backbone story map was ingevuld tot aan het “Explore” gedeelte. Dat gedeelte hebben we in break out sessies met de deelnemers ingevuld. Hierna hebben we aan de hand van de voorbereide story map laten zien hoe je de release slices maakt op basis van duidelijke release doelen. Via deze release doelen hebben we een ontwikkelstrategie bepaalt. Tot slot hebben we laten zien hoe je de betreffende release opneemt in de Sprint Backlog, van waaruit de ontwikkelteams aan de slag kunnen. Want daar gaat het natuurlijk om!

Tip
Zorg voor voldoende interactie en samenwerking tijdens een online meetup. Als je alleen wilt vertellen of laten zien hoe je een Story Map maakt, kan een webinar of webcast een betere vorm zijn.

 

5. Agenda & tijd

Deze keer hebben we ons goed aan de agenda kunnen houden. De sessie was korter, maar wel exact binnen tijd klaar. Door bijvoorbeeld maar één keer te schakelen naar een break out sessie, wordt het minder rommelig. Hierdoor zijn de deelnemers minder afgeleid en is er een duidelijke scheiding tussen de meetup onderdelen. Daarnaast voorkom je het afhaken van deelnemers als je ‘uit de tijd loopt’. De moderator hield, naast de facilitators, de tijd per onderdeel extra in de gaten.

Het gebruik van tools als Zoom, samen een dedicated moderator, helpen bij het volgen van de agenda en houden van contact met de deelnemers.

Tip
Oefen vooraf met het gebruik van tools als Zoom.
Probeer ook eventuele alternatieven uit om te bepalen wat het beste past bij het type sessie.

 

6. Kleine tweaks voor een volgende keer…

  • Controleer of alle layout onderdelen in het Mural-board vergrendeld (‘gelocked’) zijn.
    Nu werd er tijdens de workshop wel eens onbedoeld een deel van de Story Map door iemand versleept.
  • Introduceer ‘energizers’ tijdens de meetup. Het energieniveau van de deelnemers valt vaak na een tijd terug (je kijkt tenslotte vrij passief naar een beeldscherm). Een korte leuke oefening kan helpen om iedereen weer fris en actief te krijgen tijdens de sessies.
  • Voeg eventueel een uitgebreidere toelichting toe bij de verschillende stappen van, in dit geval, de Story Map. Hiermee kunnen deelnemers zelf nog de instructie nalezen.
    Ook kan je de Outline-functie van Mural hiervoor gebruiken.

 

Volgende meetup!

Gezien de enthousiaste reacties van de deelnemers en de mooie NPS score van 33, gaan we deze meetup vaker online organiseren. Op dit moment hebben we voldoende onderwerpen waar we uit kunnen kiezen!

Mocht je een onderwerp hebben waar je het graag over wilt hebben, stuur ons dan een bericht via de Meetup pagina. Tot de volgende meetup!

User Story Mapping tijdens Agile Meetup Breda: de Retrospective

Op 22 april hebben we met Agile Meetup Breda een online workshop gehouden met als thema “User Story Mapping”.

Initieel was het de bedoeling om de meetup in levende lijve te doen op een mooie locatie in Breda. De coronacrisis gooide echter helaas roet in het eten. Omdat we toch aan de slag wilden met het onderwerp en we ook erg benieuwd waren of we dit op afstand konden doen hebben we de meetup alsnog door laten gaan maar dan online.

Een overzicht van onze aanpak en de stappen die we hebben doorlopen kun je hier vinden.

De meetup was van 15:00u tot 17:00u. Met van 14:30u tot 15:00u digitale inloop. We hadden 15 deelnemers. Als digitale hulpmiddelen hebben me Microsoft Teams en Mural gebruikt.

Dit was voor ons de eerste keer dat we het op deze manier hebben gefaciliteerd. Heel veel ging goed, maar er viel zeker nog genoeg te verbeteren voor een volgende keer. Onderstaand de belangrijkste punten uit onze retrospective:

Wat ging goed

  • Overall hebben we in een korte tijd de belangrijkste aspecten van de techniek kunnen behandelen. Voor een volgende keer gaan we nog goed kijken of bepaalde onderdelen meer of minder of op een andere manier aan de orde moeten komen. Hiervoor gaan we ook beter vooraf luisteren naar de behoeften van de groep.
  • We hadden een zeer enthousiaste groep deelnemers. Voor zover we dat goed meekregen had iedereen er lol in en was het voor iedereen een interessante ervaring.
  • Naast centrale onderdelen hadden we ook twee breakout momenten, waarin een facilitator met een groepje van 3 tot 5 mensen in een aparte teamroom werkte aan het invullen van een gedeelte van de User Story Map. Dat was erg geslaagd. De sfeer was goed. Omdat je met een klein groepje bent wordt het gelijk wat intiemer en persoonlijker.
  • Richting het einde vielen er een aantal kwartjes, met name voor wat betreft waar User Story Mapping past in een flow met andere technieken. Bijvoorbeeld dat je begint met een product vision, dan maak je een User Story Map en vervolgens komen de User Stories hiervan als items op een Sprint Backlog terecht, al dan niet via een Product Backlog. Hierdoor kwam er meer beeld bij de context van een User Story Map.

Wat kan beter

  • Microsoft teams werkt in de huidige vorm niet goed genoeg. Ondanks vooraf gestuurde uitnodigingen met toegang tot onze Teams omgeving duurde het zeker 20 minuten voordat we van start konden omdat mensen toch tegen toegangsproblemen aanliepen. We hadden verschillende rooms aangemaakt voor de break-out onderdelen. Ook daarbij duurde het langer dan wenselijk voordat iedereen op de juiste plek zat. Een volgende keer gaan we gebruik maken van Zoom of een andere online tool.
  • Daarnaast willen we de volgende keer dat een persoon als moderator optreed voor wat betreft technische zaken en mensen die inlogproblemen hebben. Dat moet ook duidelijk zijn voor de genodigden. Nu waren er een aantal mensen bezig, o.a. de gene die het eerste gedeelte aan het uitleggen was, met mensen toegang te verlenen en troubleshooting.
  • We hadden vooraf een half uur inloop gepland voor het officiële gedeelte zou beginnen. Net als bij een fysieke meetup. We merkten echter dat nu bijna iedereen pas in de laatste minuut digitaal binnenkwam. De volgende week maken 20 tot 30 minuten inloop onderdeel van de officiële planning. Zijn we eerder klaar, dan is het mooi en gaan we van start, maar andere loop je gelijk al achter op de planning.
  • We hadden een vrij strakke planning, met het schakelen van gezamenlijke onderdelen naar break-out onderdelen verloren we tijd, waardoor de planning nog meer in het gedrang kwam. De volgende keer gaan we dus ruimer plannen.
  • De intro die we gaven m.b.t. User Story Mapping was te kort. Gedurende de meetup kwamen we er achter dat niet voor iedereen duidelijk wat nou precies het doel is en wanneer je het goed kunt gebruiken. De volgende keer gaan we hier vooraf langer bij stilstaan.
  • Ondanks dat User Story Mapping redelijk gangbaar is, merkten we toch dat er verschillende interpretaties zijn van de techniek. Ook als facilitators. Hier hadden we vooraf langer bij stil moeten staan. Voor een volgende keer gaan we bijvoorbeeld duidelijker bepalen of we gaan focussen op het maken van een back-bone of dat we meer aandacht gaan besteden aan het maken van slices en een development strategie. We hadden een redelijk complexe casus gekozen, met als onderwerp het Havenbedrijf in Rotterdam. Erg interessant, maar wellicht dat we voor een volgende een iets minder complexe casus kiezen.
  • Twee uur voor een meetup/workshop met een onderwerp als dit is erg kort. Om het onderwerp echt recht te doen en tijd te hebben om er zelf mee aan de slag te gaan, heb je al gauw 4 tot 6 uur nodig.

De volgende keer dat we aan de slag gaan met User Story Mapping is op 27 mei, met Agile Meetup Rotterdam.

Meerdere product backlogs? Yes please!

In mijn tijd werkzaam als product owner voor Philips ben ik aanraking gekomen met SAFe. Onderdeel daarvan is het beheren van product backlogs op meerdere niveaus. Nu lees en hoor ik vaak meningen dat je scaling niet moet doen en SAFe al helemaal niet, omdat er facetten haaks op het agile gedachte goed staan. Dat zal vast waar zijn, maar dat vraagt naar mijn mening een grote mate van volwassenheid in het agile werken. Dat geldt voor vele van ons nog niet en zo ook niet voor mij en de organisaties waar ik tot nu toe werkzaam ben geweest. Ik heb dan ook het werken met product backlogs op meerdere niveaus erg nuttig ervaren en toegepast in mijn opdrachten na Philips. Lees meer

A product backlog should contain just about 50 items

An thought-provoking idea has rested in my mind for some time and I’m writing it down right now to get some feedback. Maybe I’m completely wrong, but that ‘ll be clear from the reactions.

I often see very large product backlogs with hundreds of items in them. The sheer size makes it very hard to keep the overview. The symptoms are then solved with ever-expanding structures with epics, features, themes etc. But the root-cause is the size, and I contend that it’s not wise to make the backlog so large.

And I think it is really not necessary to have a large backlog. It’s rather a remainder of a waterfall mentality.

A product backlog with 50 items is enough! And this is why:

The top of the backlog, the work for the coming 2-3 sprints, should contain small and clear items. In my experience most teams deliver 6-10 items per sprint, so that yields some 25 items at the top.

Below that, the items should not be that small. There should be larger items that can be sliced into small pieces later.

Slicing already now is not wise. It could be that we will not deliver this item. New, and more important items can emerge, the PO may down-prioritise these items. Maybe the client asks us to take new directions, or the team invents smarter technical solutions. Slicing the items too early is a form of waste. Having too many small items in the backlog can make us less agile. We don’t want to change direction because we have put so much time in the existing items already.

So, after the top 25 small items, there should be larger items in the backlog. If the top-items are all 1-8 story points in size, the items lower in the backlog should be 13-40 points in size, and lower still the items should be even bigger. So having only 50 items in the product backlog is enough to keep the team busy for a year or so.

Well, this is my theory. Any thoughts?

Een product backlog moet altijd maar ongeveer 50 items bevatten

Hierbij maar eens een provocerend blogje met een provocerende titel. Het is een idee dat bij mij al een poosje borrelt en dat ik maar eens opschrijf om er feedback op te krijgen. Misschien zit ik er wel helemaal naast, maar dat wordt dan wel duidelijk uit de reacties.

Ik zie vaak hele grote, lange product backlogs met honderden items erin, waarin men met grote moeite overzicht behoudt. Om dat overzicht te krijgen worden dan allerlei levels toegevoegd, thema’s, epics, stories, of nog meer niveaus.

Volgens mij is dat allemaal niet nodig, sterker nog, volgens mij is het fout en een teken van nog steeds behoorlijk waterval werken.

Een Product Backlog met 50 items is genoeg!

Dat zit zo.

De top van de backlog, het werk voor de komende 2 of 3 sprints, moet mooie kleine, heldere items bevatten. In mijn ervaring doen de meeste teams ongeveer 6-10 items per sprint, dus dat geeft de eerste 25 of zo items.

Daaronder hoeft het allemaal niet zo precies en zo klein te zijn. Het zijn grotere brokken die later wel in stukjes gehakt worden als ze bijna in een sprint worden opgepakt.

Nu al in stukjes hakken is niet slim. Het zou zomaar kunnen zijn dat we dit item helemaal niet gaan oppakken. De klant wil misschien een andere kant op, of we verzinnen een heel andere technische oplossing. Agile zijn betekent dat je zoveel mogelijk openstaat voor dit soort veranderingen. Alles vast helemaal opknippen en uitwerken zorgt ervoor dat je al snel denkt: “dit moeten we echt zo uitvoeren, daar is al zo veel voorbereiding in gestoken”.

Onder die 3 sprints met kleine items (zeg van 1-8 story points groot) komen dus grotere items. Rond sprint 3-5 in de backlog zijn ze nog niet zo heel groot, 13-21 punten groot. Maar daaronder zijn het grotere brokken, 40-100 punten groot.

De hele backlog van 50 items vertegenwoordigt dus werk voor een heel jaar. Maar vooraf uitwerken is een vorm van waterval denken.

Herkenbaar? Mee eens? Ik hoor jullie reacties graag!

Value points

André Heijstek, directeur van Valueminds:

‘De kosten van een user story worden in de regel ingeschat in story points, waarvoor we meestal de Fibonacci-reeks gebruiken (1,2,3,5,8, etc.). Maar hoe schat je de waarde van een user story in? Dit kan op dezelfde manier. De product owner kan samen met zijn stakeholders de inschatting maken met dezelfde Fibonacci reeks. Hiervoor kan je planning poker kaartjes gebruiken. Het kan natuurlijk ook met een andere set getallen. Ik zelf werk altijd met een reeks van 1 t/m 1000, waarbij 1000 het meest belangrijk is.

Als je de backlog hebt ingeschat op zowel de waarde als de kosten, dan is een deel van de prioritering van de backlog gemakkelijker geworden. Je kan dan per user story de prioriteit berekenen als business waarde/story points, bijvoorbeeld:

planning poker kaarten Valueminds

Stories zoals story 4 met veel waarde en weinig kosten kan je zo snel mogelijk oppakken. Stories met weinig waarde en veel kosten (story 3) kunnen van de backlog verwijderd worden. Natuurlijk is dit niet het enige wat de product owner mee moet nemen in de prioriteitsstelling. Technische afhankelijkheden tussen stories kunnen tot een andere volgorde leiden: je kan story 5 pas bouwen als story 13 eerst gebouwd is.

Daarnaast is het vaak ook slim om soortgelijke stories in 1 sprint bij elkaar op te pakken. Je krijgt dan een heldere sprint goal zoals: ‘in deze sprint doen we alle rapportage-stories.’

Het kan ook zijn dat je met stories op meerdere niveaus werkt, zoals thema’s, epics, etc. In dat geval moet je oppassen dat je maar op één niveau waardepunten toekent. Wat mij betreft is het laagste niveau (het niveau van de user stories) de plek waar je waarde zou moeten toekennen. Wanneer je dit niet doet, ga je dingen dubbel tellen. Ik kies voor het laagste niveau omdat ik van mening ben dat elke user story de waarde zou moeten hebben. Wanneer je punten op dit niveau gaat toekennen, dwingt het je ook om er zo over na te gaan denken.’

Volgorde van de backlog

André Heijstek, directeur van Valueminds:

‘De product backlog hoort geordend te zijn. Dingen die als eerste opgepakt moeten worden staan bovenaan, wat later mag komen staat onder. De regel die het meest wordt gebruikt is dat de items op volgorde van waarde staan. Naar mijn mening is dat echter te beperkt. In mijn ideale situatie bepaalt een mix van de volgende factoren de volgorde van de backlog:

  • Technische afhankelijkheden. Er is nu eenmaal vaak een bepaalde technische volgorde om dingen te bouwen.
  • Waarde. Spannende stories waar mogelijk ellende in zit moet relatief hoog op de lijst staan: fail fast is beter dan fail late.
  • Risico. De waarde die de stories hebben voor de klant of gebruiker; meestal vraag ik de Product Owner om aan alle stories een getal toe te kennen (100 voor heel veel business value, 1 voor heel weinig).

Naast deze drie aspecten, komt er in de keuzes voor de komende sprint nog en aspect bij: wanneer de items waaraan in een sprint wordt gewerkt aan elkaar gerelateerd zijn, werkt dit veel prettiger. Dan krijg je zoiets als: ‘In sprint 4 doen we rapportage, in sprint 5 implementeren we het zoeken.’ Wil je dat het team meer focus krijgt en meer gaat samenwerken tijdens sprint? Stel dan een sprint goal!’

Hoe user stories snel inschatten?

André Heijstek, directeur van Valueminds:

‘Planning poker is een bekende techniek om de grootte van User Stories in te schatten. En het is een goede techniek. Maar als ik veel (30-100) stories snel moet inschatten, dan duurt pokeren me te lang.

Maar wanneer is het nuttig om een grote groep stories in te schatten? Je kan dit doen wanneer de Product Owner wil weten hoe lang het ongeveer gaat duren om een bepaald deel van zijn backlog te bouwen. Ook agile projecten moeten ten slotte de verwachtingen van stakeholders managen.

Mijn techniek voor het snel inschatten van user stories is als volgt. Ik print alle user stories uit op klein formaat (A5 of A6) en ik leg ze in een stapel op tafel. Vervolgens vraag ik aan het development team om deze stapels in drie kleinere stapels te verdelen: Klein, Midden en Groot. Ik zorg dat de Product Owner hierbij aanwezig is, zodat hij snel uit kan leggen wat de bedoeling is van de stories. Mijn ervaring is dat dit ongeveer een uur kost voor 70-100 stories.

Als het team dit heeft gedaan, vraag ik het development team om hetzelfde nog een keer te doen. Er ontstaan dan 9  stapeltjes, van Klein-Klein tot Groot-Groot. De tweede ronde kost veel minder tijd, vaak is een half uur voldoende. Alle 9 stapeltjes bevatten user stories die ongeveer even groot zijn, en krijgen dus allemaal dezelfde grootte (in uren of in story points, net wat h et team gewend is).

Heeft het team nog geen schattingsmethode gekozen? Dan is dit een goed moment om daarmee te starten! De stapel Klein-Klein krijgt 1 story point en dient als referentie voor de andere stapels. De stapel Midden-Klein wordt vergeleken met Klein-Klein. Zijn ze 2 keer zo groot? 3 keer? Elk stapeltje krijgt op deze manier heel snel een waarde in story points.

Heeft het team al wel een schattingsmethode gekozen? Dan kunnen bestaande stories als referentie gebruikt worden.

In de praktijk heb ik vaak gezien dat de stories vanaf Midden-Midden te groot zijn om echt mee te werken. Het zijn geen stories meer maar epics. In dat geval moet er later nog gesplitst worden in kleinere stories. Al met al ben je ongeveer 2 uur kwijt om een hele backlog in te schatten.’