Traditionele SRS omzetten naar User Stories?

Veel traditioneel beheerde projecten beginnen met een Software Requirements Specification (SRS). Op een bepaald moment in het project wordt dan besloten om over te stappen naar een agile aanpak. In dat geval komt natuurlijk de vraag op of een SRS kan dienen als de nieuwe agile Product Backlog. Sommige teams overwegen zelfs om de SRS om te schrijven naar een Product Backlog met User Stories. Maar is dat echt nodig?

Voordat we ons op deze vraag richten, wil ik eerst kort toelichten wat ik precies bedoel met Requirements Specification of SRS. Ik heb gemerkt dat deze documenten per organisatie sterk kunnen verschillen. In principe verwijs ik echter naar een typisch document dat uitspraken bevat als "Het systeem zou moeten…".

Mijn advies past echter in feite bij vrijwel alle traditionele specificatiedocumenten. Dit geldt uiteraard voor elk document met geïntegreerde en genummerde eisen, ongeacht of alle statements daadwerkelijk zijn geformuleerd als "Het systeem zou moeten…".

Enkele nadelen van het gebruik van een SRS als Product Backlog

Bij een agile product heeft de Product Backlog twee belangrijke functies:
- Het dient als archief voor al het werk dat gedaan moet worden
- Het vergemakkelijkt het prioriteren van het werk

De Product Backlog vertelt een team dus welk werk er gedaan moet worden, en kan bovendien als planningstool worden gebruikt om het werk te ordenen. Een traditionele SRS daarentegen geeft alleen aan welk werk er bij een project gedaan moet worden.

Een SRS is er niet op gericht om requirements te schrijven die in een Sprint opgenomen kunnen worden, en ook niet om deze te prioriteren. Onafhankelijke requirements schrijven is op z'n best een ondergeschikt doel, wat goed te zien is aan de hiërarchische opbouw van de meeste SRS-documenten met hun genummerde requirements (1.0, 1.1, 1.1.1 enz.).

Zolang een SRS als puur requirementsdocument wordt gezien, levert dat geen enkel probleem op. Maar als de items van een SRS als Product Backlog Items moeten dienen en geprioriteerd worden, zal dat tot problemen leiden.

Met een SRS is het voor een team vaak niet mogelijk om requirement 1.1.1 te ontwikkelen zonder tegelijkertijd ook requirement 1.1.2 en 1.1.5 te ontwikkelen. Deze afhankelijkheden maken het een stuk lastiger dan wanneer je simpelweg de ene story na de andere uit een goed uitgewerkte Product Backlog zou selecteren en afwerken.

Het prioriteren van ondergeschikte items is bij een SRS net zo moeilijk als het identificeren van ondergeschikte features voor het creëren van een Minimum Viable Product.

Een Software Requirements Specification is goed geschikt als requirementsspecificatie. Het is goed in het vastleggen van wat een systeem of product moet doen. (Uiteraard gaat het niet in op alle agile aspecten van opkomende requirements (Emergent Requirements), samenwerking, voortschrijdende inzichten enzovoort. Ik ga er echter van uit dat deze zaken wel degelijk voorkomen.)

Mijn aanbeveling over SRS in de Sprint

In principe zou ik niet aanraden om je tijd op te offeren aan het herschrijven van een foutloze SRS. Natuurlijk zou het met het oog op de zojuist genoemde problemen best nuttig kunnen zijn om de SRS om te schrijven naar User Stories en een mooie Product Backlog, maar meestal is de moeite het gewoon niet waard.

Iemand zou er tijd voor moeten vrijmaken, maar diegene kan die tijd normaal gesproken veel zinvoller besteden. Ik zou er vooral van afraden om een SRS te herschrijven als andere teamleden op de nieuw geschreven Product Backlog zouden moeten wachten voordat ze met hun werk kunnen beginnen.

De Scrum Master of een ander teamlid moet een manier vinden om ook bij een SRS de voortgang te kunnen meten, en ervoor zorgen dat er geen requirements in verloren gaan. Normaal gesproken is het een goed idee om de kwaliteitsborging erbij te betrekken, om te waarborgen dat alles in de SRS is afgehandeld of in de Backlog is opgenomen.

Daarnaast is het belangrijk om de mensen die betrokken zijn bij het opstellen van de SRS-documenten mee te geven dat ze dit bij toekomstige projecten op een manier doen die beter compatibel is met Agile. Als je dat voor elkaar krijgt, kun je bij je volgende project de problemen vermijden die ontstaan door een discrepantie tussen Agile en een traditioneel SRS-document.

Deze tekst is afkomstig uit de blog van Mike Cohn en is door ons naar het Nederlands vertaald.

Niet-functionele eisen

=> Ontdek hier hoe je niet-functionele eisen omzet in User Stories.

Commitment georiënteerde Sprint Planning

=> Hier lees je waarom ik commitment georiënteerde Sprint Planning verkies boven velocity georiënteerde Sprint Planning.