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 piektaak 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: “De sandbox is eenvoudig. De bibliotheek doet het grootste deel van het 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 het waard zijn om te stellen voordat u gaat stemmen

• Eerst alleen in de sandbox, of zijn de live-sleutels vanaf dag één 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 mislukkingen: vallen geweigerde kaarten, verlopen kaarten en 3DS-verificaties allemaal onder het toepassingsgebied?

In een dergelijk geval is het vaak verstandig om het verhaal op te splitsen. „Geld opnemen” 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 dat de financiële afdeling in week acht vraagt waar het rapport blijft.

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

Zie ook: veelvoorkomende fouten bij planning poker waarbij verhalen te laat worden opgesplitst; schattingstechnieken voor werk dat zo vaag is. Bekijk de andere uitgewerkte schattingsvoorbeelden, of start een gratis planning poker-sessie zodra de verfijning klaar is.