Een schatting maken van een betalingsintegratie

Op het ticket staat „Stripe toevoegen”. In de tekst staat „een half kwart”.

De betalingsfunctie beschikt over een openbare API-interface die op één pagina past, en een beslissingsinterface voor intern gebruik die dat niet doet. Het selecteren van een aanbieder is een eenmalige piek van één dag. Het inrichten van het standaard afrekenproces neemt een paar dagen in beslag. Alles wat daarna volgt – het terugbetalingsproces, het beleid voor het herhalen van webhooks, de idempotentiesleutels, het afstemmingsrapport waar de financiële afdeling in de tweede maand om zal vragen – vormt de daadwerkelijke functionaliteit, en niets daarvan staat op het ticket vermeld.

Het verhaal waarin staat „Stripe integreren” is zelden het verhaal dat daadwerkelijk wordt ingeschat. Het verhaal dat wordt ingeschat is: „we kunnen geld ontvangen, het terugbetalen, aantonen dat we het hebben ontvangen en een betwiste afschrijving doorstaan.” Zolang de groep niet over die omvang stemt, is het bedrag slechts een schatting van iets anders.

Wat er in de kamer wordt gezegd

Backend: “Sandbox is eenvoudig. De bibliotheek doet het meeste werk.”

SRE: “Webhooks moeten idempotent zijn. Wat is onze strategie voor herhalingspogingen als Stripe de gegevens opnieuw verzendt?”

Financiën: „Hoe worden terugbetalingen verwerkt? Wat geldt er voor gedeeltelijke terugbetalingen?”

Naleving: „Hebben wij te maken met kaartnummers, of blijven wij bij SAQ-A?”

PM: „Wat staat er in de e-mail over de mislukte betaling, en wie schrijft die?”

Vragen die u zich het beste kunt stellen voordat u gaat stemmen

Eerst alleen in de sandbox, of zijn de live-sleutels vanaf dag één al inbegrepen?
Terugbetalingen en gedeeltelijke terugbetalingen — UI, API of uitsluitend voor beheerders?
Idempotentie van webhooks en afhandeling van herhalingspogingen — wie is verantwoordelijk voor de deduplicatietabel?
Toepassingsgebied van de PCI-norm: voldoen wij aan de SAQ-A-vereisten door de PAN nooit te verwerken?
Afstemming: wie stelt het rapport op, en op basis van welke betrouwbare bron?
UX bij foutmeldingen: geweigerde kaart, verlopen kaart, 3DS-verificatie — valt dit allemaal onder het toepassingsgebied?

Bij een dergelijk verhaal is het vaak verstandig om het op te splitsen. „Geld innen” is één verhaal; „geld terugbetalen” is een ander; „geld afstemmen” is een derde. Als u deze als één geheel beschouwt, leidt dat ertoe dat de integratie in week drie wordt opgeleverd en de financiële afdeling in week acht vraagt waar het rapport blijft.

Stem op „bewijs dat we het geld hebben ontvangen en het geschil hebben doorstaan”, niet op „roep de checkout-API aan”.

Zie ook: veelgemaakte fouten bij planning poker over het te laat opsplitsen van stories; schattingstechnieken voor werk dat zo vaag is. Bekijk de andere praktijkvoorbeelden van schattingen, of start een gratis planning poker-sessie zodra de verfijning klaar is.