Verboden te betredenIn traditionele ICT-projecten stellen business/informatie analisten de requirements op tijdens een requirementsfase. Scrum kent geen requirementsfase en onderkent ook geen analistenrol. Dit betekent niet dat requirements onbelangrijk zijn binnen Scrum. Integendeel, Scrum heeft expliciet aandacht voor het voortdurend verfijnen en bijstellen van de requirements. De requirements blijven zo het steeds verder voortschrijdend inzicht weerspiegelen.

Het grootste verschil met de traditionele requirementsfase is dat het achterhalen van de requirements zo lang mogelijk wordt uitgesteld (‘until the last responsible moment’). Dit bespaart veel tijd en elimineert de noodzaak om een ‘voorraad’ aan requirements te beheren. We hebben immers allemaal ervaren dat het erg lastig, zo niet onmogelijk, is om een volledige, juiste en eenduidige baseline met requirements op te stellen. Bovendien tonen onderzoeken aan dat gedurende het project gemiddeld 35% van de requirements wijzigen. Reden genoeg voor agile aanpakken om requirements alleen ‘just in time’ op te stellen.

‘Just in time’ en ‘just enough’ requirements die continue in de pas lopen met de actuele business behoeften, bereikt Scrum door voortdurend requirements te verfijnen en bij te stellen.

Bij de start van het project

Om van start te gaan met een Scrum-project moeten een visie op het eindproduct en een product backlog aanwezig zijn. De high-level requirements zijn dan bekend en geprioriteerd. De product owner werkt (samen met de stakeholders en het team) alleen de requirements uit die het team in de eerste sprint gaat implementeren. Het opstellen van de eerste versie van de visie en de product backlog hoeft niet langer dan 2 weken te duren. Beide producten worden daarna veelvuldig getoetst en aangepast aan de actuele situatie en behoeften van de business. Dit is de verantwoordelijkheid van de product owner.

Tijdens de Sprint Planning Meeting

Requirements sprint ready

Tijdens de Sprint Planning Meeting, aan het begin van iedere sprint, licht de product owner de requirements (of beter de product backlog items) met op dat moment de hoogste prioriteit toe. Het team schat in hoeveel items ze in die sprint kunnen implementeren en zullen daarbij nadere toelichting over de requirements vragen van de product owner. Bovendien zijn alle product backlog items al eerder met het team besproken. In de weken voorafgaand aan de sprint planning meeting worden de requirements namelijk ‘sprint ready’ gemaakt. Dit wil zeggen het opsplitsen van product backlog items totdat ze zo klein zijn dat het team ze in enkele dagen kan implementeren. Bij het ‘sprint ready’ maken heeft de product owner de medewerking van het team nodig. Vaak gebeurt dit in planningpoker sessies.

Tijdens de sprint

De teamleden stemmen tijdens het ontwikkelen en testen van de software regelmatig af met de product owner. Ze stellen vragen over details van de requirements en vragen tussentijds feedback op de ontwikkelde software. Op deze manier kan de product owner tijdens de sprint al bijsturen en zijn er geen gedetailleerde specificaties van de requirements nodig.

Tijdens de Sprint Review Meeting

Requirements bijstellen

Iedere sprint sluit af met een sprint review meeting. Het volledige scrumteam en de belangrijkste stakeholders nemen hieraan deel. Het team laat zien voor welke requirements ze commitment had afgegeven en demonstreert de software die ze deze sprint heeft gerealiseerd. De stakeholders geven vervolgens feedback. Dit levert vaak waardevolle informatie op over de requirements en de prioriteiten van de stakeholders.

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