Voorbeelden van uitgewerkte schattingen
In het schattingsgesprek komen van begin tot eind concrete voorbeelden aan bod — inloggen, betalingen, migraties, pieken — en de vragen die moeten worden beantwoord voordat er over een getal wordt gestemd.
Hoe u een inlogfunctie kunt beoordelen: de verborgen aspecten — wachtwoordherstel, tweefactorauthenticatie, federatie, rate limiting, sessies — en de vragen die u moet stellen voordat er gestemd wordt.
Hoe u een SSO-integratie kunt inschatten: het werk speelt zich niet af in uw codebase, maar in de eigenaardigheden van de identiteitsprovider. De vragen die u moet beantwoorden voordat u een schatting maakt.
Hoe u een betalingsintegratie kunt inschatten: sandbox versus live, terugbetalingen, webhooks, idempotentie, PCI-toepassingsgebied. Het gesprek dat moet plaatsvinden voordat er ook maar één cijfer wordt vastgesteld.
Hoe u een zoekfunctie kunt inschatten: relevantie, rangschikking, faceting en wie de eigenaar is van de index. De vragen die van ‘een zoekbalk toevoegen’ een daadwerkelijke inschatting maken.
Hoe u een meldingssysteem kunt inschatten: kanalen, voorkeuren, ontdubbeling en leveringsgaranties. Waarom ‘een e-mail versturen’ stilletjes uitgroeit tot een project van zes weken.
Hoe u een bestandsupload kunt inschatten: maximale bestandsgrootte, virusscan, hervatbaarheid, opslag en bewaartermijn. Het slepen en neerzetten is het makkelijke gedeelte; de onderliggende processen vormen de echte uitdaging.
Hoe u een dashboard kunt beoordelen: gegevensbronnen, verversingsfrequentie, tijdzones, drill-down, machtigingen. De grafiek zelf is eenvoudig; de onderliggende gegevenspijplijn is het echte werk.
Hoe u een onbetrouwbare test kunt inschatten: waarom er twee schattingen nodig zijn in plaats van één, en waarom een tijdslimiet de voorkeur verdient boven discussies over punten wanneer het antwoord afhangt van wat u aantreft.
Hoe u een bug kunt inschatten als deze niet kan worden gereproduceerd: u kunt de omvang van de oplossing niet bepalen, alleen die van het onderzoek. Hoe u een tijdslimiet kunt stellen aan het onderzoek in plaats van te stemmen over een story die niemand kan inzien.
Hoe een prestatieverlies kunt inschatten: het gaat hierbij vooral om de diagnose, niet om de oplossing. Hoe kunt u de omvang ervan inschatten wanneer de oorzaak onbekend is en een SLO op het spel staat?
Hoe een door een klant gemelde bug te inschatten: de omschrijving op het ticket bepaalt de omvang. Hoe onderscheidt u een oplossing van slechts één regel van een reactie die de hele sprint in beslag neemt?
Hoe een databasemigratie in te schatten: backfill, vergrendelingsduur, uitrol en terugdraaien. ‘Een kolom toevoegen’ is één regel SQL; de schatting betreft de tweede klok.
Hoe een gegevensmigratie in te schatten: het overzetten van gegevens tussen systemen, afstemming en omschakeling. De transformatie duurt een uur; het opschonen duurt een kwartaal.
Hoe u een framework-upgrade kunt inschatten: waarom een grote versie-upgrade een project is en geen ticket, en hoe u dit kunt opsplitsen in stories waarvan u de omvang daadwerkelijk kunt inschatten.
Hoe u een upgrade van een afhankelijkheid kunt inschatten: de langdurige toename die N pieken in één ticket verbergt. Lees eerst de changelogs en maak vervolgens een inschatting van wat u hebt gevonden.
Hoe u de omvang van een CI/CD-herziening kunt inschatten: aangezien er voor het werk aan de pijplijn geen demo bestaat, kunt u het project opdelen op basis van wat kan worden geschrapt. Het project dat een heel kwartaal in beslag neemt en op de backlog staat vermomd als een refactor.
Hoe u de impact van een API-overstap naar een derde partij kunt inschatten: semantische verschillen, gelijktijdige werking en de aannames die verweven zijn met de eigenaardigheden van de oude leverancier. De nieuwe API lijkt slechts identiek.
Hoe u de invoering van een rate limit kunt inschatten: drempelwaarden, testperiodes, communicatie met klanten. Het schrijven van de code kost een halve dag; het bepalen van limieten waar niemand over klaagt, is het echte werk.
Hoe u de impact van een wijziging in het ontwerpsysteem kunt inschatten: de uitrol van tokens, verouderingstrajecten, de dekking van Codemod en de 200 plaatsen waar de oude component wordt aangeroepen. Breng de gevolgen voor de downstream in kaart.
Hoe u de omvang van een aanpassing op het gebied van toegankelijkheid kunt inschatten: a11y-problemen zijn functies die u bij de eerste versie niet hebt opgenomen. Waarom u de omvang van de probleemcategorie moet inschatten, en niet die van een enkel geval.
Hoe u de uitrol van een feature-flag kunt inschatten: gefaseerde percentages, kill-switches, toelatingscriteria en de opruimwerkzaamheden die niemand inplant. Een flag is een klein product, geen implementatie.
Hoe u een onderzoeksspike kunt inschatten: een spike is een tijdsblok met een te leveren resultaat, geen story. Hoe u kunt voorkomen dat deze stilletjes uitgroeit tot het werk dat oorspronkelijk in de scope was opgenomen.
Hoe u een prototype moet beoordelen: het is een eindproduct dat bedoeld is om van te leren, niet om te gebruiken. Hoe u kunt voorkomen dat het wegwerpbare prototype uitgroeit tot de productiecode waar niemand rekening mee had gehouden.
Hoe u een ML-experiment kunt inschatten: het is onderzoek in combinatie met techniek — het model is eenvoudig, het werk zit hem in de gegevens. Hoe u de omvang van een budget bepaalt, niet van een prognose.