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 back­log 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 business­waarde 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

Misschien vind je dit ook interessant

33 reacties

  • Thomas

    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!

  • johanholtman

    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.

  • Marco

    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.

    • Nicole de Swart

      Ik denk dat je aan use case 1.0 al genoeg hebt.

  • Marjan

    Wij gebruiken op dit moment geen use cases, maar use case 2.0 lijkt me wel heel handig om systeeemdocumentatie op te gaan leveren.

    • Nicole de Swart

      De kracht is vooral dat en het het hele proces ondersteunt, van voortraject t/m systeemdocumentatie.

  • Hans

    Usecase 2.0 is goed bedacht.
    We gebuiken nu zowel user stories als usecases en usecase 2.0 lijkt beide technieken te ondersteunen.

  • Berrie de Mik

    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.

  • Ton Willems

    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.

    • Nicole de Swart

      Ik denk dat in jullie situatie use cae 2.0 een betere optie is dan de user story techniek

  • Ray Nederpel

    Hi Nicole,
    Lijkt me zeer handig, zeker de verschillende beschreven detailleringsniveaus. Ik zou graag meer uitleg en vooral voorbeelden ontvangen.

  • Frank Wulms

    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.

    • Nicole de Swart

      Dat je niets hoeft om te zetten van de ene naar de andere techniek is inderdaad een groot voordeel van use case 2.0.

  • Leander

    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.

  • Angelique Pieters

    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.

  • Roos

    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!

    • Nicole de Swart

      Use case 2.0 draait het om. Eerst de (basis structuur) van de use case en daaruit de slices/user stories afleiden.

  • Arnoud

    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.

  • Jessica van Muiden

    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.

  • Herman

    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

  • Tiny

    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.

    • Nicole de Swart

      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.

  • Janine

    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.

  • Harm van den Berg

    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.

  • Ard Vialle

    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.

  • marco

    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.

  • John

    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.

  • Remko Hendrikse

    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.

  • Jeroen

    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.

  • Casper Steenbergen

    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.

  • Huub

    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?

  • Michael Hollants

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

Geef een reactie