Het inschatten van een door een klant gemelde fout
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?
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 bestaan. Maar het werk eromheen 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 het account moet worden gecrediteerd, en de communicatie 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 de gebruikelijke planning poker. De reactie is onbekend voor 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 tegen vrijdag.”
Lead: “Zijn er nog andere accounts getroffen? Moeten wij hen een e-mail sturen?”
Vraag: “Kunnen wij de fout 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 creditering verlenen, een terugbetaling uitvoeren of een 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?
Opsplitsen helpt: de oplossing is het ene ticket, het antwoord is 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 servicebeurt. De naam van de klant is de reden waarom de kosten voor de servicebeurt zo hoog uitvallen.
Zie veelgemaakte fouten bij Planning Poker voor meer informatie over de risico’s van stemmen over werkzaamheden die niet onder de verantwoordelijkheid van het team vallen. Bekijk de andere praktijkvoorbeelden van schattingen, of start een gratis Planning Poker-sessie met beide verhalen bij de hand.