Planning Poker

Hoy me apetecía hablar del Planning Poker. Para los que no lo conozcáis, es una técnica de estimación basada en consenso. Se utiliza en muchos ámbitos, pero es especialmente defendida dentro del mundo de las metodologías ágiles. Ha estado especialmente vinculado a la metodología XP (eXtreme Programming), pero más recientemente se ha asociado casi exclusivamente a SCRUM.
Tenéis una descripción bastante acertada en Wikipedia. Aquí vamos a tratar de ir un poco más alla. Empezaremos resumiendo cómo funciona:

1. El grupo de estimación estará compuesto por un moderador y los estimadores (equipo de desarrollo). El Product Owner puede participar, pero no puede estimar las tareas.
2. Cada estimador debe tener un juego de cartas.
3. El moderador lee la descripción de la tarea (normalmente, la propia "Historia del Usuario"). El Product Owner puede aquí participar para aclarar alguna duda.
4. Cada estimador elige una carta y la coloca boca abajo en la mesa. Cuando todos los estimadores están listos, éstos darán la vuelta de forma simultánea, cada uno a su carta seleccionada.
5. Si las estimaciones varían mucho, los estimadores con mayor variación (más alta y más baja respecto a la media), exponen sus razones. Aquí deben participar todos, no sólo los responsables de las cartas discordantes.
6. Repetir el paso 4 hasta que las estimaciones convergan.

