In traditionele ICT-projecten stellen business / informatie analisten de requirements op tijdens een requirementsfase. Scrum kent geen requirementsfase en onderkent ook geen analistenrol. Dit betekent echter niet dat requirements in scrum onbelangrijk zijn.

Integendeel, in agile en scrum zijn requirements een integraal onderdeel van het ontwikkelproces. Er is veel aandacht voor het voortdurend achterhalen en verfijnen van requirements. En bij gewijzigde inzichten pas je de product backlog aan. Voor requirements in scrum is het essentieel dat ze de behoeften van de business (voor zover bekend) goed blijven weerspiegelen.

Verschil met traditionele requirements

​Het grootste verschil met traditionele requirements is dat je requirements in scrum niet lang van tevoren helemaal uitwerkt. Je stelt het achterhalen van requirements zo lang mogelijk uit. In agile zeggen ze ‘Until the last responsible moment’.

Dit bespaart veel tijd en elimineert de noodzaak om een ‘voorraad’ aan requirements te beheren. Je hebt (vroeger) misschien ook wel ervaren hoe lastig het is om een baseline met requirements volledig, juist en eenduidig te specificeren. En het doorvoeren van wijzigingen in de requirements is veel werk.

We denken (of dachten) vaak dat het aantal wijzigingen wel meevalt. Diverse onderzoeken in waterval projecten hebben echter aangetoond dat gedurende een project gemiddeld 35% van de requirements wijzigen.

Reden genoeg voor agile aanpakken als scrum om requirements alleen just in time op te stellen.

Requirements in scrum proces geïntegreerd

Gedurende het hele ontwikkelproces verfijn je de op dat moment relevante requirements. Je werkt ze steeds just in time and just enough uit. Hoe dat in het scrum proces is geïntegreerd laten we hieronder zien.

Aan het begin van het traject

Vanaf het begin van het ontwikkeltraject moeten de high level requirements bekend zijn en geprioriteerd. Deze vind je terug in de productvisie en op de initiële product backlog. Daarnaast werkt de product owner (samen met de business stakeholders en het team) alleen de requirements uit die het team in de eerste sprints gaat implementeren.

Het opstellen van de eerste versie van de product backlog hoeft niet langer dan 2 weken te duren. De product backlog wordt tijdens het sprinten veelvuldig getoetst en aangepast aan de actuele situatie en de behoeften van de business. Dit is de verantwoordelijkheid van de product owner.

Requirements tijdens de sprintplanning

Elke sprint start met een sprintplanning. Input hiervoor is de ingeschatte en geprioriteerde product backlog. De product owner licht het beoogde doel van de sprint toe. En met welke user stories hij denkt dat dat sprintdoel gerealiseerd kan worden.

De ontwikkelaars stellen vragen totdat ze genoeg informatie hebben om aan te geven welke stories in die sprint passen. Vervolgens stellen de product owner en het team samen het sprintdoel vast.

Product backlog refinement

Alle user stories zijn al een keer eerder met het team besproken tijdens een product backlog refinement. In de weken voorafgaand aan de sprintplanning worden de user stories namelijk verfijnt ofwel sprint ready gemaakt. Dit wil zeggen dat je ze opsplitst in kleine user stories en dat je ze gedetailleerd uitwerkt. Dit doe je niet alleen maar samen met de business en de ontwikkelaars.

Requirements tijdens de sprint

De teamleden stemmen tijdens het ontwikkelen en testen van de software regelmatig af met de product owner. ​Ze stellen vragen over de op dat moment relevante details van de user stories. En vragen tussentijds feedback op de ontwikkelde software.

Op deze manier ontstaat een gesprek tussen de ontwikkelaars en de product owner (of gebruiker) over de gewenste werking van de software. Zo ontdek je tijdens de sprint meer over de requirements en kun je waar nodig gezamenlijk bijsturen.

Requirements tijdens de sprintreview

