INVEST is een methode voor het creëren van goede User Stories. Het stelt ons in staat om te controleren of ze goed geformuleerde inhoud hebben en of ze betrekking hebben op de zakelijke waarde van het Product. En ook of hun grootte en bruikbaarheid goed zijn gekozen.
De beste User Story maken met INVEST – inhoudsopgave:
- Inleiding
- I voor Onafhankelijk
- N voor Onderhandelbaar
- V voor Waardevol of Verticaal
- E voor Schatbaar
- S voor Klein
- T voor Testbaar
- Samenvatting
Inleiding
INVEST is een acroniem dat is gemaakt door Bill Wake in 2003. Elke letter staat voor het begin van een woord dat een goede User Story kenmerkt. Volgens het INVEST-principe moet elke User Story:
- Onafhankelijk
- Onderhandelbaar
- Waardevol
- Schatbaar
- Klein
- Testbaar
We hebben meer geschreven over wat een User Story is in een apart artikel. Hier zullen we alleen vermelden dat het een beknopte beschrijving is van een nieuwe functionaliteit van het Product, geschreven in toegankelijke taal.
I voor Onafhankelijk
De eerste eigenschap van een goede User Story is zijn onafhankelijkheid. Dit betekent dat de beschrijving en kenmerken begrijpelijk moeten zijn zonder verwijzing naar andere User Stories. Maar vooral, de realisatie mag niet correleren met andere User Stories. Natuurlijk zal het niet volledige onafhankelijkheid zijn. Je kunt de creatie van een Product niet opdelen in volledig afzonderlijke modules. Het is echter cruciaal om te onthouden dat User Stories zo onafhankelijk mogelijk moeten worden gehouden. Dankzij dat, zelfs als een van hen niet in de implementatiefase komt of aanzienlijk wordt gewijzigd, de overige niet hoeven te worden aangepast. Als regel geldt: User Story moet een afzonderlijk en samenhangend geheel vormen.
N voor Onderhandelbaar
User Story moet onderhandelbaar zijn. Dit betekent dat het het Doel vaststelt, niet de manier om daar te komen.
Met andere woorden, het definieert een verwachte functionaliteit van het Product, niet een technische oplossing om te implementeren.
De onderhandeling over de User Story vindt plaats tussen de Product Owner en het Ontwikkelteam. De Product Owner stelt de implementatie voor van bepaalde functionaliteit van het Product, dat wil zeggen, zegt “Wat” te doen. De Ontwikkelaars zijn verantwoordelijk voor het beantwoorden van de vraag “Hoe”. Dat wil zeggen, onderhandelen over specifieke manieren om het probleem dat in de User Story wordt gepresenteerd op te lossen.
V voor Waardevol of Verticaal
In het acroniem INVEST staat de letter V voor twee kwaliteiten:
- Waardevol
- Verticaal
Beide onthullen de sleutelkenmerken van een goede User Story. Daarom hebben we besloten uit te leggen wat elk van hen betekent.
Waardevol
Een waardevolle User Story rechtvaardigt het zakelijke doel van de wijziging. Met andere woorden, het beantwoordt nauwkeurig de vraag waarom de wijziging moet worden doorgevoerd en waarom het belangrijk is vanuit het perspectief van de belanghebbenden.
Verticaal
De tweede eigenschap; Verticaal komt voort uit de Agile-methodologie. De verticale User Story bevat een nieuwe functionaliteit van het Product die zichtbaar is voor de Gebruiker. Dat wil zeggen, het richt zich niet op horizontale “prestatieverbetering” in een geselecteerde laag van het Product. Integendeel, het voegt een andere “laag” toe.
Met andere woorden, User Story beschrijft hoe de algehele werking van een Product kan worden gewijzigd door de vraag te beantwoorden Wat precies te verbeteren? Het betekent ook dat elke functionaliteit van het Product voortbouwt op bestaande oplossingen.
E voor Schatbaar
Een goede User Story moet schatbaar zijn. Dit betekent dat het duidelijk de reikwijdte van de wijzigingen moet definiëren die aan het product moeten worden aangebracht om de User Story als compleet te beschouwen. Dit stelt het Ontwikkelteam in staat om de tijd en moeite te bepalen die nodig zijn om het te voltooien.
De reikwijdte en moeilijkheid van een taak worden meestal geschat in eenheden die Story Points worden genoemd. Ze zijn relatief. En elk Ontwikkelteam werkt de waarde van Story Points in de praktijk uit op basis van eerdere ervaringen.
In aparte artikelen hebben we meer behandeld over de snelheid van het Ontwikkelteam en hoe deze te meten.
S voor Klein
User Story die door het Ontwikkelteam is geaccepteerd voor realisatie moet beknopt zijn. Dat wil zeggen, het mag niet langer zijn dan één Sprint. Als Ontwikkelaars tijdens de Sprint Planning ontdekken dat de User Story die door de Product Owner is voorgesteld te lang is, moeten ze deze splitsen in mogelijk onafhankelijke delen.
T voor Testbaar
De laatste letter van het acroniem INVEST staat voor testbaar. Dit betekent dat de Productwijziging die in de User Story wordt beschreven houdbaar en verifieerbaar moet zijn. Met andere woorden, het moet mogelijk zijn om te verifiëren of de oplossing die door de Ontwikkelaars is geïmplementeerd de veronderstelde waarde heeft geleverd aan een specifieke Belanghebbende.
De beste User Story maken – samenvatting
INVEST is een acroniem dat een goed geschreven User Story beschrijft. Het moet zijn:
- Onafhankelijk van andere User Stories. Zodat het kan worden gewijzigd of verwijderd uit de Product Backlog als dat nodig is.
- Onderhandelbaar. Het moet specificeren wat te doen, waarbij de keuze van hoe het te doen aan de Ontwikkelaars wordt overgelaten.
- Waardevol, dat wil zeggen, rechtvaardigt de zakelijke zin van het wijzigen van het Product. Of Verticaal, dat wil zeggen, presenteert een nieuwe functionaliteit van het Product die zichtbaar is voor de Gebruiker.
- Schatbaar, wat betekent dat het een definieerbare grootte en voltooiingscriterium heeft.
- Klein genoeg om in één Sprint te worden voltooid.
- Testbaar zodat met zekerheid kan worden vastgesteld dat het is geïmplementeerd.
Als je onze inhoud leuk vindt, sluit je dan aan bij onze drukke bijengemeenschap op Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
Caroline Becker
Als projectmanager is Caroline een expert in het vinden van nieuwe methoden om de beste workflows te ontwerpen en processen te optimaliseren. Haar organisatorische vaardigheden en het vermogen om onder tijdsdruk te werken, maken haar de beste persoon om ingewikkelde projecten werkelijkheid te laten worden.
Scrum Guide:
- Glossarium van basisbegrippen, rollen en noties
- Wat is Scrum?
- Scrum waarden
- Hoe implementeer je Scrum in jouw bedrijf?
- Scrum Team - wat is het en hoe werkt het?
- Wie is een Product Owner?
- De meest voorkomende fouten van de Product Owner
- Wie is de Scrum Master?
- De meest voorkomende fouten van de Scrum Master
- Welke statistieken en metrics moet de Scrum Master bijhouden?
- Ontwikkelteam in Scrum
- De meest voorkomende fouten van ontwikkelaars
- Scrum-artikelen
- Schaalbare Scrum
- Sprint Backlog
- Wat is de Product Backlog?
- Wat zijn User Stories?
- Het creëren van de beste User Story met INVEST
- De meest voorkomende fouten bij User Stories
- Gebruikersverhaal Acceptatiecriteria
- Schatting en Story Points in Scrum
- Planning Poker
- Team Schatting Spel
- Definiëren van Incremente
- Scrum evenementen
- Wat is een Burndown Chart?
- Voordelen en nadelen van de burndown-grafiek
- Kanban-borden in Scrum en Scrumban
- Snelheid in Scrum - Snelheid van het Ontwikkelteam
- Dagelijkse Scrum
- Sprintplanning
- Sprint Review
- Wat is een Sprint Retrospective?
- Veelvoorkomende fouten tijdens een Sprint Retrospective
- Product Backlog verzorging
- Hoe maak je een burndown-grafiek en hoe interpreteer je deze?
- Wat is een Sprint in Scrum?
- Samenwerking tussen Product Owner en Scrum Master