Hasta aquí todo bien. Hay mucha documentación en internet sobre cómo hacerlo, incluso algún sitio web que se ofrece para que hagas el planning online de forma gratuita (http://www.planningpoker.com/). Por cierto, que esto es especialmente útil para equipos distribuidos, aunque la paradoja aquí es que precisamente las metodologías ágiles están en teoría enfocadas a equipos no distribuidos.

Sin embargo, vamos a intentar como siempre, poner algo más...

Si has llegado leyendo hasta aquí y no tienes un montón de preguntas...anda...léelo otra vez. La cuestión es que el Planning Poker no estima en horas. Ni en días. No es una unidad habitual, es la llamada "Punto de Historia de Usuario". Es decir, después de una sesión de estimación con Planning Poker, saldrás de la reunión sin saber cuándo vas a terminar las tareas. Vale, en este momento, tengo a todos los agile-fans enviándome comentarios con amenazas. No, en serio. Lo que ocurre, es que la medida obtenida con Planning poker, es una unidad relativa. Se trata de una medida comparativa. Comparamos las tareas. es decir, una tarea será estimada con la carta del "3", si creemos que cuesta el triple de tiempo que la tarea para la que se estimó en "1". Es por eso, que las tareas estimadas con cantidades grandes, se suelen dividir en tareas pequeñas, que se vuelven a estimar.

Pero sigamos. Tenemos tareas pequeñas, todas bien estimadas, y ¿seguimos sin saber cuándo vamos a terminarlas? Sí, y No. En las metodologías ágiles, especialmente en SCRUM, existe un concepto llamado "Velocidad". Este término, viene a ser el número de "Puntos de Historia de Usuario" que según los datos históricos, somos capaces de llevar a cabo por unidad de tiempo.

Ventajas de Planning Poker

• Hace divertida la estimación (después de todo, ¿quién se niega a sentarse en una mesa y jugar a las cartas en mitad del trabajo?).
• Intenta evitar el sesgo que proporcionan las estimaciones de los falsos expertos.
• Promueve la participación y la colaboración.
• Aumenta el compromiso. Si la historia de usuario entra en el sprint, estaremos más comprometidos porque hemos participado en la estimación.
• Abstrae el concepto de tiempo. Las estimaciones se hacen en puntos, y éstos son una medida proporcional a tareas simples.
• Facilita la colaboración y estimación en entornos distribuidos (con las oportunas herramientas).

Desventajas de Planning Poker

• No está enfocado a usuarios noveles. Una estimación basada en "puntos", es difícil que sea de utilidad a quien no tiene ya una cierta experiencia (y no sólo en ese proyecto), tanto en estimación como en desarrollo. Sin un mínimo de conocimiento, no es posible hacer la abstracción que te permita comparar la tarea estimada con otra distinta de referencia.
• El llegar a un consenso, no garantiza el acierto. Así es, podemos estar de acuerdo en algo, y eso no significa que sea cierto. Aquí jugará mucho la experiencia REAL. Es decir, no sólo no hay que ser no-novatos, sino que además interesa que el equipo tenga varios expertos. Por desgracia, si está delante el usuario para ayudarnos en la estimación, o hay un jefe, es posible que nadie esté dispuesto a "dar la nota", y acabe llegándose a un consenso-porque-sí.
• Es poco serio. Venga, hay muchísimos clientes que si tuvieran que asistir en una sesión de estimación, y vieran que lo primero que se hace es sacar una baraja....se echarían a temblar (justificadamente o no). Vamos, que no es exactamente la mejor imagen de seriedad.
• Requiere de un histórico de información. Si no tenemos una medida de la velocidad del equipo, y no tenemos estimaciones anteriores para correlacionar esas estimaciones con las horas realmente requeridas, va a ser complicado que algún día podamos encajar puntos y horas. En relación con este concepto, he encontrado un post cuyo enfoque comparto. Y es que esto de abstraer la duración de las tareas, da miedo escénico. En dicho post, propone una aproximación inicial de basarse en datos históricos, combinada con el concepto de usar la tarea más pequeña, como "1 punto de historia de usuario". Así todo el equipo tiene un referente común de lo que cuesta hacer ese "punto".
• Cultura. Requiere una cultura ágil enraigada. No veo a un manager o jefe de proyecto sin esa cultura ágil, oir hablar de que nos faltan "3 puntos" para terminar la iteración. A más de uno le entrará la histeria y soltaría frases como: "dejate de tonterías, lo tienes que terminar el viernes".
• Por sí solo, no es una buena fuente de estimación. Sin embargo, esta técnica por sí sola, sí es una primera estimación, y se complementa perfectamente con otras técnicas de estimación como pueden ser WBS y las basadas en históricos, u otras técnicas basadas en parametrización.
• Este método consume mucho tiempo. La idiosincrasia y el protocolo que requieren, desde mi punto de vista, parece más enfocado a acordar un resultado, que a que dicho resultado tenga algún parecido con la realidad.
• Los Puntos de Historia de Usuario se enfocan en estimar el tamaño de lo que se construye, y evitan la realidad de que eso realmente no importa: de lo que se trata, es de estimar cuánto cuesta construirlo. Aquí, hay múltiples ejemplos en el mundo real: el hacer algo el doble de grande, no tiene porqué costar el doble. Quizás más, quizás menos.
• El uso de Puntos, trata también de esquivar el equívoco que se produce al consumir la mitad de horas del proyecto. En este caso, un jefe de proyecto poco experimentado estará tentado de decir que estamos al 50%. Al hablar de puntos, estamos intentando que estadísticamente hablando, el error de estimación se diluya, consiguiendo que al haber transcurrido la mitad de puntos, estemos a la mitad de la iteración. Bajo mi punto de vista, esta afirmación presupone tantas cosas, que  las veo prácticamente en la misma perspectiva: ambas respuestas están mal. y es que el haber completado la mitad de puntos, me dice lo mismo que en el primer caso (cambiando horas por puntos). Lo que sí es cierto, es que el avance no se debería expresar en horas, sino en funcionalidades. Por otro lado, la triste realidad que no podemos esquivar, es que al 50% de horas, hemos gastado la mitad del dinero. A ver como administramos lo que queda...

Al final, a pesar de parecer tan duras estas desventajas, es que la técnica está realmente bien. Como siempre, estas desventajas las tenemos que ver como riesgos que afectan al proyecto. Mi recomendación, que es la misma que el SEI y otras fuentes, es diversificar. No sólo el hecho de diversificar las personas que estiman, mejoran la estimación (en eso se basa esta técnica). Si además, combinamos varias técnicas, y sobre todo, nos apoyamos en datos reales históricos, tendremos la auténtica fuente de buenas estimaciones.

Y nada más, probadlo y obtened vuestras propias conclusiones. Me gustaría terminar recomendando una lectura relacionada, de un blog que suelo leer. Os lo dejo en este link.