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
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?
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/
Dank je wel voor de links, Nicole, daar kan ik wat mee.
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.
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 hetgeen aanpassen dat voor jullie niet goed blijkt te werken.
Dag Gerco,
Je schrijft: “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.”
De Sprint Review is oorspronkelijk ook helemaal niet bedoeld om requirements te valideren. Dat is wat veel mensen er zelf van maken; “tijdens de demo komt de goedkeuring van de business”.
De Sprint Review is een werkoverleg tussen Scrum Team en Stakeholders. Daarin wordt door het team gedemonstreerd wat ze de afgelopen Sprint afgerond hebben (helemaal klaar en releasable, conform de Definition of Done) en hebben aanwezigen wel de mogelijkheid om daarop te reageren, maar het is geen validatie. Het is immers al klaar en kan, indien de PO daartoe besluit, gereleast worden. Er wordt wel gekeken wat het Sprint Doel was en of dat gehaald is.
Valideren van losse items (requirements) doet het team (incl. PO) zelf tijdens de Sprint a.d.h.v. de acceptatiecriteria die o.a. tijdens de refinement nog besproken zijn. Als gebruikers toch niet tevreden zijn of van gedachte veranderen t.a.v. het opgeleverde, kan de PO daarvoor eventueel nieuwe Product Backlog items aanmaken, die in een latere Sprint opgepakt kunnen worden (mits de PO het de moeite waard vindt).
Tijdens de Sprint Review wordt ook gekeken naar waar men nu met het product staat en welk doel men voor de komende Sprint heeft. Aanwezigen kunnen daarop reageren, bijvoorbeeld door feedback te geven op basis van ervaringen met eerdere releases van het product. Dat kan heel waardevol zijn voor de PO en het team. Het kan ook zijn dat er marktontwikkelingen worden besproken (bijv. een concurrent komt met een nieuwe feature), waardoor de PO ervoor kiest om de volgende Sprint een (iets) andere koers te gaan varen om de concurrentie zo snel mogelijk het hoofd te kunnen bieden.
Dus zoals ik het zie is “bijsturing van de requirements vooral naar voren komt uit het gebruik van de nieuwe release” heel positief. Laat dat ook vooral ter sprake komen tijdens de Sprint Review. Vraag eventueel aan stakeholders naar ervaringen met de meest recente release waarmee men onlangs gewerkt heeft.
Interessante blog over de relatie tussen Scrum en requirements! Het benadrukt het belang van een flexibele en collaboratieve aanpak bij het beheren van requirements in een Scrum-context. Bedankt voor het delen van deze waardevolle inzichten!
Een inzichtelijk artikel over de synergie tussen Scrum en requirements management. Het benadrukt hoe het integreren van effectieve requirementstechnieken binnen Scrum de productontwikkeling kan stroomlijnen.