El planning poker és una de les millors eines per a fer estimació de l’esforç 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. L’ú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’expertesa necessari

Les normes

El primer que cal dir és que el planning poker és una activitat enfocada a l’estimació d’històries d’usuari. Les històries d’usuari no es valoren en temps ni en cost econòmic. Han de valorar-se en un valor relatiu que dona una orientació sobre l’esforç per a l’equip. En cas que l’equip decideixi, per la seva organització, dividir les històries d’usuari en tasques tècniques, aquestes si poden estimar-se en hores

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 els tècnics (developers) 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 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. El Scrum Master ha d’estar atent a què l’equip desenvolupi l’actitud d’imparcialitat necessària.
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 successió de Fibonacci, amb els valors següents:

• 0 - La tasca és trivial i no té valoració. Hauríem d’avaluar si realment l’item té valor per als usuaris i l’organització
• 0.5 - Aquest valor no és habitual a tots els projectes. En ocasions és necessari indicar que, tot i que sabem que una història és trivial; por les seves característiques o per qüestions organitzatives, seria desitjable incloure-la com a història d’usuari vàlida i independent.
• 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
• ∞ - Quimera. La tasca no s’entén. La tasca és massa grandària

Un exemple de cartes amb la successió de Fibonacci

Altres formes de fer estimació

Una altra forma de fer estimació, i que té 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 grandària

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 perquè 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 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é controlar 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 grandària dels diferents ítems del Product Backlog.

Descarrega les cartes aquí

Alternativa al planning poker “de sempre”

El planning poker, com totes les activitats i bones pràctiques en agilitat, està viu!! Hi ha alternatives i variants al planning poker de tota la vida. En concret hi ha una de molt interessant que explico a continuació. La podem anomenar com Planning Poker per aspectes:

L’equip es reuneix per a fer estimació d’una història d’usuari. Algú l’explica i es té un debat per alinear coneixement al voltant del que es necessita. A l’hora de fer l’estimació, cada membre de l’equip dona un valor de 0 a 6 sobre els aspectes següents:

• Esforç: De forma semblant al planning poker tradicional. Quin esforç creus que representa aquesta història respecte a les altres? Un valor de 0 a 6
• Incertesa: Quina possibilitat creus que hi ha de que aparegui algun element sorpresa que dificulti la consecució d’aquesta història? Un valor de 0 a 6
• Coneixement: Quin grau de dificultat creus que hi pot haver respecte a la necessitat de coneixements tècnics o skills específics per la consecució d’aquesta història? O, quin grau de treball en equip creus que té aquesta història (0=individual - 6=completament en equip)? Un valor de 0 a 6

La suma dels tres valors dona un valor en story points per la teva votació. Posteriorment la dinàmica de consens d’una estimació consensuada és la mateixa que en el planning poker tradicional