Voorbeelden van story points: een referentieschaal van 1 tot 13
Zes backlogvoorbeelden om je team te helpen werk te vergelijken, aannames te bevragen en eigen referentiestories te kiezen.
Een story-point schatting geeft de relatieve omvang van werk weer voor een team, rekening houdend met inspanning, complexiteit en onzekerheid. Dat maakt een afgerond, bekend item een nuttige referentie om het volgende te bespreken. Atlassian’s schattingshandleiding legt deze relatieve benadering uit.
Een team kan bijvoorbeeld een bekende instellingwijziging 2 punten geven en een nieuwe notificatieworkflow 5. De relevante vraag is: welk extra werk verklaart het verschil?
De onderstaande voorbeelden horen bij een fictief team dat een gedeelde documentwerkruimte bouwt. Ze zijn vertrekpunten voor een gesprek, geen standaardwaardering voor functies. Jouw team kan redelijkerwijs andere waarden kiezen.
Zes voorbeelden op de schaal van één team
Ga ervan uit dat dit team al een componentenbibliotheek, toegangsrechten voor werkruimtes, een notificatieservice en geautomatiseerde controles rondom bestaande workflows heeft. Elke schatting omvat implementatie, review en de controles die nodig zijn om aan de defintie van klaar van het team te voldoen.
| Punten | Backlog-item | In dit voorbeeld inbegrepen | Waarom dit team het hier plaatst |
|---|---|---|---|
| 1 | Een lege activiteitstijdlijn uitleggen | Goedgekeurde tekst en een bestaande leegtoestandcomponent; geen nieuw gedrag | Een kleine, bekende wijziging met weinig beïnvloede toestanden |
| 2 | Laat werkruimtebeheerders de gedeelde weergavenaam wijzigen | Bestaand instellingenformulier, API en beheerrechtencontrole; validatie en opgeslagen/fouttoestanden | Een bekende route met enkele gedragscontroles; het referentie-item van het team |
| 3 | Documenten filteren op eigenaar | Bestaande filtercomponent en API-ondersteuning; resetgedrag en lege resultaten | Meer interactieve UI-toestanden dan de referentie, met een bekend datapad |
| 5 | Informeer een documenteigenaar wanneer iemand toegang aanvraagt | Bestaande bezorgservice; permissiecontroles, notificatie-inhoud, duplicaatafhandeling en een link terug naar het verzoek | Verschillende bestaande onderdelen moeten correct samenwerken |
| 8 | Documenteigendom overdragen binnen een werkruimte | Nieuwe overdrachtsoperatie; permissiewijzigingen, gelijktijdige bewerkingen en een auditlogboek | Een bredere toestandovergang met faalgevallen die zorgvuldige afstemming vereisen |
| 13 | Verplaats een map en de documenten naar een andere werkruimte | Bestemmingsrechten, koppelingen, gedeeltelijke mislukkingen en herstelgedrag | Te veel onderling verbonden beslissingen voor dit team om als één comfortabel item te houden; bespreek opsplitsen |
De aannames over de infrastructuur zijn belangrijk. Een team zonder notificatieservice zou in het 5-puntvoorbeeld extra werk schatten. Een team met een bewezen overdrachtsoperatie zou dat item mogelijk lager inschatten.
Deze cijfers zijn geen formule. Het tellen van UI-schermen, endpoints of acceptatiecriteria zal niet betrouwbaar tot dezelfde schattingen leiden.
Hoe de scope de schatting verandert
Denk aan 'de weergavenaam van een werkruimte wijzigen'. De tabel gaat uit van een beheerder die het gedeelde label in de instellingen aanpast, met een bestaand update-endpoint en permissiecontrole.
Wijzig nu de acceptatievoorwaarden:
| Versie | Scope | Illustratieve schatting |
|---|---|---|
| A | Wijzig het label in de werkruimte-instellingen; gebruik de bestaande opslaan-functie | 2 |
| B | Werk ook de uitnodigingsinhoud en gecachte navigatie bij; houd deze oppervlakken consistent als een update slechts gedeeltelijk slaagt | 5 |
| C | De naam bepaalt ook de openbare URL van de werkruimte; behoud oude links en behandel conflicten | Pauzeer om te verduidelijken, dan mogelijk 8 of opsplitsen |
Versie C stelt eerst een productvraag voordat het een schattingsvraag oplevert: moet het hernoemen de URL überhaupt wijzigen? Besluiten om een stabiele URL te behouden kan veel extra werk wegnemen.
Als een deelnemer 2 stemt en een ander 8, vraag dan beiden om te beschrijven welk gedrag ze meenemen. Ze kunnen allebei logisch nadenken over verschillende versies. Herschrijf de acceptatievoorwaarden voordat opnieuw wordt gestemd.
Kies referentiestories die je team herinnert
Kies twee of drie afgeronde items met duidelijke afbakeningen. Een kleine bekende wijziging, een gematigde workflow en een grotere maar begrepen wijziging geven het team betere vergelijkingen dan één abstract getal.
Maak bij elke referentie een korte notitie:
- Welk gebruikersresultaat leverde het op?
- Welke systemen en toestanden veranderden?
- Welke controle- en verificatiewerkzaamheden waren inbegrepen?
- Welke aannames maakten het eenvoudig of complex?
Vergelijk nieuw werk daarna met de dichtstbijzijnde referentie. "Dit lijkt op onze instellingwijziging, maar voegt twee permissiepaden toe" geeft deelnemers iets concreets om te bespreken.
Als het team geen gedeelde leveringsgeschiedenis heeft, kies dan een goed begrepen item als voorlopige referentie. Herzie dit na levering en houd de aannames zichtbaar. Het is niet nodig een perfecte schaal te maken voordat het team samen heeft geleerd.
Kopieer deze schattingsnotitie in een backlog-item
Gebruik het volgende als hulpmiddel bij de discussie in je backlog of teamnotities:
Gebruikersresultaat:
Inbegrepen gedrag:
Uitdrukkelijk uitgesloten:
Dichtstbijzijnde afgeronde referentie:
Waarom dit kleiner of groter is:
Onbekenden die de scope kunnen veranderen:
Beslissing: schatten / splitsen / onderzoeken
Afgesproken schatting, indien gereed:
Volgende verduidelijking en eigenaar, indien nodig:
Hier is een ingevuld voorbeeld voor het toegangsmelding-item:
Gebruikersresultaat: de documenteigenaar wordt geïnformeerd dat een lid van de werkruimte toegang heeft aangevraagd en kan het verzoek openen.
Inbegrepen: gebruik maken van de bestaande notificatieservice, controle van de rechten van de ontvanger, koppeling naar het openstaande verzoek en duplicaatmeldingen voorkomen bij herhaalde bezorgingspogingen.
Uitgesloten: herinneringsmails, dagelijkse overzichten en automatisch toekennen van toegang.
Referentie: onze 2-punts wijziging in instellingen gebruikt een bekende opslaan-route. Dit item combineert de paden van verzoek, rechten en bezorging, waardoor er meer coördinatie en faalmomenten zijn.
Open vraag: voorkomt de service al dubbele bezorging? De beheerder van de notificatieservice bevestigt dit, voordat we de schatting vaststellen.
In het fictieve scenario van de tabel bevestigt die controle herbruikbare bezorgondersteuning en stemt het team in met 5. Zonder deze bevestiging moet het team het extra werk bespreken voordat hetzelfde nummer wordt gebruikt. De referentie verklaart de vergelijking; het berekent het antwoord niet.
Gebruik voor de vergaderindeling de stapsgewijze Planning Poker-gids. Deze behandelt privé stemmen, bespreken van verschillen en het kiezen van de uitkomst van de volgende ronde.
Wanneer een nummer nog niet bruikbaar is
Ga terug naar verduidelijking wanneer een onbekende variabele het werk verandert. “Welke tekst moet de notificatie gebruiken?” heeft een andere onzekerheid dan “Staat de doelwerkruimte externe gebruikers toe?”
Voor het voorbeeld van het verplaatsen van een map kan het team eerst akkoord gaan met een kleiner gebruikersresultaat: het verplaatsen van één document tussen werkruimtes die de gebruiker beheert. Deze eerste stap vereist nog steeds duidelijke bestemmingsrechten, behoud van toegangsregels en veilige afhandeling van fouten zodat een onderbroken verplaatsing het document niet kwijtraakt of blootstelt aan verkeerde personen. Het verplaatsen van groepen documenten kan een apart item zijn. Het verkleinen van de batchgrootte beperkt het werk; het elimineert niet de noodzaak om met fouten om te gaan.
Na het splitsen moet elk item afzonderlijk worden geschat. De nieuwe waarden hoeven niet op te tellen tot 13: het team heeft de scope gewijzigd en meer over het werk geleerd.
Veelgestelde vragen door teams
Hoeveel uren zijn een 3-puntstory?
Er is geen universele conversie. De voorbeelden hier vergelijken werk binnen een fictief team. Als je een leveringsvoorspelling nodig hebt, gebruik dan je eigen leveringshistorie en huidige capaciteit, en bespreek onzekerheid apart van het puntlabel.
Is elke bug een 1-punt item?
Nee. Een reproduceerbare weergavefout met bekende oorzaak verschilt van intermitterend gegevensverlies waarvan de oorzaak onbekend is. Maak duidelijk wat je schat: de oplossing, een onderzoek, of beide.
Moet elk team een 13-punt story splitsen?
Nee. Hier markeert 13 werk dat dit specifieke team wil onderzoeken en splitsen. De grens van jouw team hangt af van referenties en de capaciteit om een item te begrijpen en te leveren.
Breng je referenties mee in Planning Poker
Kies enkele aankomende items, schrijf hun acceptatievoorwaarden op en houd je referentiestories erbij. Gebruik Agilo Planning Poker voor de schattingssessie van het team.
Maak een Planning Poker kamer aan zodra de items klaar zijn voor bespreking.