Iedere sprint sluit af met een sprintreview. Het volledige scrum team (incl product owner) en de belangrijkste business stakeholders nemen hieraan deel. Het team laat zien welke user stories ze geïmplementeerd hebben en demonstreert de software die ze deze sprint heeft gerealiseerd.

De aanwezige business stakeholders vraag je daarna om feedback. Dit is het voornaamste onderdeel van de sprintreview. Het levert vaak waardevolle informatie op over de requirements en hoe de stakeholders er tegenaan kijken.

User stories

De aanbevolen techniek voor het achterhalen van requirements zijn user stories. Omdat veel analisten, teams en organisaties niet op de goede manier met deze krachtige techniek omgaan, heb ik het e-book ‘Haal meer uit User Stories’ geschreven. Daarin lees je hoe je in minder tijd meer resultaat boekt door slim toepassen van user stories.

Nicole de Swart & Priya Soekhai

Misschien vind je dit ook interessant

5 reacties

  • Gerco

    Het vooraf uitwerken van requirements heeft als voordeel dat er een redelijke inschatting van de ontwikkelkosten / -inspanning gemaakt kan worden. Het nadeel ervan is dat tijdens het project deze aanpak voortschrijdend inzicht zorgt voor veranderende requiements en te leveren inspanning. Beter is dus starten met een roadmap / vision, maar hoe zorg je dan voor een redelijk kloppende inschatting? De context van deze vraag: Elk jaar in deze periode worden budgetten bepaald voor voorziene ontwikkelingen in het komende jaar en daarbij schiet men graag in de waterval-kramp; schijnzekerheid is beter dan geen zekerheid. Welke agile methoden kun je gebruiken om een redelijke inschatting te maken zonder requirements uit te werken en een voorontwerp te maken?

    • Nicole de Swart

      Goede vraag, Gerco. Hoe je redelijke (of zelfs betrouwbare) schattingen maakt zonder requirements op voorhand te hoeven uitwerken, heb ik een keer in een blogartikel beschreven. zie https://www.reaco.nl/blog/zo-geef-je-zekerheid-aan-het-management/

      Je schrijft terecht dat zekerheid niet te geven is. In plaats van schijnzekerheid, biedt agile voorspelbaarheid. Met een agile aanpak kun je garanderen dat je binnen tijd en budget blijft, maar niet welke functionaliteit er precies opgeleverd wordt. Dat mag de opdrachtgever / business zelf bepalen. Ze krijgen namelijk de mogelijkheid om elke sprint opnieuw de scope te bepalen. Meer hierover lees je in https://www.reaco.nl/blog/hoe-je-met-agile-requirements-goede-planningen-maakt/

      • Gerco

        Dank je wel voor de links, Nicole, daar kan ik wat mee.

  • Gerco

    Wij hebben de hier beschreven werkwijze op een aantal punten moeten aanpassen in ons scrum proces. Het bevragen van de product owner tijdens de sprint planning voldeed niet zo. Ten eerste had de product owner had niet antwoord op alle vragen, wat leidde tot “zoek x uit voor y”-workitems. Ten tweede bleek het team snel cognitief verzadigd door het voortdurend schakelen tussen verhelderen en schatten (dmv planningspoker). Voor ons werkt het beter om planning volledig te scheiden en de verheldering van work items samen te voegen met de backlog refinement. Dit doen we wekelijks in een zogenaamde DOR-sessie.
    De sprint review met demo levert meestal weinig validatie van de requirements op. De bijsturing van de requirements komt vooral naar voren uit het gebruik van de nieuwe release.

    • Nicole de Swart

      Perfect, dat jullie het verhelderen / uitwerken van de product backlog items tijdens de refinement doen. Dat is ook precies hoe Scrum het aangeeft. Ik zie nu dat ik het niet duidelijk in dit artikel had verwoord en heb de tekst bij ‘Requirements tijdens de sprintplanning’ meteen aangepast. Bedankt voor je reactie en daarmee indirect voor verbeteren van dit artikel.
      Goed trouwens dat jullie dingen uitproberen en aanpassen die voor jullie niet goed blijken te werken.

Geef een reactie