Eén van de verschillen tussen agile en traditionele requirements is de hoeveelheid informatie die je vastlegt. In agile specificeer je veel minder details dan we bij de waterval aanpak deden.
Maar substantieel minder details specificeren gaat niet vanzelf goed.
Geen wonder dat analisten ons vaak vragen: “Hoeveel requirements moet ik specificeren?” Ons uitgebreide antwoord lees je in dit artikel inclusief de samenvatting in een infographic.
Fundamenteel andere werkwijze
Minder specificeren kan alleen als je voor een fundamenteel andere werkwijze kiest!
Traditionele requirements worden hoofdzakelijk schriftelijk overgedragen. De kwaliteit van de specificaties is dan cruciaal.
Bij agile requirements is de schriftelijke overdracht grotendeels vervangen door directe afstemming tussen het agile team en de vertegenwoordigers van de business.
KORT voor de sprint verfijnen business en IT SAMEN de user stories.
Daardoor heeft iedereen de besproken user stories nog vers in het geheugen tijdens de sprint. Dat maakt nauwkeurige vastlegging overbodig.
Bovendien kijkt de product owner of andere vertegenwoordiger van de business mee met de realisatie tijdens de sprint, zodat zij meteen requirements kunnen verduidelijken, aanvullen en de ontwikkeling bijsturen waar nodig. Uiteraard met inachtneming van de scope van de sprint.
Hoeveel specificeren?
In een organisatie in transitie waarin de directe afstemming tussen de teamleden en vertegenwoordigers van de business nog niet naar wens verloopt, moet je op zoek naar een mengvorm van agile en traditionele requirements.
Wat het gewenste detailniveau van de specificaties is, is sterk afhankelijk van de inrichting van het ontwikkelproces.
Hoe meer het ontwikkelproces leunt op schriftelijke communicatie, hoe meer je moet vastleggen en hoe minder efficient en effectief het proces wordt.
In de onderstaande situaties werk je niet volledig agile en ben je dus genoodzaakt extra informatie vast te leggen:
A. Te ver vooruit werken
Als je met het opstellen van requirements/user stories meerdere sprints op het team vooruit loopt.
Naarmate je meer vooruit werkt, moet je meer tijd overbruggen. En daardoor moet je meer vastleggen om de informatie te kunnen onthouden.
B. Te weinig samenwerken
Als niet het voltallige agile team participeert in de afstemsessies (refinement, sprintplanning, sprintreview).
Teamleden die niet bij de besprekingen over de requirements aanwezig zijn, moeten op een andere manier de voor hen relevante informatie tot zich nemen (meestal schriftelijk).
C. Niet iteratief werken
Als je in één keer de juiste requirements voor het eindproduct probeert te vinden en onvoldoende gebruik maakt van kort feedbackloops.
Als je de requirements en de software niet met iteratieve verbeterslagen tot stand laat komen, is nauwkeurig vastleggen van de geaccordeerde requirements nodig voor de acceptatietest.
D. Traditioneel werkende ontwikkelaars
Als de ontwikkelaars alleen op basis van specificaties van de requirements willen bouwen.
Dan ontkom je niet aan gedetailleerde specificaties. Realiseer je dat die eis van ontwikkelaars ergens uit voortkomt, vaak uit slechte ervaringen uit het verleden.
Infographic
Het beknopte antwoord op de centrale vraag in dit artikel “Hoeveel requirements moet ik specificeren?”, vind je in de infographic hiernaast. Klik hier of op de afbeelding om de infographic te openen.
Minder flexibel
In bovenstaande situaties heb je niet genoeg aan alleen agile requirements. Je hebt meer specificaties nodig. Maar tegelijkertijd maken deze beschrijvingen je ook minder flexibel en dus minder agile. Bovendien kost het extra tijd en verhoogt het risico op interpretatieverschillen.
Blijf altijd kritisch en specificeer niet meer dan strikt noodzakelijk is.
TIP 1 – Houd bij alle informatie die je vastlegt sowieso het doel en de doelgroep goed voor ogen.
TIP 2 – Blijf alert op mogelijkheden om het detailniveau van de beschrijvingen terug te dringen.
De beste manier om dat te doen is door de samenwerking tussen business stakeholders en de agile teamleden te verbeteren en de werkwijze meer agile te maken. Ga stapsgewijs steeds meer mondeling afstemmen en informatie visueel delen. Dan ontstaat langzaam maar zeker minder behoefte aan gedetailleerde specificaties.
TIP 3 – Vooral als de samenwerking met de ontwikkelaars goed is en ze volop participeren in de product backlog refinements, bepalen zij wanneer de user stories ver genoeg uitgewerkt zijn.
Het criterium is namelijk dat er (net) genoeg details bekend moeten zijn om de omvang van de user story in te schatten.
TIP 4 – Voor meer tips lees het artikel Mijn 5 belangrijkste agile documentatietips.
Zoals bij al onze artikelen zijn opmerkingen en (kritische) vragen meer dan welkom. Zet ze gerust in het reactieveld hieronder.
Nicole de Swart & Priya Soekhai
Nicole,
Zoals altijd is er een “gulden” middenweg (daarom noemt die ook “gulden” – geen munteenheid). Teveel requirements is niet goed, zeker als je requirements met mogelijke oplossing verwart. Te weinig requirements is ook niet goed, want dan laat je zogezegd dingen over aan de verbeelding en dit wordt dan “guessing”.
Een domein waar de requirements niet gebaseerd zijn op goede data en eindigen in “benen zonder vlees” (of graten zonder vis als je dat liever hebt) zijn de user requirements en UX requirements. Daar wordt het raden als je geen data hebt, als het al raden wordt want meestal schitteren UX requirements in afwezigheid. Zonder een degelijke user research (meer dan wat interviews, wat gesprekken – dat is een absoluut minimum) zijn die data er nooit, inderdaad, nooit.
UX requirements zijn geen dingen zoals performantie, security, vertrouwen, foutpreventie, korte teksten en dergelijke. In het Kano model zijn dat geen “delighters”. UX requirements zijn bv “correct interpreteren van een dashboard” en dat past niet zomaar in een user story.
Dank voor je aanvulling Rik. Eens dat UX belangrijk is. Daar moet bij de meeste systemen inderdaad expliciet aandacht voor zijn. Mijn voorkeur ligt echter niet bij het vooraf opstellen van uitgebreide UX requirements, maar meer bij een iteratieve aanpak waarbij je de UX (en rest van de software) voortdurend verbetert met behulp van korte feedbackloops.
Deze tekst gaat compleet voorbij aan de definitie van acceptatiecriteria, shift left, ATDD of BDD, example mapping, executable specifications etc allemaal Agile technieken die helpen om het juiste te maken en herbruikbaar zijn, niet puur documentatie die snel verouderd is.
Hallo Carine, Ik ben het met je eens dat de agile technieken die je noemt zeer waardevol zijn en dat alles documenteren geen zoden aan de dijk zet. Dit artikel focust echter op het specificeren van requirements met o.a. als boodschap dat mondelinge afstemming effectiever is dan veel vastleggen. Ik kan niet alles in één artikel behandelen :-).