User stories dat klinkt best soft, misschien zelfs wel een beetje zweverig voor iets waarmee u uw project definieert. U heeft vast ook liever harde requirements. Toch verliezen de harde requirements het tegenwoordig van de softe user stories. En dat lijkt wel een beetje gek.

 

Als het gaat over requirements dan denkt iedereen meteen aan veel werk, lange lijsten, werk waar een specialist voor nodig is. Bijvoorbeeld een business analist of een requirements engineer. Wanneer het gaat om user stories dan klinkt dat tof en simpel en iets dat iedereen kan doen.

 

“Het lijkt alsof iedereen userstories kan maken”

Maar is dat slim? Om die vraag te kunnen beantwoorden is het belangrijk om stil te staan bij waarvoor user stories en requirements gebruikt worden. User stories en requirements vormen het pakket van eisen voor projecten. Vaak wordt het gebruikt in relatie tot software ontwikkelingsprojecten bijvoorbeeld tbv automatiseren, digitaliseren of robotiseren, maar het kan ook gebruikt worden in relatie tot bouwprojecten, organisatie veranderingsprojecten of andere projecten. Vaak gaat het dus over flinke investeringen.

 

“Dat laat u toch niet aan iedereen over of wel?”

Wat zijn user stories en requirements eigenlijk?

Laten we daarom even stil staan bij wat user stories en requirements eigenlijk zijn. Volgens de definitie van Nicole de Swart auteur hand boek requirements zijn requirements eisen die gesteld worden aan het gedrag of de kwaliteit van het systeem om te voorzien in behoeften van een belanghebbenden uit de business.

 

De definitie van een User Story is meestal iets als een kore beschrijving van wat een gebruiker wil kunnen en een beschrijving waarom hij dat wil bereiken. Zie bijvoorbeeld de Scrumguide.
Een User Story ziet er daarom meestal uit als:

 

 

“ Als [rol] wil ik graag [bepaalde functionaliteit] zodat ik [reden].”

 

Links om of rechtsom zowel User stories als requirements beschrijven dus een wens van een gebruiker om iets te bereiken en waar het aan moet voldoen. Dat is toch dan hetzelfde?

Eisen aan user stories en requirements

Toch zit er een addertje onder het gras en dat heeft te maken met de kwaliteitseisen die gesteld worden aan user stories en requirements.

 

Voor requirements geld over het algemeen dat ze SMART (bron wikipedia SMART) moeten zijn. SMART staat voor:  
  • Specifiek, zodat de behoefte concreet genoeg is om een passende oplossing te bepalen.
  • Meetbaar, zodat op basis van een meting aangetoond kan worden dat aan het requirement wordt voldaan.
  • Acceptabel, Een requirement is acceptabel als aan de geldende kwaliteiteisen wordt voldaan of dat gestelde doelen gehaald kunnen worden.
  • Realistisch, Realistisch wil zeggen dat het requirement opgelost kan worden met een haalbare of maakbare oplossing.
  • Tijdsgebonden. Met tijdsgebonden wordt aangegeven wanneer het requirement vervuld moet zijn, meestal binnen het project.

Waarborgen dat iets SMART is kost over het algemeen veel tijd om het zo op te schrijven dat er geen speld meer tussen te krijgen is. Maar het resultaat kan dan wel in beton worden gegoten en u weet zeker waar de oplossing  / het resultaat van het project aan gaat voldoen. 

 

Voor User Stories bestaat ook zo’n soort criterium genaamd INVEST (bron wikipedia INVEST)INVEST staat voor: 
  • Independent: met andere woorden functionaliteit die onafhankelijk van andere functies ontwikkeld kan worden.
  • Negiotable: dat wil zeggen dat het een ambitie uitspreekt om een doel te behalen de manier waarop mag over gediscussieerd worden.
  • Valuable: Hiermee wordt bedoeld dat de userstory een bepaalde waarde moet opleveren voor een van de stakeholders.
  • Estimatable: Dit betekend dat de omvang en complexiteit in te schatten moet zijn door het SCRUM TEAM
  • Small: Met small wordt bedoeld dat user story binnen een sprint gerealiseerd moet kunnen worden.
  • Testable. Last but not Least moet een userstory beschrijven hoe deze getest moet worden nadat die gerealiseerd is.

