Een schatting maken van een prototype
Hoe u een prototype moet beoordelen: het is een opleverbaar product dat bedoeld is om van te leren, niet om te gebruiken. Hoe u kunt voorkomen dat het wegwerpbare prototype uitgroeit tot de productiecode waar niemand op had gerekend.
Het verhaal waarvan het eindresultaat luidt: „We weten nu wat we moeten bouwen”, en niet: „We hebben het gebouwd.”
Een prototype is bedoeld om van te leren, niet om daadwerkelijk te gebruiken. Het gaat erom snel genoeg antwoord te krijgen op een vraag (voelt deze interactie goed aan, is deze aanpak schaalbaar, zal deze API het volhouden?), zodat u van koers kunt veranderen voordat u zich er definitief aan committeert. Teams die prototypes op dezelfde manier inschatten als functies, komen uit op een cijfer dat de verkeerde vorm van werk financiert.
De andere vorm van mislukking is het tegenovergestelde: een prototype te klein inschatten, iets opleveren dat „net voldoende werkt”, en dat vervolgens in productie nemen omdat de planning al verder is gevorderd. Het prototype dat het product wordt, is de duurste code in de codebase, omdat er geen rekening is gehouden met de onderdelen die ontbreken.
Wat er in de kamer wordt gezegd
Ingenieur: “Ik kan er binnen een paar dagen wel iets in elkaar zetten.”
Inleiding: “Welke vraag proberen we te beantwoorden?”
PM: “Is dit bestemd voor klanten, of alleen voor intern gebruik?”
Inleiding: “Als het antwoord ja is, gooien we het dan weg en beginnen we opnieuw?”
Ingenieur: „Wij gooien het nooit weg.“
Vragen die het waard zijn om te stellen voordat u gaat stemmen
- Op welke vraag geeft het prototype een antwoord, en hoe weten wij dat wij een antwoord hebben?
- Alleen intern, of in het bijzijn van klanten?
- Is dit standaard een wegwerpproduct, en staat het team daar volledig achter?
- Wat houdt de tijdslimiet in, en wat gebeurt er aan het einde daarvan?
- Als het werkt, hoe verloopt dan het traject van prototype naar productiecode?
De uitspraak van de ingenieur „we gooien het nooit weg“ vormt het werkelijke risico: reserveer budget voor het prototype als onderdeel van de oplossing en beschouw de productieversie als een op zichzelf staand project, zodat het weggooien niet automatisch de overhand krijgt.
Stel een prototype op basis van het antwoord op, niet op basis van het eindproduct, en plan de herontwikkeling voordat de planning dit voor u regelt.
Net zoals bij het inschatten van een piek in het onderzoek is het eindresultaat kennis; behandel beide op dezelfde manier. Bekijk veelgemaakte fouten bij Planning Poker waarbij onderzoek onbedoeld in het verhaal binnensluipt, en de andere voorbeelden van succesvolle schattingen.