Een schatting maken van een betalingsintegratie

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

De betalingsfunctie beschikt over een openbare API-interface die op één pagina past, en een beslissingsinterface die dat niet doet. Het selecteren van een aanbieder is een eenmalige piek van één dag. Het opzetten 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 de opdracht.

Het verhaal waarin staat „Stripe integreren” is zelden het verhaal dat daadwerkelijk wordt ingeschat. Het verhaal dat wordt ingeschat is: „we kunnen geld innen, 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 regelt het grootste deel ervan.”

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

Financiën: “Hoe worden terugbetalingen verwerkt? Hoe zit het met 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 live-sleutels vanaf dag één inbegrepen?
• Terugbetalingen en gedeeltelijke terugbetalingen: via de gebruikersinterface (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 aan te raken?
• 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?

Bij een dergelijk verhaal is het vaak verstandig om het op te splitsen. „Geld opnemen” is het ene verhaal; „geld terugbetalen” is het andere; „geld afstemmen” is het derde. Als u deze als één geheel inschat, 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 wij 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.