08 sep 3 overeenkomsten en 3 verschillen tussen use cases en user stories
Rob den Hollander en Dennis Geluk
In eerder publicaties (o.a. Agile requirements bestaan niet & Efficiënte analyse: Just Enough in de praktijk) schreven we al dat use cases en user stories prima naast elkaar kunnen worden gebruikt.
Use cases hebben een meerwaarde wanneer er behoefte is aan een gestructureerde manier van het vastleggen van requirements. Als deze behoefte er niet is dan kunnen we user stories gebruiken.
Ondanks de verschillen tussen use cases en user stories blijkt in de praktijk dat veel analisten use cases als een uitgebreide vorm van user stories beschouwen. Sterker nog, in sommige gevallen worden use cases en user stories zelfs als synoniemen gezien.
In dit artikel staan we stil bij de belangrijkste overeenkomsten en verschillen tussen use cases en user stories. Hiermee willen we duidelijk maken waarom en met welk doel we bij DiVetro use cases en user stories gebruiken.
Want use cases en user stories hebben allebei (pas) hun nut wanneer ze op het juiste moment voor het juiste doel gebruikt worden.
3 Overeenkomsten tussen use cases en user stories
1. Beschrijving vanuit het perspectief van de gebruiker
Eén van de belangrijkste overeenkomsten tussen user stories en use cases is dat beide een gewenste functionaliteit van een systeem beschrijven vanuit het perspectief van de gebruiker (user). De focus ligt hierbij op de business value zonder hierbij in te gaan op de technische details.
2. Elementen om de scope van een systeem te bepalen
Zowel use cases als user stories kunnen gebruikt worden om de functionele en technische grenzen (scope) van een systeem vast te stellen. Voor een scope bepaling is het immers voldoende om een globale beschrijving van de functionaliteit en verantwoordelijkheden te hebben.
In het geval van use cases gebruiken we een use case model en een korte beschrijving per use case. In het geval van user stories beschrijven we per user story scherp wie welke toegevoegde waarde zal ondervinden.
Door het gebruik van actoren binnen een use case model is het ook relatief eenvoudig om de technische grenzen van een systeem te beschrijven. Als we daarentegen alleen user stories gebruiken dan kunnen we de grenzen van een systeem niet direct uit de individuele stories afleiden.
3. Elementen om de omvang van het systeem te bepalen
Use cases en user stories kunnen allebei gebruikt worden om een schatting te maken van de omvang van een systeem of release. Wanneer we alleen use cases gebruiken dan hebben we een schatting op een abstracter (hoger) niveau dan wanneer we een uitgebreide verzameling user stories gebruiken.
Zoals gezegd kunnen use cases en user stories ook in combinatie met elkaar gebruikt worden. Meestal worden de use cases dan gebruikt voor een eerste (grove) schatting en geven de user stories in een later stadium een meer onderbouwde schatting.
3 Verschillen tussen use cases en user stories
1. User stories primair voor planning gebruikt
User stories zijn ontstaan binnen de Extreme Programming (XP) methodiek, waarbij ze primair gebruikt werden als een ‘speelstuk’ in de planning game. Alle user stories komen in principe op de backlog en bieden daarmee een geprioriteerde lijst waarmee de PO en het development team een volgende iteratie of release kunnen plannen.
Per individuele story worden de benodigde taken (development, test, requirements, etc…) bepaald die nodig zijn om de gewenste functioneliteit op te kunnen leveren.
We zouden derhalve kunnen stellen dat een user story voor een significant deel een planningseenheid is. Uiteraard bevat een user story ook primaire requirements om de acceptatiecriteria van de story zo scherp te maken. Deze acceptatiecriteria kunnen vervolgens gebruikt worden om de story te valideren op volledigheid en correctheid.
Merk op dat, hoewel use cases een volstrekt ander doel hebben (zie hieronder), bovenstaande ook bereikt kan worden door het gebruik van use case slices! Een use case slice verhoudt zich in alle opzichten tot een user story en is, net zoals een user story, primair een planningseenheid.
2. Use cases primair gebruikt voor het gestructureerd vastleggen van requirements
Use cases zijn ontstaan om alle mogelijke manieren waarop een gebruiker (actor) een doel kan bereiken gestructureerd te beschrijven. We kunnen veel eisen en wensen in de vorm van user requirements in één use case vastleggen.
Zoals hiervoor benoemd start iedere use case op een abstract niveau en kan deze indien nodig verder gedetailleerd worden. Volledig uitgewerkte use cases beschrijven, ondersteund door een termenlijst, domeinmodel, bedrijfsregels en diverse aanvullende eisen, de volledige (functionele) werking van een systeem.
Ongeacht de toegepaste diepgang is het primaire doel van use cases dus het gestructureerd vastleggen van eisen en wensen die aan een systeem gesteld worden.
3. Use cases hebben een waarde als naslagwerk
Bij het gebruik van user stories wordt meestal voor iedere wijziging een nieuwe user story beschreven zonder de oude aan te passen. Hierdoor kan het lastig worden om na oplevering een scherp beeld te hebben van de actuele functionaliteit.
Omdat use cases primair bedoeld zijn voor het gestructureerd vastleggen van requirements hebben zij, mits bijgehouden, een meerwaarde als naslagwerk.
Conclusie:
Use cases en User stories hebben duidelijke overeenkomsten en verschillen. Afhankelijk van de specifieke projectsituatie kunt u ervoor kiezen om use cases naast user stories te gebruiken. Houd hierbij altijd rekening waarvoor beide elementen primair bedoeld zijn en op welk vlak zij een meerwaarde hebben.
De ervaring leert ons dat u binnen een agile project kunt kiezen voor het gebruik van 1) alleen user stories of 2) een combinatie van user stories en use cases. Het gebruik van use cases alleen is onvoldoende.
In onze visie zou iedere functionele story zijn oorsprong moeten vinden in een use case. Afhankelijk van welke methode of aanpak u volgt kan een user story direct ontstaan uit de use case of wordt de use case (achteraf) gebruikt voor het vastleggen en bijwerken van de documentatie.
De ‘verantwoordelijkheid’ van user stories en use cases is dus duidelijk: een user story faciliteert primair de planning en de scope van het werkpakket terwijl een use case een middel is voor het structureel vastleggen van requirements.
Hoe denkt u hierover?
Heeft u vragen of opmerkingen over agile werken of de impact van agile werken op uw requirements? Aarzel niet en deel uw vragen en opmerkingen via het reactieformulier onderaan deze pagina, via info@divetro.nl of via +31 (0) 88 000 54 00. Wij helpen u graag verder.
Volg een training
Wilt u uw kennis uitbreiden op het gebied van analyse en agile werken? Volg dan één van onze praktische trainingen of workshops. Bekijk hiervoor het trainingsaanbod van de DiVetro Academy.
Blijf op de hoogte
Wilt u meer van dit soort blog posts lezen? Meld u dan aan voor onze nieuwsbrief. U ontvangt onze blog posts dan in uw mailbox zodra ze op onze website verschijnen.
Rob den Hollander is senior informatie analist bij DiVetro. Hij heeft ruim 15 jaar ervaring met informatie analyse in systeem ontwikkeling en is gespecialiseerd in UC2.0 en Agile werken. Momenteel helpt Rob verschillende opdrachtgevers met het ontwikkelen/professionaliseren van agile teams.
Dennis Geluk is een senior informatie analist en partner van DiVetro. Hij heeft meer dan 15 jaar IT ervaring. Dennis is een gecertificeerd Use-Case 2.0 coach. Hij heeft bij verschillende organisaties een spilfunctie vervuld bij het implementeren van UC2.0, het invoeren van Agile werken en het verbeteren van requirements standaarden. Momenteel is Dennis als coach en informatie analist voor de NS bezig UC2.0 te implementeren. Lees hier meer over de NS-case.
