Story Points: Vuistregel om vooraf de omvang van een SCRUM project te bepalen

Story Points zijn een cruciaal concept in Agile softwareontwikkeling. We gebruiken ze om de relatieve inspanning te schatten die nodig is om een ​user story te realiseren.

Stel een unitmanager komt bij je met een geweldig software idee. Het bedrijf kan hier mee grote voordelen behalen. Aan het eind van een eerste enthousiast gesprek vraagt hij: ”Wat gaat dat ongeveer kosten [aantal uren X tarief]”?

Hoewel precieze tijdsschattingen vaak ongrijpbaar zijn, kan het begrijpen van de onderliggende principes van Story Points ons hierbij helpen. Dit artikel zal de kernconcepten van Story Points verkennen, ingaan op effectieve schattingstechnieken zoals Planning Poker. Afsluitend bieden we tevens een praktische “vuistregel” die een snelle inschatting mogelijk maakt.

Wat zijn Story Points?

Bij Agile softwareontwikkeling zijn Story Points een maateenheid waarmee de relatieve inspanning kan worden geschat die nodig is om een ​​User Story of ander werkstuk te voltooien.

Hier is een overzicht:

• Relatieve schatting: Agile Story Points gaan niet over tijd (zoals uren of dagen). Ze vertegenwoordigen de algehele inspanning, complexiteit en onzekerheid die betrokken zijn bij het voltooien van een taak.
• Concentreer je op inspanning, niet op tijd, ze houden rekening met factoren zoals:
  Complexiteit: Hoe ingewikkeld is de taak? Zijn er veel afhankelijkheden of integraties?
  Onzekerheid: Zijn er onbekende risico’s of potentiële obstakels?
  Grootte: Hoeveel werk is het?
• Team-Based: Teams schatten gezamenlijk Story Points, vaak met behulp van technieken als Planning Poker. Dit bevordert gedeeld begrip en vermijdt tevens individuele vooroordelen.
• Voortgang bijhouden: Door het aantal voltooide Story Points tijdens sprints (korte ontwikkelingscycli) bij te houden, kunnen teams namelijk hun snelheid meten en de toekomstige sprintcapaciteit voorspellen.

Wat is het verschil tussen Story Points en User Stories?

Scrum User Story

Het is een korte, eenvoudige beschrijving van een kenmerk of functie die een gebruiker wenst. Ze worden vaak geschreven in de vorm “Als [gebruikersrol] wil ik [functie], zodat [voordeel].”  

Doelen van User Stories zijn:

• De gewenste functionaliteit vanuit het perspectief van de gebruiker definiëren.
• Ervoor zorgen dat het ontwikkelteam de behoeften en verwachtingen van de gebruiker begrijpt.
• Grotere projecten op te delen in kleinere, beter beheersbare delen.

Scrum Story Points

Story Points zijn een meeteenheid die we gebruiken om de relatieve inspanning te schatten die nodig is om een ​​User Story te voltooien. Niet op tijd, maar op factoren zoals complexiteit, onzekerheid en grootte. Er wordt doorgaans samengewerkt met het ontwikkelteam met behulp van technieken zoals Planning Poker.  

Het doel van Story Points is:

• Agile teams te helpen bij het plannen en prioriteren van werk.
• De voortgang bij te houden.
• De toekomstige sprintcapaciteit te voorspellen.

Fibonacci Story Points

In Agile softwareontwikkeling verwijzen Fibonacci Story Points naar het gebruik van de Fibonacci-reeks (0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, …) om de relatieve inspanning te schatten die nodig is om een ​​User Story te voltooien.  

Zo werkt het:

