Wat zijn Story Points, en waarom gebruiken we ze?

Voor veel teams die Agile werken met Scrum zijn Story Points een onderwerp voor discussie: “Moeten we ze nou wel of niet gebruiken om de grootte van User Stories in te schatten?” Dat hangt van de situatie af. Hieronder lees je wanneer het voor jouw team handig en onnodig is.

Wat zijn Story Points?

Story Points zijn een meeteenheid die wordt gebruikt om de relevantie, benodigde tijdsinspanning, risico en de complexiteit, ook wel de “effort” genoemd voor het uitvoeren van een User Story weer te geven. Door het gebruiken van Story Points kun je werk gemakkelijker prioriteren op de Product Backlog.

Over het algemeen worden de nummers uit de Fibonacci reeks gebruikt als basis gebruikt. Elk nummer is de som van de twee voorafgaande nummers. Dan krijg je dus: 0, 1, 2, 3, 5, 8, 13… etc. De reeks groeit dus exponentieel. Hoe hoger het getal des te meer “effort”. In Scrum schat je in hoeveel “effort” een PBI (Product Backlog Item) of User Story is, en juist het feit dat we het waarschijnlijk in een team niet eens zijn zorgt voor de discussie en het kennisdelen wat we nodig hebben om tot een betere inschatting te komen.

Wat zegt de Scrum Guide?

Geeft de Scrum Guide advies over Story Points? Je zou denken dat daar iets over in moet staan, maar niks is minder waar. Er staat heel mooi beschreven dat de teamleden die het werk doen verantwoordelijk zijn voor de inschattingen. Alleen hoe je dat doet? Dat kunnen de teamleden zelf bepalen.

HUH? ZEG DAT NOG EENS? Dat is een reactie die we met enige regelmaat in trainingen krijgen. Mensen vinden het natuurlijker om inschattingen te maken in uren of minuten in plaats van Story Points. En niemand vertelt je dat je dat niet mag (nee de Scrum politie bestaat niet).

Maar kijk maar eens wat er gebeurt als je tijdens een Sprint Planning inschattingen in uren of minuten maakt. De deelnemers aan de discussie zijn voornamelijk bezig met meer of minder uren: “Ik denk twee uur. Nou, ik denk drie uur.” Met als gevolg dat we geen discussie en geen kennisdeling hebben. Hierdoor kan er gedurende de rest van de sprint een hoop grijze gebieden en ruis ontstaan.

Hoe werkt inschatten met Story Points?

Als ik aan jou zou vragen om zonder te googelen in te schatten hoeveel meter hoog de Schiphol toren is zou je waarschijnlijk niet 1..2..3.. een antwoord paraat hebben. En als je met grote onzekerheid een antwoord geeft is het vermoedelijk ook ver buiten de richting van het echte antwoord.

Met Story Points maak je geen inschatting op absolute eenheden zoals tijd, maar ga je Relatief Inschatten. Je schat het nieuw werk in ten opzichte van een inspanning uit het verleden, of iets wat je al kent.

Als ik nu zou vragen of je de hoogte van de Burj Kalifa wolkenkrabber in Dubai kan vergelijken met de hoogte van de Schipholtoren kun je veel makkelijker antwoord geven. Bijvoorbeeld: waarschijnlijk 8 keer zo hoog. Een relatieve inschatting geeft mensen veel meer beeld.

Story Points voor Product Backlog Items

Als je Story Points gebruikt om Product Backlog Items in te schatten kun je hetzelfde bereiken. Daarbij is het wel van belang om een uitgangswaarde te hebben waar elk teamlid het mee eens is. Spreek met elkaar af om voor een simpele (een voor iedereen uitvoerbare) Product Backlog Item 2 punten toe te kennen. Dit zorgt ervoor dat iedereen weet welke “effort gelijk staat aan 2 Story Points.” Doe je dit niet dan wordt het appels met peren vergelijken.

Planning poker

