Voorbeelden van uitgewerkte schattingen

Hoe u een inlogfunctie kunt beoordelen: de verborgen reikwijdte (wachtwoordherstel, tweefactorauthenticatie, federatie, rate limiting, sessies) en de vragen die moeten worden beantwoord voordat er gestemd kan worden.

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 een zoekfunctie kunt inschatten: relevantie, rangschikking, facettering 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 het uploaden van een bestand kunt inschatten: maximale bestandsgrootte, virusscan, hervatbaarheid, opslag en bewaartermijn. Het slepen en neerzetten is het makkelijke gedeelte; de techniek erachter is waar het om draait.

Hoe u een dashboard kunt beoordelen: gegevensbronnen, verversingsfrequentie, tijdzones, drill-down, toegangsrechten. De grafiek zelf is eenvoudig; de gegevenspijplijn erachter is het echte werk.

Hoe u een onbetrouwbare test kunt inschatten: waarom het om twee schattingen gaat, en niet om éé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 die niet reproduceerbaar is: u kunt de omvang van de oplossing niet bepalen, alleen die van het zoekproces. 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 schat u een door een klant gemelde bug in: de omschrijving op het ticket bepaalt de omvang. Hoe maakt u onderscheid tussen een oplossing van één regel en een reactie die de hele sprint in beslag neemt?

Hoe u een databasemigratie kunt inschatten: 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 de 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, moet u het 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, dubbele uitvoering 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: toegankelijkheidsproblemen zijn functies die u de eerste keer niet hebt geïmplementeerd. 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 buiten het bereik ervan viel.

Hoe u een prototype moet beoordelen: het is een opleverbaar product 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 een prognose.