Use case 2.0 is de agile versie van de oude vertrouwde use cases. Minder bekend dan user stories maar in hybride omgevingen vaak een beter alternatief.
Bij agile requirements denken veel mensen vooral aan user stories. Hoewel dit een fantastische requirementstechniek is, is alleen het opstellen van user stories niet toereikend.
User stories zijn bijvoorbeeld niet geschikt voor:
- het opstellen van systeemdocumentatie
- het creëren van overzicht
- het gedetailleerd vastleggen van requirements
Vooral in hybride projecten (deels agile, deels waterval) lijkt het een logisch keuze om user stories te combineren met use cases. Of een andere reden kan zijn dat de business gewend is aan use cases en het agile team met user stories wil werken.
Use case 2.0
Wat veel analisten niet weten is dat er ook een agile versie van de use case techniek bestaat. De vernieuwde use case techniek, use case 2.0 genoemd, is flexibel en schaalbaar opgezet. Het is daardoor in zowel traditionele, agile als hybride omgevingen te gebruiken. In dit interview dat ik had met Ivar Jacobson, de grondlegger van use cases, vertelt hij over het gebruik van zijn requirementstechniek in een agile omgeving.
In vergelijking met de user story techniek biedt use case 2.0 meer structuur en houvast. In UC 2.0 is beschreven welke activiteiten en bijbehorende werkproducten nodig zijn om de requirements op te stellen en te implementeren.
Ik zal je de kern van use case 2.0 uitleggen.
Use case slices
Voor toepassing binnen agile trajecten zijn er use cases slices geïntroduceerd en kun je spelen met het detailniveau van de use case beschrijvingen. In use case 2.0 deel je de use cases op in slices, die je vervolgens op de product backlog plaatst. Deze use case slices zijn te vergelijken met kleine user stories.
Het onderkennen van slices is relatief eenvoudig omdat ze je ze rechtstreeks uit de mogelijke paden door de use case (flows) afleidt. Zo waarborg je dat elke use case slice businesswaarde heeft.
Detailniveaus
In use case 2.0 is het niet meer nodig om de use cases volledig uit te werken. Zeker in agile trajecten is het vastleggen van alle details onwenselijk. UC 2.0 heeft daarom voor al haar werkproducten verschillende detailniveaus gedefinieerd. Voor een use case beschrijving zijn dat bijvoorbeeld ‘contourschets’, ‘detailschets’ en ‘volledig beschreven’. De detailniveaus voor een use case model zijn ‘businesswaarde vastgesteld’, ‘systeemgrens afgebakend’ of ‘gestructureerd’.
Je kunt dus het voor jouw praktijksituatie passende detailniveau kiezen. Dat is onder andere afhankelijk van de de inrichting van het project, van het contact met de business en van de volwassenheid van het agile team. Het advies is om met het laagste niveau te beginnen en pas meer details toe te voegen wanneer het team informatie mist.
Activiteiten
De activiteiten die je moet uitvoeren om de requirements op te stellen en te implementeren, worden uitgebreid toegelicht in het e-book Use Case 2.0. Hier volgt een samenvatting.
Je begint met het vastleggen van de belangrijkste use cases en actoren in een initieel use case model. Die vul je later, wanneer er een extra actor of use case op tafel komt, aan. Vervolgens werk je van de voornaamste use cases de basis- en alternatieve flows uit, voor zover nodig om de use case op te delen in slices.
Het is niet nodig om een use case meteen helemaal op te delen in slices. Begin met de slices die de meeste businesswaarde leveren of belangrijke risico’s afdekken. Doe daarna hetzelfde voor de andere use cases met hoge prioriteit. De eerste slice van een use case is altijd gebaseerd op de basisstroom. Dit is namelijk de meest directe manier voor de gebruiker om zijn doel te halen.
Kort voordat een use case slice door het agile team opgenomen wordt in een sprint, werk je die slice samen met de business uit. Dat doe je door de use case beschrijving verder te detailleren en door testcases te definiëren. Testcases zijn belangrijk voor het agile team, omdat ze vertellen wanneer de use case slice succesvol geïmplementeerd is.
Use case 2.0 in hybride omgevingen
Door haar flexibiliteit en de structuur die use case 2.0 biedt, is het in hybride omgevingen een serieus alternatief voor de user story techniek. Het geeft meer houvast en je hoeft geen use cases meer om te schrijven naar user stories of andersom. Tijdens de transitie en groei naar een volwassen agile organisatie, kun je het detailniveau van de producten eenvoudigweg mee laten bewegen met de afnemende behoefte aan detail.
Zou use case 2.0 ook voor jouw project een serieus alternatief kunnen zijn?
Laat me hieronder in het reactieveld weten:
- Of, en zo ja waarvoor, je op dit moment use cases gebruikt
- en waarom use case 2.0 voor jouw project interessant zou kunnen zijn
Nicole de Swart
Een interessante techniek! Bij mijn huidige project, welke bijna ten einde loopt, is het gebruik van deze techniek (helaas) niet meer toe te passen. Het blijft wel een techniek die ik ga onthouden voor de toekomst!
We gebruiken user stories om helder te krijgen wat we gaan maken. We volgens daarmee een Agile werkwijze.
We gebruiken use case 2.0 alleen voor systeemdocumentatie en overzicht (achteraf). We werken een use case alleen bij wanneer die echt gebouwd is.
Wij gebruiken nu de user story techniek en hebben meer inzcht nodig in de over-all structuur van het systeem en de systeemdocumentatie. De Use Case 2.0 techniek zou een oplossing hiervoor kunnen zijn.
Ik denk dat je aan use case 1.0 al genoeg hebt.
Wij gebruiken op dit moment geen use cases, maar use case 2.0 lijkt me wel heel handig om systeeemdocumentatie op te gaan leveren.
De kracht is vooral dat en het het hele proces ondersteunt, van voortraject t/m systeemdocumentatie.
Usecase 2.0 is goed bedacht.
We gebuiken nu zowel user stories als usecases en usecase 2.0 lijkt beide technieken te ondersteunen.
Interessant verhaal. Wij moeten onze systemen voor klanten documenteren. De huidige opzet van user stories is te beperkt voor documentatie. Het opdelen in slices lijkt hiervoor een goede oplossing te zijn, zonder dat we dagen aan het documenteren zijn. Graag ontvang ik meer uitleg.
We zitten in een hybride omgeving waar we aan de voorkant vooral Agile zijn maar zodra het ontwikkelde geimplementeerd wordt gaan we weer naar waterval.
Use cases gebruiken we vooral in projecten, voor onderhoud aan de applicatie gaan we steeds meer naar user stories en missen daardoor de toegevoegde warden van de use cases in documentatie.
Use case 2.0 is daarom interessant om eens te bekijken.
Ik denk dat in jullie situatie use cae 2.0 een betere optie is dan de user story techniek
Hi Nicole,
Lijkt me zeer handig, zeker de verschillende beschreven detailleringsniveaus. Ik zou graag meer uitleg en vooral voorbeelden ontvangen.
Op dit moment wordt er voornamelijk gewerkt met User stories, waarbij steeds vaker blijkt dat het grote geheel niet gedocumenteerd/vastgelegd is in bijvoorbeeld Use Cases. Om de user stories nu om te gaan zetten naar use cases of andere soort van systeemdocumentatie, is ook geen leuke activiteit, die zeker ook vanuit de business weinig meerwaarde lijkt te geven.
Dat je niets hoeft om te zetten van de ene naar de andere techniek is inderdaad een groot voordeel van use case 2.0.
Wij gebruiken User Stories maar ik vind het interessant om te bekijken of de Use Case 2.0 techniek voor ons interessant kan zijn. Niet alle requirements zijn wat mij betreft geschikt om als User Story vast te leggen.
Hallo Nicole, we zijn onlangs gestart met het schrijven van de acceptatiecriteria bij een user story m.b.v. Gherkin language, dit biedt al veel toegevoegde waarde om de user story verder te detailleren en de scope goed vast te stellen. Ik zou de use case 2.0 techniek m.n. willen onderzoeken voor het opstellen van systeemdocumentatie. Ik ben zeer benieuwd naar je ervaringen op dat vlak.
Wij werken met user stories (op de backlog) maar gebruiken een soort van use cases om overzicht te bewaren/ krijgen (is alle functionaliteit onderlegd?), ik ben wel benieuwd naar het beter gebruiken van use cases en daarmee ook naar uc 2.0. Alvast dank!
Use case 2.0 draait het om. Eerst de (basis structuur) van de use case en daaruit de slices/user stories afleiden.
Hallo Nicole,
Binnenkort begin ik bij een nieuwe klant waarbij ze nog vasthouden aan de waterval-methode, maar waarbij ze wel graag meer richting Agile/Scrum willen gaan… Deze transitie duurt inmiddels al een aantal maanden en ze zijn nog altijd niet volledig over. Dit zou voor mij misschien wel een mooie manier zijn om tijdens deze transitie toe te passen. Bedankt daarvoor.
Hi Nicole,
Lijkt me zeer handig, zeker de verschillende beschreven detailleringsniveaus. Ik merk dat de user story soms nog te weinig info biedt en een use case een mooie aanvulling kan zijn zonder teveel in de techniek te duiken.
Onze ervaring is dat User Stories alleen gebruikt worden voor sprintplanning, maar niet geschikt zijn als (ontwerp)document.
Daarvoor gebruiken we Use Cases.
User stories zijn ook “vluchtig” , in de zin van temporary vereist voor sprintplanning, maar zijn geen (onderdeel van) documentatie
Hi,
Wij werken met user stories die vaak te veel documentatie bevatten en te gespecificeerd zijn. We zijn op zoek naar een goede techniek om goede userstories te schrijven en te documenteren op of tot op het juiste niveau.
Dat jullie user stories te veel documentatie bevatten en te gespecificeerd zijn, ligt niet aan de techniek (welke techniek dan ook) vermoed ik. Er is een reden waarom jullie teveel documenteren en specificeren. Grote kans dat dit te maken heeft met traditionele krachten in jullie organisatie.
Wat het juiste detailniveau is (voor jullie), moet je zelf bepalen. Dat geldt ook voor use case 2.0.
Wij gebruiken user stories en hebben op deze wijze al een heel systeem gebouwd. Beschrijving van het systeem ontbreekt echter. Dat gaan we nu achteraf aanpakken dmv use cases. Deze werkwijze voelt erg inefficiënt. Ik zou graag willen experimenteren met use cases 2.0 om een beter systematiek te zoeken. De organisatie is hybride en vraag namelijk nog wel om uitgebreide documentatie.
Hallo Nicole, toevallig vandaag ter sprake gekomen dat we te snel de details in gaan door van must haves naar user stories te gaan zonder eerst een visie of het grotere plaatje te schetsen. Wellicht inspireert UC2.0 mij hierbij.
Een voordeel van het gebruik van de Use Case techniek die wij hebben ervaren is dat in tegenstelling tot FO’s een actuele beschrijving blijft bestaan. Het werkt zoals anderen ook aangeven hybride, en is meer gestructureerd dan user stories.
Wij zijn net gestart met het ontwerp van een compleet nieuw systeem. de businessrequirements en de objectmodellen zijn er al, en we zijn bezig om de eerste userstories met de business te bepalen. we zijn nog aan het nadenken over hoe de systeemdocumentatie vorm te geven. wellicht dat usecase 2.0 ons hierbij kan helpen.
Bij het onderhoud van een deel van onze systemen wordt gebruik gemaakt van user stories. Bij het oorspronkelijke ontwerp van die systemen is in sommige gevallen ook gebruik gemaakt van use cases , die echter later niet meer onderhouden zijn. Met Use Case 2.0 hadden we dit misschien kunnen voorkomen.
Ja, dat denk ik wel.
Wij gebruiken UseCases binnen BizDevOps om de functionaliteit van de systemen te borgen. De UserStories beschrijven wat er gemaakt moet worden, de UseCases de functionaliteit die gemaakt is. Deze documenten worden dus bijgewerkt op het moment er een UserStorie is die deze UC raakt. Daar hebben wij een stramien voor gevonden en ben benieuwd in hoeverre dit aansluit op de UseCase 2.0.
In een organisatie in transitie richting agile gebruiken we een soort van process document (soort van use case) die elke stap weergeeft en ervoor zorgt dat cross team de oplossing coherent is. Vervolgens worden de process stappen vertaald richting user stories.
In onze organisatie werken we met userstories, echter ben ik van mening dat we beter kunnen/moeten documenteren. Om deze reden wil ik me verder verdiepen in de use case 2.0 techniek om te beoordelen wat deze hierin kan betekenen.
Dit artikel is geloof ik van begin 2018, zijn er inmiddels meer ervaringsverhalen bekend van collega’s die met UC2.0 gewerkt hebben? De theorie klinkt supermooi, hoe hebben jullie de praktijk ervaren?
Hallon bedankt voor de interessante inzichten.
Wij gebruiken use cases voornamelijk voor het beschrijven van de functionele analyse. Daarna wordt er een technische analyse gemaakt, die dan aan de programmeurs wordt overgedragen en dit zowel voor ontwikkeling van nieuwe als aanpassingen aan bestaande software.
Aan de andere kant, verzorgen wij derde lijn support, waarbij bugs worden gefixt en verbeteringen worden aangebracht aan de hierboven geprogrammeerde functionaliteiten.
Idealiter is stap 1 ontwikkelen van nieuwe functionaliteiten en is stap 2 nooit nodig, maar door de complexiteit en door het zware legacy karakter van onze motoren, is dit een groot deel van de programmeertijd aan het innemen.
Persoonlijk heb ik de idee dat wij, in het eerste geval perfect scrum based kunnen werken volgens het agile framework, maar moet ik op zoek gaan naar scaled agile technieken om stap 2, die in 2-wekelijkse releases is georganiseerd te verdelen over de verschillende ‘sprints’ – als je het zo al kan noemen
Development is voor release N+2, system testing voor release N+1 en acceptatie testing voor release N.
Ik denk dat het gebruik van use case slices misschien wel interessant kan zijn, maar voor stap 1 zou ik eerder naar user stories gaan en in het tweede geval is dit volgens mij te klein om nog eens te slicen (ook omdat hier vaak geen functionele analyse voor vereist is, maar eerder een kort technisch onderzoek om het probleem te vinden en een fix te kunnen maken).