Kun jij ze allemaal nog uit elkaar houden? Requirements, epics, features, user stories, taken, use cases, scenarios, thema’s, acceptatiecriteria.
In de wijze waarop organisaties en teams met epics, features, 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 epics, features, user stories 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.
In een puur agile omgeving gebruik je
- Epics, user stories, 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 uiteen kan vallen in stenen van verschillende formaten, zoals in de afbeelding.
Heel 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. Zo klein dat de story in minder dan een halve sprint te realiseren is.
Daarnaast moet de user story de benodigde detailinformatie bevatten. Genoeg (maar ook niet meer) details om de omvang 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.
In een hybride omgeving gebruik je
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 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.
Hoe je je agile werkproces afstemt op je hybride omgeving ontdek je in de online masterclass Cocktail van agile en traditionele requirements.
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
- De ontwikkelaars de requirements tot in detail gespecificeerd willen 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 over 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.
Nicole de Swart
Ik heb wel oor naar het inzetten van use case 2.0. Is dit bedoeld voor in een agile omgeving of is het een “transitie” techniek voor omgevingen waar er hybride gewerkt wordt?
Use case 2.0 ondersteunt meerdere detailniveaus. Je kunt het in zowel agile, traditionele als hybride omgevingen inzetten.
Ik ben erg benieuwd naar use case 2.0!
Ik ben ook nieuwsgierig naar usecase 2.0
Hallo, ook ik wil daar graag meer over lezen
Ja, ook ik ben nieuwsgierig naar use case 2.0. Neem je dan als productowner/analist niet weer een stukje (implementatie/ontwerp) vrijheid van de ontwikkelaars af?
Het is inderdaad niet de bedoeling om er een ontwerp van te maken. Als je het bij het WAT houdt en niet het HOE (de oplossing) beschrijft, gaat het goed.
use case 2.0 lijkt me erg interessant
Use cases, taken user stories, epics, scenario’s. Dit kan van alles zijn, je definitie zal dit bepalen.
Zelf gebruik ik use cases op sea level, dit zijn taken die in de business worden uitgevoerd en een afgesloten geheel. Het plaatsen van een bestelling kan een use case op sea level zijn, inloggen is dat nooit(daar heeft de business niets aan, de systeembeheerder wel want die staat in voor de security).
Het mooie is dat dergelijke use cases quasi overeenkomen met epics en thema’s en zo een uitstekende backbone bieden voor het business deel van de user story map.
Creatief zijn met de technieken is cruciaal, de situatie bepaalt wat je precies nodig hebt. Dit is geen pleidooi voor anarchie, zomaar wat doen, integendeel. Bewust beslissen. Denk daar niet over na en je krijgt eenheidsworst.
Ik zou ook graag meer over use case 2.0 willen weten.
Een mooie samenvatting (NL maar er is ook een Engelse versie) is hier te vinden: https://www.ivarjacobson.com/publications/white-papers/use-case-20-ebook-dutch-version
Wat naar mijn mening in eerdere versies van een use case op zich al bestond, is dat een use case een heel mooie manier is om als kapstok te fungeren voor (functionele) stories. In use case 2.0 wordt e.e.a. wat explicieter neergezet. Off topic: Een totaal(!!) andere -maar ook werkende- aanpak is het opzetten van een story map (Jeff Patton). Je vangt met die techniek ook stories in een context waardoor je niet slechts ‘een lijst met stories’ hebt.
In dat e-book heeft Ivar Jacobson use case 2.0 inderdaad uitgebreid beschreven. Wist je dat ik meegewerkt heb aan de vertaling naar het Nederlands?
Ha, grappig – ik zie het! Ik ook 🙂
Ik werk vaak in situaties, waar het ene team werkt met user stories en andere teams met Use cases en functionele detail designs. Ik converteer naar mate de communicatie / transparantie dit vereist. Alle hulp is welkom, dus ik ben benieuwd naar Use case 2.0. Alvast dank Nicole.
Ik ben ook benieuwd naar Use case 2.0
De termen ‘epics’, ‘features’ en ‘user stories’ zou je kunnen overnemen uit het bekende SAFe framework. Deze termen worden steeds meer gebruikt en zijn heel duidelijk.
User stories etc zijn prima te gebruiken tijdens het voortbrengingsproces. Ze zijn duidelijk minder geschikt als (minimale) beheerdocumentatie. Zeker wanneer een applicatie al een paar jaar bestaat. Voor (beheer)documentatie is Usecase 2.0 prima te gebruiken. De bedenker, Jacobson, heeft daarvoor een mooi ‘verhaal’ geschreven. Je beeldt de user stories, die je daadwerkelijk gaat realiseren in een Sprint, af op flows in een use case. Het bijwerken kost meestal heel weinig tijd. Dus een use case bevat dan alleen datgene wat je daadwerkelijk gemaakt hebt.
Bedankt voor de tip ivm de documentatie! Het is altijd worstelen om een juiste methode te kiezen in het bos van ’termen’.
Dus ben ik ook benieuwd om meer te lezen over usecase 2.0
Ik zal graag je artikel over use case 2.0 lezen.
Enkele vragen bij user stories:
Als je user stories redelijk klein maakt, hoe hou je dan het overzicht. Door aan Epic te koppelen?
En in welke mate zijn user stories geschikt als documentatie.
Hoe verwerk je opmerkingen tijdens development in user stories, improvements, …
– Het werkt andersom. Je begint met epics en deelt die ‘just in time’ op in middelgrote en kleine user stories. Als het goed is heb je dan nooit heel veel kleine user stories tegelijkertijd, want zodra ze in een sprint opgenomen worden haal je ze van de product backlog af.
– User stories zijn uitsluitend bedoeld voor het voortbrengingsproces (dus totdat de story gerealiseerd is). Ze zijn niet geschikt als (systeem)documentatie.
– Ik zou een user story niet meer aanpassen tijdens development. Documentatie die bewaard moet blijven maak ik (zo lean mogelijk) tijdens de sprint als je precies weet wat er gebouwd is.
Volgens mij is een user story aanleiding om systeemdocumentatie te schrijven: hoe moet de opdracht uit de user story opgenomen worden in het systeem. Ik ga dan uitschrijven wat er gebouwd moet worden, documentatie is geen reverse engineering klusje.
@AJ: systeemdocumentatie kan prima onderdeel zijn van de realisatie van een user story. Normaliter neemt een team die dan op in de “definition of done”.
Ik ben ook benieuwd naar het combineren van Use Cases en User Stories
Graag meer informatie over UC 2.0.
Je hebt mij nieuwsgierig gemaakt.
Ik zou ook graag meer willen weten over use case 2.0
Ik wil ook meer weten,over use case 2.0
Een wat ouder artikel maar de learnings zijn nog steeds relevant: https://www.infoq.com/articles/use-case-20-slices-Dutch-Railways/.
Ik wil ook meer weten over Use Cases 2.0
Dito, lijkt me heel interessant!
Lijkt mij zeer interessant!