samen
werken
Story points in uren uitdrukken, mag dat?
Het is een vraag die veel mensen bezighoudt: moeten we Product Backlog Items uitdrukken in Story Points of in uren/tijd? En mocht je taken nou uitgedrukt hebben in Story Points, kan je ze dan niet ook gewoon in uren terugrekenen? Deze blog gaat over Story Points, wat de voor- of nadelen zijn en inzicht in de antwoorden op al je andere vragen over Story Points.
Wat is een Story Point?
Laten we beginnen bij het begin: Story Points zijn een tool die in Agile en bij Scrum gebruikt worden om in te schatten hoe hoog de ‘effort’ is om de Product Backlog Item van de Product Backlog te voltooien. Een Story Point geef je aan een Product Backlog Item en is daarmee een combinatie van:
De complexiteit van Product Backlog Item
- Hoe complex is het item vergeleken met andere Product Backlog Items?
- Is het een makkelijke of ingewikkelde taak?
- Zijn er afhankelijkheden voor het uitvoeren van de werkzaamheden?
De risico’s bij het uitvoeren van het Product Backlog Item
- Welke taken hebben we nu nog niet genoeg kennis van?
- Wat zijn de ervaringen met andere Product Backlog Items?
- Zijn er onzekerheden voor het uitvoeren van de werkzaamheden?
Effort of hoeveelheid werk
- Wat moet er allemaal gedaan worden om het item af te ronden?
- Is het klein/groot/gemiddeld?
- Hoeveel werk gaat het Product Backlog Item kosten?
Dus in plaats van te focussen op het aantal uur dat het werk in beslag neemt, kan het gebruik maken van Story Points je in staat stellen om objectievere inschattingen te maken en is de verdeling van werk beter te regisseren tijdens een Sprint.
Wanneer worden Story Points verdeeld?
Story Points worden normaliter gegeven bij een Refinement sessie, waarbij elk teamlid Story Points toebedeeld over afzonderlijke taken. Dit wordt ook wel in Scrum termen ‘pokeren’ genoemd.
Doordat iedereen afzonderlijk punten geeft, komen ervaringen uit het verleden met soortgelijke taken naar boven, maar ook verschillen in vaardigheden van verschillende teamleden (waardoor het gesprek niet tot emotionele discussies leidt). Door Story points te gebruiken wordt de discussie gestuurd om het te hebben over zaken als complexiteit en haalbaarheid, in plaats van discussies over randzaken.
Voordelen van Story Points boven inschatten in uren
Nu we het toekennen van Story Points weten, kunnen we bekijken welke voordelen van story points er zijn ten opzichte van op uren gebaseerde schattingen. Dit zijn namelijk:
1. Inschatten in Story Points gaat sneller
Het klinkt gek, maar teams die Product Backlog Items in uren uitdrukken gaan vaak naar een diepere laag. Onderzoek heeft aangetoond dat het inschatten tot 60% sneller kan, omdat zonder Story Points men minder gemakkelijk consensus bereikt om toezeggingen te doen voor hoeveel dagen het kost.
2. Story Points zijn relatief ten opzichte van elkaar
Het maakt dus niet uit of onze inschattingen juist waren, een beetje ernaast zaten, of compleet onjuist waren. Het gaat erom dat de inschattingen consistent zijn en blijven relatief ten opzichte van elkaar.
3. Story Points zijn hetzelfde voor iedereen (ook voor complexe taken).
Het maakt dus niet uit of een senior of junior ontwikkelaar de Story oppakt. Het gaat erom hoeveel meer een Product Backlog Item groter is dan een andere en zo kunnen ook complexe werkzaamheden goed objectief ingeschat worden.
4. Story points zorgt voor indirecte kennisdeling.
In een Agile team kan je veel verschillende teamleden hebben als een programmeur, een tester, ontwerper, Product Owner etc, maar door samen in te schatten leert iedereen ook van elkaars werk en zorgt dit indirect voor kennisdeling onderling.
5. Objectievere inschattingen
Story Points leiden over het algemeen tot objectievere inschattingen en zorgen vaak voor minder heftige of emotionele discussies
Kortom bij gebruik van Story Points kunnen Agile teams nauwkeurige en objectievere inschattingen maken, zonder toezeggingen, met meer focus op waarde en kennisdeling.
Nadelen bij het gebruik van Story Points?
Het gebruik van Story Points gaat niet automatisch bij elk team probleemloos. Soms kunnen er problemen opduiken bij het inschatten van Product Backlog Items, namelijk:
1. Story Points zijn minder intuïtief.
Mogelijk heb je het wel eens gehoord “deze taak voelt meer als 5 Story Points voor mij, terwijl de rest het een nummer 2 vindt”.
Het probleem van Story Points is dat ze op een gegeven moment niet meer intuïtief zijn en er meer gefocust wordt op het aantal Story Points in plaats van het werk wat verzet moet worden voor de bepaalde taak. Opmerkingen die ik wel eens hoor zijn: “Wat is het verschil tussen 2 of 3 Story Points?” of “Waarom kunnen we niet het gemiddelde nemen van 3 of 5 punten?”. Probeer in zulke gevallen de focus te houden op het werk dat voltooid moet worden.
2. Story Points worden lastig als een specifiek persoon het moet uitvoeren.
Het kan gebeuren dat voor een Product Backlog Item een senior ontwikkelaar uit het team het 3 punten toekent, terwijl een junior ontwikkelaar het als 13 punten inschat. Voor het gemak wordt er dan vaak gekozen om voor 3 punten te gaan, immers dan kost het vast ook de minste effort. Maar alle taken op een Sprint Backlog dienen door iedereen opgepakt te kunnen worden, ofwel het kan tot problemen leiden als toch de junior ontwikkelaar het op moet pakken.
3. Story Points kunnen lastig zijn voor niet-projectgerelateerde taken.
De meeste Product Backlog Items worden vertaald in User Stories, maar het inschatten van bugs oplossen, emails schrijven of andere ‘reguliere’ taken maakt het lastig om dit als Story Point in te schatten.
Dus Story Points in uren uitdrukken?
Kortom als de bovenstaande voor- en nadelen in beschouwing worden genomen, kunnen we de centrale vraag beantwoorden. “Is het uitdrukken van Story Points in uren een goed idee?” Het antwoord met alles afwegende: nee, probeer het te voorkomen en houd het in punten!
Het uitdrukken van Story Points in tijd neemt het grootste voordeel van Story Points weg. Door gebruik te maken van Story Points zorg je ervoor dat teamleden, junior of senior, samen de hoeveelheid werk kunnen inschatten door goed samen te communiceren en kennisdelen.
Door Story Points te gebruiken kunnen teamleden in een open discussie samen besluiten hoeveel werk een Product Backlog Item voor het gehele team is. Een senior ontwikkelaar kan bijvoorbeeld wel een bepaalde Product Backlog Item in een bepaalde tijd voltooien, terwijl een junior persoon er 4x zolang over zal doen: samen kunnen ze wel overeenkomen dat het 2 punten als Story Point waard is.
Vervolgens kunnen ze naar een ander Product Backlog Item kijken en bepalen of hoeveel meer effort/complexiteit/risico bevat ten opzichte van de vorige. Immers alle taken op een Sprint Backlog dienen door iedereen opgepakt te kunnen worden, ofwel het kan tot problemen leiden als toch de junior ontwikkelaar het op moet pakken.
Kortom de grootste voordelen van Story Points zijn: dat je in een open discussie abstracte cijfers geeft, de Story Points voor iedereen geld in een team en het zorgt voor objectievere schattingen. Als je Story Points uitdrukt in uren vallen veel voordelen weer weg, dus daarom het advies om enkel bij de Story Points te houden.
Ben je naar aanleiding van dit artikel enthousiast geworden over Story Points en hoe ze jouw Scrum Team kunnen verder helpen? Heb je vragen of wil je er gewoon eens over praten? Neem contact op via 020 2614 195 of info@agilescrumgroup.nl en één van onze consultants helpt je graag verder.
Ook interessant:
- Scrum Transparency: voordelen van het werk visualiseren
- Agile mindset: wat is het en hoe ontwikkel ik het? (+3 werkvormen)
- Welke rollen zijn er in Kanban?
