Requirements in scrum van groot belang

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 ontwikkelteam 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

requirements in scrum planning meetingElke sprint start met een sprintplanning meeting. 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.

Het ontwikkelteam stelt 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 ontwikkelteam besproken tijdens een product backlog refinement meeting. 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 het ontwikkelteam.

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 het ontwikkelteam en de product owner (of gebruiker) over de gewenste werking van de softwareZo 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 meeting. 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.


Gratis e-book ‘Vliegende start als agile analist’

Met 25 do’s en don’ts 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:

Tips voor de moderne analist

Je ontvangt eens per maand een nieuw artikel. Net zoals meer dan 5.500 collega abonnees.

Copy link
Powered by Social Snap