Het inschatten van een door een klant gemelde fout
Hoe een door een klant gemelde bug te inschatten: de omschrijving op het ticket bepaalt de omvang. Hoe onderscheidt u een oplossing van slechts één regel van een reactie die de hele sprint in beslag neemt?
Het probleem is niet de omvang. De klant is de omvang.
Een door een klant gemelde bug heeft een omvang die het team niet kan overzien op basis van het ticket alleen. De technische oplossing kan misschien uit één regel bestaan. Maar het werk eromheen — 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 de communicatie met andere getroffen klanten — vormt vaak het grootste deel van het verhaal. Niets daarvan staat op het ticket. 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 — en dat is de reden waarom bugs van klanten het gevoel geven dat ze 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 we hen een e-mail sturen?”
Vraag: “Kunnen we het probleem met hun gegevens reproduceren, of hebben we een geanonimiseerde export nodig?”
Vragen die u zich het beste kunt stellen voordat u gaat stemmen
- Wie heeft dit gemeld, en wat is hun ARR, SLA of contractstatus?
- Moet er extern een RCA of een 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 synthetisch?
Opsplitsen helpt: de oplossing is het ene ticket, het antwoord is het andere. Beide doorlopen de planning poker-procedure; slechts één ervan heeft een technische aard.
Maak een afzonderlijke schatting van de reparatiekosten en de reactietijd. De accountnaam is de reden waarom de reactietijd zo lang is.
Zie veelvoorkomende fouten bij Planning Poker voor meer informatie over de risico’s van het stemmen over werk waarvoor de groep niet verantwoordelijk is. Bekijk de andere praktijkvoorbeelden van schattingen, of start een gratis Planning Poker-sessie met beide stories bij de hand.