Jag har vagt känt till begreppet Prediction Markets, där man sammanfattar många individers förutspåelser om aktiekurser, vilken teknik som kommer att lyckas och misslyckas, och andra svåra frågor där enskilda individers kunskap ofta inte är tllräcklig, eller något man generellt sett inte litar på. Vem litar på enskilda aktieanalytiker, till exempel.
Stötte nyligen på en artikel i ämnet som sammanfattar ett event i Silicon Valley om just detta ämne, anordnat av Yahoo. Det visar sig vara ganska mycket på gång, bland annat finns det ett open source ramverk skrivet i Java med namnet Zocalo. En kille från Microsoft berättade att man använt tekniken för att förutspå testplanering, där det visat sig att man på detta sätt förutspått att planen inte skulle hålla tidsramen. Och då slog det mig att man skulle kunna använda anonyma formulär på detta sätt för att fråga medlemmarna i ett Scrum team om de tror på tidsramarna för en sprint. Kanske tror man inte på tidsplanen, men vill inte säga något om det för att inte verka negativ eller långsam. Får man svara på detta anonymt, så kanske det kollektiva svaret blir bättre än det som framkommer under mötet då tidsplanen tas fram?
Planning Poker har blivit ett populärt sett att göra detta i Scrum. Vi har börjat köra det på Tain också (så sent som idag faktiskt). Funkar bra! Tror begreppet "planning poker" myntades i Mike Cohn’s välkända bok "Agile Estimating and Planning".
Planning Poker är busenkelt. Under sprintplaneringsmötet har alla i teamet en egen kortlek som består av korten 0.5, 1, 2, 3, 5, 8, 13, 20 och 40. En slags modifierad fibonacciserie. Har man ingen riktig kortlek med dessa siffror kan man skapa på nolltid med postit-lappar.
Alla i teamet har sin egen kortlek. Så fort något ska tidsestimeras så lägger alla teammedlemmar fram ett kort, nedvänt, som motsvarar deras tidsestimat (i mandagar eller vilken enhet man nu vill använda). När alla lagt ned varsitt kort vänder alla upp samtidigt och jämför. Om differansen är stor så diskuterar man detta och teamet enas till slut om ett rimligt tidsestimat. Om teamet inte kan enas tar man det högst estimatet helt enkelt.
Anledningen till att man kör nummerserie med "hål" i är för att slippa diskutera om något ska ta 12 eller 13 eller 14 dagar. Det finns bara 13. Eller 8. Eller 20. Ju större tidsestimat, desto mer osäkerhet och därmed desto mindre skäl att försöka vara exakt i tidsestimatet. Det ger också en bra incentive att bryta ned stora stories till mindre.
/Henrik