Waarborgen dat iets voldoet aan INVEST lijkt simpeler gezegd dan gedaan want hoe bepaal je als simpele gebruiker of iets Estimatable, Small of testable is als je nog nooit een (software ontwikkelings) project hebt gedaan.

 

“Misschien is dat best lastig voor een simpele gebruiker of niet”

 

Overeenkomsten tussen user stories en requirements

 

Ook al klinkt SMART anders dan INVEST, toch zijn de verschillen niet zo groot. Kijk maar eens goed:

 

 

 

Requirements VS Userstories
Specifiek Niet afhankelijk van iets anders dus – Independent
Meetbaar Zodat meetbaar is wanneer het af is. Testable
Acceptabel Zodat het voldoende waarde toevoegt voor de gebruiker Valuable
Realistisch Complexiteit is te overzien, inschatbaar Estimatable
Tijdsgebonden Het is maakbaar binnen de gestelde tijden Small
SMART = ITVES

 

 

 

Dus met andere woorden de kwaliteits eisen die gesteld worden aan requirements gelden ook voor user stories, Echter user stories hebben een extra eis. Namelijk de eis dat ze NEGIOTABLE mogen zijn, met andere woorden de user storie mag een ambitie uitspreken die niet perse gehaald hoeft te worden. Dit geeft een ontwikkel team / project team de ruimte om het requirement in te vullen op de manier waarop zijn denken dat het beste past binnen de gestelde tijd. Waardoor het project een grotere kans van slagen heeft.

 

Effect van requirements en user stories op een project.

 

Het voordeel van van te voren precies specificeren van waar de oplossing aan moet voldoen, lijkt dat je van te voren zou kunnen bepalen hoeveel je moet investeren. Echter de ervaring leert dat van te voren bepalen hoeveel iets gaat duren en dus hoeveel het gaat kosten niet zo nauwkeurig lukt. Zie bijvoorbeeld de Cone of uncertainty voor meer informatie

 

INVEST zorgt er voor dat je rekening kan houden met die onzekerheid, het zorgt er voor dat het resultaat van het project onderhandelbaar wordt, bijvoorbeeld dat het past binnen de beschikbaar gestelde middelen of zelfs niet uitgevoerd wordt.

 

Conclusie

 

Userstories of requirements, beschrijvingen vanuit het gebruikers persepectief of ten behoeve van het gebruikersperspectief maakt eigenlijk geen verschil. Zorg er voor dat u nu niet te veel tijd investeerd in waar de oplossing straks precies aan moet voldoen.

 

Met een FIxed Business Analyse van Virtual BA helpen wij u en uw gebruikers met het opstellen van de eisen en wensen waarmee u inzicht krijgt in wat u kan verwachten in uw volgende project. U mag zelf bepalen of u dat wil in de vorm van user stories of requirements!

 

Het ideale SCRUM Team

Het ideale SCRUM Team

Het ideale SCRUM Team SCRUM is hot, maar of het nu een zegen of een vloek is, daar zijn de meningen over verdeeld. Een van de belangrijkste key succesfactoren is het SCRUM Team. De inrichting van het team bepaalt het succes van het project. Immers in SCRUM bepaalt het...

Nieuw SCRUM Backlog Generator

Nieuw SCRUM Backlog Generator

Druk? Veel wensen van verschillende gebruikers maar eigenlijk geen tijd om het allemaal netjes te verwerken in goede User Stories? Maak dan gebruik van de Virtual BA – SCRUM Backlog Generator De SCRUM Backlog Generator van Virtual BA vertaalt losse emails, word...

Opgedroogde Backlog

Opgedroogde Backlog

De SCRUM purist zal nu zeggen als de backlog leeg is dan is het project klaar. Mission Accomplished. Iedereen mag naar huis en op naar het volgende project. In de werkelijkheid zal een backlog nooit echt leeg zijn, er zullen altijd wel "dingetjes" zijn die opgelost...