Waarvoor je epics, user stories, use cases, features etc gebruiktRequirements, user stories, taken, use cases, scenarios, epics, features, thema’s, acceptatiecriteria. Kun jij ze allemaal nog uit elkaar houden?

In de wijze waarop organisaties en projecten met requirements, user stories, use cases etc omgaan, zitten grote verschillen. Is dat erg? Nee, tot op zekere hoogte zijn verschillen in de werkwijze juist goed. Je moet je werkwijze immers afstemmen op jouw praktijksituatie.

Wanneer gebruik je in jouw situatie features, user stories, use case, scenario’s etc.?

Laat ik beginnen met je gerust te stellen. Het is niet de bedoeling om ze allemaal te gebruiken. Het zijn namelijk (op taken na) allemaal verschijningsvormen van requirements. Sommige bestaan al heel lang en andere zijn in de agile wereld ontstaan. Ook als je in een hybride omgeving werkt en een mix van agile en traditionele technieken toepast is het ‘overkill’ om ze allemaal te gebruiken.

>> Wat je in een puur agile omgeving gebruikt:

  • User stories, epics, acceptatiecriteria en eventueel thema’s. Deze begrippen behoren allemaal tot de user story techniek
  • Taken. Dit zijn de werkzaamheden die nodig zijn om een user story te implementeren. Ze staan op de sprint backlog. Het zijn planningseenheden, geen requirements.

Wat niet iedereen weet is dat een user story geen vast formaat heeft. Een user story kan heel groot of heel klein of alles daartussenin zijn. Je kunt een grote user story opdelen in kleinere user stories. Net als een rotsblok uitteen kan vallen in stenen van verschillende formaten, zoals in de afbeelding.

Hele grote user stories hebben de naam epic gekregen. De exacte omvang van een epic is niet gedefinieerd en niet van belang. Het geeft alleen aan dat de user story groot is, dat er nog geen details over bekend zijn en dat hij voorlopig niet gebouwd wordt.

Voordat een user story in een sprint opgenomen wordt moet hij klein genoeg zijn om in minder dan een halve sprint te realiseren en de benodigde detailinformatie bevatten om dat in te kunnen schatten. Het is gebruikelijk om die detailinformatie op te nemen als acceptatiecriteria.

Thema’s worden minder vaak gebruikt. Ze zijn bedoeld om allerlei user stories die over een bepaald onderwerp gaan te groeperen, zodat je er gemakkelijk naar kunt refereren. Gebruik alleen een thema als daar behoefte aan is.

>> Wat je in een hybride omgeving gebruikt

Afhankelijk van wat traditioneel denkende stakeholders gewend zijn, kan het verstandig zijn om de user story techniek te combineren met:

  • Features. Deze grote brokken functionaliteit lijken qua omvang op epics. Kies daarom een van beide.
  • Use cases. Voor het uitgebreid vastleggen van requirements zijn use cases veel meer geschikt dan user stories.
  • Scenario’s. Deze geven een bepaalde volgorde weer en komen in meerdere contexten voor, bijvoorbeeld in een use case scenario, gebruikersscenario, testscenario.

Use cases zijn prima te combineren met de user story techniek als je niet ontkomt aan het vastleggen van gedetailleerde requirements, bijvoorbeeld als:

  • De business vooraf (gedetailleerd) vastgelegde requirements wil
  • Het ontwikkelteam de requirements tot in detail gespecificeerd wil hebben
  • De functioneel beheerders uitgebreide systeemdocumentatie willen

Als minimaal 2 van deze voorbeelden op jou situatie van toepassing zijn, is het niet logisch om de user story techniek te blijven gebruiken.

Ik zou dan overstappen op use case 2.0, de agile versie van de use case techniek. Dan kun je je werkwijze eenvoudig aanpassen aan het agile niveau van je stakeholders en (ongemerkt) steeds meer agile gaan werken. Het omzetten van use cases naar user stories of andersom hoeft dan ook niet meer.

Meer weten of use case 2.0? Geef dat dan even aan in het reactieveld hieronder. Bij voldoende belangstelling schrijf ik er de volgende keer een blogartikel over.

Succes met de requirements,

Nicole de Swart

Vond je dit artikel interessant? Deel het dan met je vakgenoten via de share knoppen aan de zijkant.

Gratis e-book Vliegende start als agile analist

Met 25 do's en dont's voor agile requirements en eens per maand een agile requirements tip

Nicole de Swart

Nicole de Swart

Requirementstechnieken expert

Ik help je de juiste mix van agile en traditionele requirementstechnieken toepassen

Volg Nicole op:

Share This