1. Gebruik korte en duidelijke titels
Je kunt niet over user stories praten zonder dat iemand begint over de bekende storytemplate:
Maar doe dat niet in de titel! Want dan ziet je story er dus zo uit op het bord:
Kies een korte, duidelijke titel die de inhoud van de story dekt.Dus niet:
- ‘Als zorgverlener wil ik mijn belgeschiedenis kunnen exporteren, zodat ik deze aan de zorgverzekeraar kan geven’.
Maar wel:
- ‘Export belgeschiedenis’.
2. Begin met een korte omschrijving (vrije tekst)
De detailpagina van een story begint in mijn ideale wereld met een korte beschrijving. Deze omschrijving bevat niet per se essentiële informatie, maar geeft vooral wat context.Voorbeeld korte beschrijving story:‘
Als zorgverlener kan ik momenteel in de tab Belgeschiedenis wel alle gevoerde gesprekken inzien, maar het is niet eenvoudig deze te exporteren. Deze export heb ik nodig voor mijn declaratie aan de zorgverzekeraar. We voegen een manier toe om eenvoudig een CSV van alle gesprekken te maken.’Dit onderdeel lijkt ‘waste’ (de Kanban-term voor onnodig werk dat ook weggelaten kan worden). Maar in de praktijk helpt dit de teamleden om continue naar het grotere geheel te blijven kijken en na te denken over vragen zoals: ‘Is dit de juiste oplossing?’, ‘Kan hetzelfde doel niet ook eenvoudiger bereikt worden?’ ‘Heeft dit nog impact op andere delen van de applicatie?’.Deze korte beschrijving is een prima plek om de storytemplate ‘As a …I want … so that …’ te gebruiken, maar kijk uit dat je geen zombie stories gaat krijgen.
3. Maak een opsomming van acceptatiecriteria
Klinkt misschien triviaal, maar ik tref regelmatig teams aan die werken op basis van alleen de omschrijving zonder specifiek de acceptatiecriteria te benoemen. Toegegeven: in het begin vond ik acceptatiecriteria ook overbodig en onnodige administratie. In de beschrijving staat het toch duidelijk genoeg? Toch voegt het veel waarde toe. Hou het simpel: een korte en bondige opsomming van punten is voldoende.
Voorbeeld acceptatiecriteria aan de hand van ‘Export Belgeschiedenis’:
Extra tip: afbakeningen zijn ook waardevolle acceptatiecriteria! Een acceptatiecriterium van de story ‘Export Belgeschiedenis‘ kan wat mij betreft ook zijn:
- ‘filteren van de geëxporteerde belgeschiedenis is geen onderdeel van deze story; dus binnen deze story altijd alle gesprekken exporteren’.
4. Wijzig de acceptatiecriteria op ieder moment
Acceptatiecriteria zijn wat mij betreft een levend document. Tijdens de refinement doen we ons best om met kritische vragen de belangrijkste criteria boven tafel te krijgen. Toch kun je altijd nieuwe dingen tegenkomen of nieuwe inzichten krijgen. Daarom mag je de acceptatiecriteria altijd aanpassen en uitbreiden (natuurlijk in overleg met de Product Owner en binnen het doel van de story). Vraagt de developer aan de Product Owner of het meest recente gesprek bovenaan moet komen of onderaan? Dan is dat een nieuw acceptatiecriterium. Vraagt de tester zich af wat er moet gebeuren als de belgeschiedenis nog leeg is? Dat is ook een nieuw acceptatiecriterium.
Ik ben me ervan bewust dat dit de deur openzet naar ‘scope creep’, het verschijnsel dat een story steeds omvangrijker wordt. Voor je het weet voegt je ongemerkt steeds meer functionaliteit toe: ‘zelf e-mailadres invullen’, ‘aanpassen van tekst in e-mail’, ‘instellen herhaalschema voor automatische verzending van de export’…
Iedere developer moet hierop bedacht zijn. De vuistregel is doorgaans: als je het eenvoudig kunt fixen én het valt binnen het doel van de story, fix het dan maar gewoon. Als het echt uitbreidingen van de functionaliteit zijn, maak er dan een nieuwe story van, zodat deze geprioriteerd kan worden door de Product Owner. En als je twijfelt, overleg je even met de rest van het team.
Het eindresultaat is dat de lijst van acceptatiecriteria een correcte en volledige beschrijving van de functionaliteit zijn. Je kunt ze bijna één-op-één omzetten naar testscenario’s.
5. Vink de acceptatiecriteria af
Voor de tester en de Product Owner is het erg frustrerend als een story volgens de developer klaar is, maar er toch nog functionaliteit ontbreekt. ‘Er staat toch dat dit aangepast moet worden op de loginpagina, de homepagina én de helppagina??? Dus op drie plaatsen, niet twee!’, hoor je dan verzuchten. Op de één of andere manier is het voor developers heel makkelijk om nét dat ene dingetje over het hoofd te zien. Ik heb in teams de spanningen flink op zien lopen over dit soort suffe ‘foutjes’.
De oplossing: ieder acceptatiecriterium wordt individueel afgevinkt door de developer. Als de developer klaar is, staat er een keurig rijtje groene vinkjes. Je kunt dit ook doen met je Definition of Done. Dan zie je in één oogopslag welke onderdelen daarvan wel of niet voldaan zijn. Dan ziet de story er uiteindelijk zo uit:
Conclusie
Voor alle duidelijkheid nogmaals: bovenstaande is bedoeld ter inspiratie. Schrijf je team alsjeblieft NOOIT voor hoe het moet werken. Ieder team is anders en heeft andere behoeftes. Maar als je problemen hebt met je user stories, kun je eens kijken of er bij bovenstaande best practices een oplossing zit.
Heb je zelf nog tips of toevoegingen? Laat het me weten! Je kunt me mailen op dirk.jansen@infi.nl. En vond je bovenstaande nuttig? Deel dit artikel dan.
[Dirk is project- en scrummaster bij Infi.]
Fotocredits: neilpatel.com.
Op de hoogte blijven van onze updates over techniek, toffe projecten of een kijkje achter de schermen? Meld je dan aan voor onze nieuwsbrief!