Het inschatten van een door een klant gemelde fout

Het probleem zit niet in de omvang. De klant is de omvang.

Een door een klant gemelde fout heeft een omvang die het team niet kan overzien op basis van het ticket alleen. De technische oplossing kan uit één regel code bestaan. Maar het bijbehorende werk vormt vaak het grootste deel van het verhaal: het reproduceren van de fout op basis van de gegevens van de klant, het opstellen van een analyse achteraf, het opstellen van het antwoord, het besluit of er een creditering op de rekening moet worden bijgeschreven, en het communiceren met andere getroffen klanten. Niets daarvan staat op het ticket vermeld. Dit alles gaat ten koste van de doorloopsnelheid.

Houd rekening met twee zaken: de oplossing en de reactie. De oplossing is gewone planning poker. De reactie is onbekend bij technische teams en wordt stelselmatig te laag ingeschat; daarom lijkt het alsof bugs van klanten de sprint blijven beïnvloeden, zelfs wanneer de deck-vote laag was.

Wat er in de kamer wordt gezegd

Backend: “De oplossing bestaat uit één regel.”

Premier: „Welk account heeft dit gemeld?”

Ondersteuning: “Hun CSM vraagt om een RCA voor vrijdag.”

Lead: “Zijn er nog andere accounts betrokken? Moeten wij hen een e-mail sturen?”

Vraag: “Kunnen wij het probleem met hun gegevens reproduceren, of hebben wij een geanonimiseerde export nodig?”

Vragen die het waard zijn om te stellen voordat u gaat stemmen

• Wie heeft dit gemeld, en wat is hun ARR, SLA of contractstatus?
• Moet er extern een RCA of postmortem worden uitgevoerd?
• Zijn er ook andere accounts getroffen, en hoe kunnen wij dat achterhalen?
• Moeten wij een tegoed toekennen, een terugbetaling verrichten of de proefperiode verlengen?
• Wie stelt het antwoord aan de klant op, en staat dat in dit ticket vermeld?
• Reproductie: gegevens van de klant, geanonimiseerde dump of synthetische gegevens?

Opdelen helpt: de oplossing is het ene ticket, de reactie het andere. Beide doorlopen de planning poker-procedure; slechts één ervan is technisch van aard.

Maak een afzonderlijke schatting van de kosten voor de reparatie en de reactietijd. De naam van de klant is de reden waarom de reactietijd zo lang is.

Bekijk veelvoorkomende fouten bij Planning Poker met betrekking tot de risico’s van het stemmen over werk dat niet onder de verantwoordelijkheid van de groep valt. Bekijk de andere voorbeelden van uitgewerkte schattingen, of start een gratis Planning Poker-sessie met beide stories bij de hand.