El planning poker és una de les millors eines per a fer estimació de l’esforç per a cada una de les necessitats 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 (sprint). 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 pot 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és 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 història és trivial i no té valoració. Hauríem d’avaluar si realment l’ítem 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 - Històries senzilles. Sense dificultats tècniques aparents
• 5 i 8 - Històries senzilles amb alguna dificultat tècnica
• 13 i 20 - Històries amb complexitat tècnica
• 40 - Històries amb molta dificultat tècnica
• 100 - Històries amb molta dificultat tècnica i amb un alt risc de no ser enteses correctament degut a la seva grandària
• ∞ - Quimera. La història no s’entén. La història é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 - Història trivial
• S - Història senzilla i sense dificultats tècniques
• M - Història amb alguna dificultat tècnica
• L - Història amb dificultats tècniques rellevants
• XL, XXL, etc - Història 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 històries valorades en 5, 8 o 13 són històries complexes. I que històries valorades en 20, 40 o 100 probablement són històries d’elevat risc per a l’equip. Com més gran és una història, 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 història amb aquest volum, o prefereix dedicar temps a subdividir aquesta en històries 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 tots els interessats 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