Heel gemakkelijk gaat dit als je met je team planningspokerkaarten gebruikt. Dat ziet eruit als een gewoon kaartspel, maar dan met de fibonacci-reeks erop en nog wat toegevoegde symbolen als een kop koffie (als je denkt dat pauze zou helpen) en een vraagteken (als je het echt niet weet). Als je die kaarten gebruikt, gooien de teamleden tegelijkertijd de kaart van hun keuze op tafel als ze een User Story gaan inschatten.

Stel je hebt vijf teamleden en die leggen de volgende kaarten op: 5, 3, 8, 5, 5. Dan is het een goed gebruik om de twee extremen eens uit te vragen. Kortom teamlid met inschatting 3 en teamlid met inschatting 8 gaan met elkaar de discussie aan.

Waarom denkt de ene bijvoorbeeld maar dat het 3 punten is, terwijl de volgende maar liefst 8 punten toekent? In deze discussie delen teams veel kennis, en stellen zich qua inhoud wat kwetsbaarder en transparanter op dan wanneer het om een tijdsinschatting gaat. Wat een hoop ruis scheelt. In multidisciplinaire teams draagt dit bij aan het feit dat mensen sneller T-shaped worden, breder in hun ervaring en kennis, wat waardevoller voor het team en de organisatie is.

Denk eens aan de volgende vraag: Krijgt degene die de minste punten toekent dan ook de klus? Want die heeft waarschijnlijk de meeste ervaring of kan het kennelijk het effectiefst uitvoeren? Relatief inschatten in punten voorkomt dit soort “tegen elkaar opbieden” natuurlijk maar deels. Het is vooral de dialoog die van belang is en daarom is een Scrum Master van belang om het te faciliteren.

Nadelen Story Points ?

In de volgende gevallen kun je overwegen of Story Points nuttig zijn:

• Bugs of Ad hoc taken. Inschattingen kosten veel tijd en misschien kun je het probleem al oplossen in de tijd dat je aan het inschatten bent.
• Zonder goede Scrum Master kun je ellenlange discussies zonder einde krijgen.
• Story Points verschillen per team waardoor het lastig te vergelijken is en er soms verkeerde conclusies worden getrokken.
• Stakeholders moeten goed meegenomen worden met Story Points omdat die vaak nog wel in tijd denken.

Dus wel of geen Story Points gebruiken?

De meeste teams die met Story Points werken zijn er blij mee dat ze vooraf met het team goed kunnen verkennen wat die complexe klus nu precies inhoudt. Om op deze manier kennis goed te kunnen laten zien en over te dragen.

Want bij alle klussen, maar vooral bij complexe Scrum klussen, is inschatten een prognose. Niets meer dan dat. Werken met Story Points past daarom perfect bij het Empirische werken binnen Scrum. We schatten zorgvuldig in, en testen dat uit. We zijn transparant over wat we wel en niet weten en kunnen inspecteren of het loopt zoals dat waardevol is voor de klant. Zo nodig passen we aan.

Maar Story Points verplicht? Nee, verplicht is het niet.

Meer leren over Stories, Story Points en Story mapping? Bekijk onze User Story & Story mapping taining. Heb je vragen? Neem contact op via info@agilescrumgroup.nl of 020 2614 195.

Ook interessant:

• Wat is een Epic in Agile werken?
• De 8 kenmerken van een Agile organisatie
• Wat is een WIP limit, en waarom is het belangrijk?

Over de auteur: Mariska Hulsewé

Mariska is een Agile trainer en coach bij Agile Scrum Group. Zij heeft een grote interesse en internationale ervaring in de menselijke effectiviteit in organisaties, waarbij Agile leadership de rode draad vormt. Onderwerpen die daarbij o.a. bij horen zijn, los van leiderschap, faciliteren, influencing, coaching, branded customer service, faciliteren, pitchen en emotionele intelligentie in bedrijven. Mariska vindt het leuk om met diverse groepen mensen te werken aan op maat gemaakte programma’s.