Vastleggen en beheren van requirements in de vorm van werkbare user stories binnen DevOps

---

Wat is een user story?

Een user story beschrijft een behoefte vanuit het perspectief van een gebruiker.

👉 Dit kan zijn:

• een externe eindgebruiker 

• een klant 

• een interne gebruiker of collega 

👉 Het doel is om de focus te leggen op de gebruiker en de waarde die geleverd wordt.

👉 User stories worden gebruikt binnen Agile werkwijzen (zoals Scrum) om requirements te vertalen naar concreet werk.

👉 Ze vormen de basis van de product backlog en worden gebruikt voor sprint planning en uitvoering.

---

Doel van user stories

User stories worden gebruikt om:

• requirements begrijpelijk te maken 

• focus te leggen op gebruikerswaarde 

• samenwerking tussen stakeholders te verbeteren 

• de product backlog transparant te houden 

👉 Ze zorgen voor een gedeeld begrip tussen:

• Product owner 

• Developers 

• Stakeholders 

---

User story template

De volgende standaard wordt gebruikt:

								
Als [rol]

wil ik [functionaliteit]

zodat [waarde]

							

👉 Dit helpt om:

• consistentie te creëren 

• snel te begrijpen waar het om gaat 

• user stories te prioriteren 

---

Voorbeelden van user stories

1. Als student wil ik feedback ontvangen op mijn opdrachten zodat ik mijn prestaties kan verbeteren 

2. Als developer wil ik API-documentatie gebruiken zodat ik correcte integraties kan bouwen 

3. Als marketingmedewerker wil ik rapportages genereren zodat ik campagnes kan analyseren 

4. Als forens wil ik real-time OV-updates zodat ik mijn reistijd kan optimaliseren 

5. Als online shopper wil ik producten kunnen vergelijken zodat ik de beste keuze kan maken 

👉 In alle gevallen is duidelijk:

• wie de gebruiker is 

• wat de behoefte is 

• waarom deze waardevol is 

---

Relatie met requirements en use cases

User stories staan niet op zichzelf, maar maken deel uit van een groter geheel.

👉 User stories worden afgeleid van requirements en use cases en vormen de input voor development.

---

INVEST principe (kwaliteit van user stories)

Een goede user story voldoet aan het INVEST principe:

• Independent (Onafhankelijk)

→ kan los ontwikkeld worden 

• Negotiable (Onderhandelbaar)

→ ruimte voor gesprek en aanpassing 

• Valuable (Waardevol)

→ levert waarde op voor de gebruiker 

• Estimable (Schatbaar)

→ inschatbaar in effort 

• Small (Klein)

→ past binnen één sprint 

• Testable (Testbaar)

→ kan gevalideerd worden 

👉 Gebruik INVEST als checklist bij het schrijven van user stories.

---

De 3 C’s van user stories

User stories bestaan uit meer dan alleen tekst. Volgens de 3 C’s:

---

🔹 Card (kaart)

• De user story zelf 

• Korte beschrijving van de behoefte 

---

🔹 Conversation (gesprek)

• Uitwerking en detail 

• Afstemming tussen team en stakeholders 

---

🔹 Confirmation (bevestiging)

• Acceptatiecriteria 

• Bepalen wanneer de story “klaar” is 

---

👉 De user story is dus geen volledige specificatie, maar een startpunt voor samenwerking.

---

Acceptatiecriteria

Acceptatiecriteria maken een user story testbaar.

Gebruik bij voorkeur:

								
Given [situatie] 

When [actie] 

Then [resultaat]


							

👉 Acceptatiecriteria zijn de basis voor:

• testing 

• validatie 

• Definition of Done 

---

Gebruik binnen DevOps

Binnen Agile en DevOps worden user stories gebruikt als:

• backlog items 

• sprint items 

• input voor development 

👉 In Azure DevOps worden requirements vastgelegd als user stories binnen de backlog.

👉 Ze worden gekoppeld aan:

• tasks 

• bugs 

• testcases 

---

Best practices

• schrijf vanuit gebruikersperspectief 

• hou user stories kort en duidelijk 

• focus op waarde (niet techniek) 

• gebruik INVEST 

• voeg altijd acceptatiecriteria toe 

• link naar use cases voor detail 

• vermijd duplicatie van uitgebreide procesbeschrijvingen 

---

Veelgemaakte fouten

• te technische beschrijving 

• geen duidelijke waarde (zodat ontbreekt) 

• te grote stories 

• geen acceptatiecriteria 

• duplicatie van use cases 

• geen koppeling met requirements 

---