1. Relatieve schatting: in plaats van absolute tijdsschattingen (uren, dagen) gebruiken teams de Fibonacci-reeks om een ​​puntwaarde aan elk User Story toe te wijzen.
   Betekenis van de getallen:
   0: Het verhaal is ongeldig of kan worden verwijderd.
   1: Zeer kleine taak, gemakkelijk te voltooien.
   2: Iets complexer dan een 1-punten verhaal.
   3: Matig complexe taak.
   5: Complexer dan een 3-puntsverhaal, mogelijk met enige onzekerheid.
   8, 13, 21, enz.: Vertegenwoordigen steeds complexere en onzekerdere taken.  
2. Planning Poker:Teams gebruiken vaak een techniek die ‘Planning Poker’ heet om Story Points te schatten. Elk teamlid kiest een kaart met een Fibonacci-getal dat hun schatting voor het verhaal weergeeft.  
3. Discussie en consensus: Als er grote onenigheid is tussen teamleden, bespreken ze het verhaal verder totdat er consensus ontstaat over de schatting.  

Voordelen van het gebruik van Story Points Fibonacci:

• Focus op relatieve omvang: moedigt teams aan om zich te richten op de relatieve omvang en complexiteit van taken in plaats van op absolute tijdsschattingen.  
• Gaat om met onzekerheid: De toenemende afstanden tussen getallen in de reeks geven impliciet aan dat grotere taken inherent onzekerder zijn om nauwkeurig te schatten.  
• Verbeterde communicatie: vergemakkelijkt discussies binnen het team over de complexiteit en mogelijke risico’s die aan elk User Story zijn verbonden.  

Fibonacci Story Points bieden Agile-teams een flexibele en effectieve manier om de inspanning te schatten die nodig is om gebruikersverhalen te voltooien. Dit bevordert een betere planning, betere communicatie en een nauwkeuriger inzicht in de projectomvang.  

Vuistregel om een ​​projectraming te maken met behulp van Story Points (voordat er iets op papier staat)

Hoewel er geen algemene vuistregel is voor het schatten van een project in Story Points voordat er überhaupt werk op papier staat, volgen hier een algemene aanpak:

1. Hoogwaardige ontleding:

• Verdeel het project: Verdeel het project in grote features of epics.
• Concentreer je op de belangrijkste resultaten: Identificeer echter alleen de meest cruciale functionaliteiten en gebruikersverhalen die moeten worden opgeleverd.
• Maak een schatting op globaal niveau: Wijs zeer ruwe, algemene schattingen van de Story Points toe aan deze belangrijke kenmerken (bijv. 13, 21, 34, enz.).

2. Houd rekening met de belangrijkste factoren:

• Project Scope: Hoe complex is het project? Omvat het veel integraties, nieuwe technologieën of aanzienlijke onzekerheid?
• Expertise van het team: Beschikt het team over de benodigde vaardigheden en ervaring om de uitdagingen van het project aan te kunnen?
• Projectbeperkingen: Zijn er beperkingen qua tijd, budget of middelen die van invloed kunnen zijn op de projectplanning?

3. Gebruik analoge schattingen:

• Refereer aan vergelijkbare projecten: Als het team in het verleden aan vergelijkbare projecten heeft gewerkt, kunnen we deze historische data (snelheid, schattingen van Story Points) als richtlijn gebruiken.

4. Plan voor onzekerheid:

• Buffertijd: Zorg tevens voor een buffer in de vorm van tijd (of Story Points) voor onvoorziene uitdagingen, risico’s en mogelijke vertragingen.  

Belangrijke opmerkingen:

Door deze strategieën te volgen en rekening te houden met de beperkingen van vroege schattingen, kunnen we beter onderbouwde beslissingen nemen over de omvang en tijdlijn van ons project, zelfs voordat een gedetailleerde planning is gemaakt.

Story Points naar uren: Vroege schattingen in Story Points zijn inherent uitdagend. Het doel is daarom een ​​ruwe orde van grootte te krijgen, geen exacte voorspelling. Vroege schattingen zijn namelijk onnauwkeurig. Bovendien kunnen we Story Points niet direct omzetten in uren. Ze vertegenwoordigen namelijk relatieve inspanningen, complexiteit en onzekerheid, niet een vaste hoeveelheid tijd. Een andere schattingstechniek die wel het een aantal uren oplevert is Functie Punt Analyse (FPA). FPA is echter net als Story Points gebaseerd op ervaringscijfers.

