El planning poker és una de les millors eines per a fer estimació de l’esforc per a cada una de les funcionalitats descrites al Product Backlog. Si tu i els teus companys d’equip sou capaços de determinar l’esforç, tindreu control sobre la “quantitat” de feina de qualitat que sou capaços de lliurar a cada cicle. Si sabeu això teniu la millor eina per classificar i prioritzar les necessitats descrites per l’usuari, i saber-ne amb molta exactitud tempos i durada del projecte.

L’equip (i només l’equip) ha d’aprendre a consensuar l’esforç que comporta fer realitat cada ítem del product backlog. La única forma d’assolir això és amb la pràctica i dialogant de forma oberta i sincera amb els companys. El Planning Poker és una eina que pot ajudar-vos a assolir aquest nivell d’expertessa necessàri

Les normes

Hi ha diferents modalitats per a fer estimació amb planning poker, però totes estan subjectes a les mateixes regles essencials, i que convé recordar:

1. Previsió: El planning poker no es duu a terme en el moment de fer la planificació del sprint. En el Sprint Planning els ítems susceptibles d’entrar en el Sprint ja han d’haver estat valorats.
2. Definició: Els ítems del product backlog a valorar, ja han d’estar prou definits i sense grans dubtes al moment de fer l’estimació amb planning poker. El planning poker no és el moment de negociar la funcionalitat o de resoldre grans dubtes amb l’usuari.
3. Responsabilitat: Només el Development Team fa estimació. El Scrum Master por estar-hi a la sessió i fins i tot participar si a la resta de l’equip li sembla bé. Però només l’equip te la responsabilitat. Ni el Product Owner ni els usuaris poden participar.
4. Consens: Per a cada ítem a estimar, una persona de l’equip (la que tingui més coneixement sobre l’ítem) l’ha d’explicar a la resta de l’equip. Abans de que ningú digui cap valoració, s’han de resoldre els dubtes que hi puguin haver. És el moment per parlar sobre la funcionalitat i les dificultats tècniques de fer-la realitat. Aquesta és la part més important de la sessió.
5. Imparcialitat: Mentre s’està explicant i negociant la funcionalitat, ningú pot opinar sobre la seva valoració en story Points. Es tracta de no influir a la resta de l’equip.
6. Estimació: Quan tot està clar ja es pot procedir a fer l’estimació. Tothom ho farà a l’hora presentant una carta amb la seva valoració.
7. Alineament: En cas que les valoracions siguin molt diferents, cal que la persona que ha valorat mñes baix, i la que ha valorat més alt, expliquin els seus motius.

El procediment de valoració es torna a repetir fins que s’obtingui un consens sobre l’esforç de dur a terme la funcionalitat sotmesa a votació, de forma que tot l’equip estigui alineat sobre l’esforç.

Es poden utilitzar cartes, aplicacions o plantilles amb els valors permesos.

Algunes plantilles d’exemple

Exemple 1		Exemple 2

La numeració de les cartes

Tradicionalment, les cartes de planning poker acostumen a seguir una numeració que és propera a la succesió de Fibonacci, amb els valors següents:

• 0 - La tasca és trivial i no te valoració. Hauriem d’avaluar si realment l’item te valor per als usuaris i l’organització
• 1, 2 i 3 - Tasques senzilles. Sense dificultat tècnica aparent
• 5 i 8 - Tasques senzilles amb alguna dificultat tècnica
• 13 i 20 - Tasques amb complexitat tècnica
• 40 - Tasques amb molta dificultat tècnica
• 100 - Tasques amb molta dificultat tècnica i amb un alt risc de no ser enteses correctament degut a la seva grandària
• ∞ - Kimera. La tasca no s’entén. La tasca és massa grandària

Un exemple de cartes amb la succesió de Fibonacci

Altres formes de fer estimació

Una altra forma de fer estimació, i que te força èxit entre els equips de projecte és fer estimació amb altres gradients no numèrics, per exemple amb talles de roba:

• XS - Tasca trivial
• S - Tasca senzilla i sense dificultats tècniques
• M - Tasca amb alguna dificultat tècnica
• L - Tasca amb dificultats tècniques rellevants
• XL, XXL, etc - Tasca amb molta dificultat tècnica o grandaria

Descarrega el document amb les cartes per imprimir

A l’enllaç següent pots trobar els arxius de les cartes amb successió de Fibonacci i talles per a que les puguis imprimir. L’arxiu conté els PNG de cada una de les cartes, i dos PDF amb les cartes en diferents mides per impressió.

He fet el disseny de cartes que m’agradaria tenir per als meus equips. I ho són perquè sóc conscient que sovint amb la numeració de la seqüència de Fibonacci no és suficient. En equips nous és habitual no tenir una idea clara de que significa una tasca valorada en “20”. Les valoracions en les primeres iteracions acostumen a ser massa altes. I és una tendència que convé control·lar i abordar ja des de la 1a iteració.

Aquestes cartes porten associades a cada valoració una imatge, que pretén donar una idea sobre la complexitat. I pretén explicar a l’equip que tasques valorades en 5, 8 o 13 són tasques complexes. I que tasques valorades en 20, 40 o 100 probablement són tasques d’elevat risc per a l’equip. Com més gran és una tasca, més risc hi ha d’acabar fent una gran feina que no s’adapta realment a les necessitats de l’usuari. Cal que l’equip sigui conscient d’aquest risc per tal que pugui decidir si realment accepta la construcció d’una tasca amb aquest volum, o prefereix dedicar temps a subdividir aquesta en tasques més assumibles.

La clau d’això és el MVP (Minimum Valuable Product). L’equip, incloent-hi al Product Owner, tenen el repte de fer entendre a totes les parts que els MVP han de significar increment de valor assumible per a totes les parts. I que per tant, cal que tothom es comprometi en el consens de la grandaria dels diferents ítems del Product Backlog.

Descarrega les cartes aquí