Story Points effectief inschatten met Planning Poker

Planning Poker is een collaboratieve spelachtige techniek die we gebruiken in Agile-ontwikkeling om de relatieve inspanning te schatten die nodig is om een ​​User Story te voltooien. Het maakt daarvoor gebruik van de collectieve wijsheid van het team om tot een op consensus gebaseerde schatting te komen.

1. Voorbereiden:

• Verzamel het team: Zorg ervoor dat alle teamleden die betrokken zijn bij de ontwikkeling van de User Stories aanwezig zijn.
• Selecteer een User Story: Kies één User Story om te schatten.
• Kaarten voorbereiden: Elk teamlid ontvangt een set kaarten met de volgende waarden: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞ (oneindig). Sommige teams kunnen een aangepaste Fibonacci-reeks of andere variaties gebruiken.
• Maak het verhaal duidelijk: Bespreek het User Story om ervoor te zorgen dat iedereen dezelfde scope, vereisten en mogelijke uitdagingen begrijpt.

2. Individuele schatting:

• Elk teamlid kiest in stilte een kaart die hun individuele inschatting van de inspanning voor het verhaal weergeeft.
• Vermijd daarna voorbarige discussies en beïnvloeding door anderen.

3. Schattingen onthullen:

• Tegelijkertijd laat elk teamlid zijn gekozen kaart zien.

4. Bespreek discrepanties:

• Als er sprake is van een aanzienlijke spreiding in de schattingen (bijvoorbeeld 1 punt versus 20 punten), start dan een discussie:
  High Estimators: Leggen hun redenering uit. Welke factoren maken het verhaal uitdagender?
  Low Estimators: Leggen hun redenering uit. Zijn er bijvoorbeeld aannames of vereenvoudigingen die mogelijk ontbreken?
• Het doel is niet om consensus af te dwingen, maar om een ​​gedeeld begrip te krijgen van de complexiteit van het verhaal.

5. Herschatting (optioneel):

• Op basis van de discussie kunnen teamleden besluiten hun eerste schattingen te herzien.
• Herhaal stappen 2-4 totdat een redelijk niveau van consensus is bereikt (bijvoorbeeld maximaal twee punten verschil tussen de hoogste en laagste schattingen).

6. Noteer de schatting:

• Leg de overeengekomen Story Points schatting voor het User Story vast.

Tips voor een effectieve pokerplanning:

• Vermijdde invloed van de eerste schatting die wordt gegeven.
• Stimuleer open en respectvolle discussies.
• Als er vragen zijn die nader onderzoek vereisen, verplaats ze dan naar een apart gesprek.
• Evalueer het schattingsproces regelmatig en pas het aan indien nodig.
• Lees ook De Driepunten Techniek voor het schatten van kosten.

Door deze stappen te volgen, kan het team Planning Poker effectief gebruiken om User Stories te schatten, de projectplanning te verbeteren en uiteindelijk betere software te leveren.

Conclusie van de Story Points vuistregel

Story Points bieden opdrachtgevers in een vroeg stadium inzicht in de omvang van het werk. Het is echter cruciaal om ze op de juiste manier te gebruiken, hun beperkingen te begrijpen en de aanpak aan te passen aan de specifieke behoeften en context van onze de organisatie. Er blijft dus altijd een bepaalde mate van onzekerheid.

Disclaimer: Dit is een algemene leidraad. De specifieke aanpak verschilt namelijk per project, team en organisatiecontext. Deze informatie is uitsluitend bedoeld als algemene richtlijn en mag niet worden beschouwd als financieel of professioneel advies.

Discussieer mee op ITpedia LinkedIn of op Financial Executives LinkedIn.