Planning poker o planificación poker es una técnica muy sencilla, divertida y eficaz, en la que todas las personas comprometidas en el desarrollo de un producto software opinan para estimar el esfuerzo de desarrollar cada una de las historias de usuario de un sprint.
El planning poker se utiliza mucho en las planificaciones de sprint en Scrum, aunque realmente se puede utilizar en muchos otros contextos.
Lo que me gusta de la planificación póker es que todos los miembros del equipo participan activamente. Scrum va de comunicación, así que juntar al equipo para tomar decisiones es algo totalmente lógico y positivo para el proyecto. Además, es otra oportunidad para que los miembros del equipo aprendan unos de otros y del producto que están desarrollando.
Antes de empezar un planning poker
Antes de empezar un planning poker hay que definir la unidad que se va a utilizar para medir.
Pueden ser horas o días ideales, puntos de función o cualquier otra métrica tradicional. Aunque una unidad que me gusta y todo el mundo entiendo es la de “pantallas de login”.
Es decir, estimar cada historia de usuario, en relación a lo que costaría desarrollar una pantalla de login.
Si lo piensas bien, una pantalla de login lleva consigo:
- Una tabla de usuarios, otra de sesión, etc.
- Un conjunto de servicios para validar datos, crear la sesión, gestionar excepciones…
- Un formulario del lado del cliente con dos campos de texto y un botón
- Validaciones de contraseña, campos vacíos, usuario no existente, etc.
Lo bueno es que absolutamente todo el mundo alguna vez ha tenido que hacer una pantalla de login, y si no es así, es algo que es fácil de acertar a ojo cuánto costaría.
¿Por qué se llama planning poker?
Se llama planning poker porque se utilizan cartas numeradas (no tienen porqué ser de poker).
Lo normal es numerar las cartas con una serie de Fibonacci (0, 1, 1, 2, 3, 5, 8, 13, …), más la carta interrogante que equivale a “ni idea” y la carta infinito que equivale a “esto es demasiado grande”.
El motivo de utilizar una serie de Fibonacci en un planning poker es porque cuanto más grande es el número asignado a una historia de usuario, más probabildad de equivocarse en la estimación.
Así, se tiende a dimensionar las historias de usuario de manera que siempre se utilicen números bajos. Es más probable acertar en las estimaciones si cada historia de usuario termina con un número bajo durante el planning poker.
¿Cómo hacer un planning poker?
Lo primero y en lo que muchos equipos fallan:
En gestión ágil y en un planning poker, se estiman historias de usuario completas.
Luego si quieres las divides en tareas más pequeñas para que esté más claro el trabajo a hacer y se pueda repartir entre el equipo. Pero lo que se debe valorar son historias de usuario y lo que se debe terminar al final de un sprint son historias de usuario completas, no tareas.
Pues bien, una vez aclarado esto, para hacer un planning poker:
- Junta a todo el equipo alrededor de una mesa y reparte un juego de cartas numeradas con una serie de Fibonacci desde 0 hasta 8
- El dueño de producto lee una historia de usuario a todo el equipo
- Si alguien tiene dudas se preguntan en ese momento. Esto sirve para que todo el mundo tenga claro lo que hay que hacer en esa historia de usuario. Es una manera rápida y fácil de acotar el alcance
- Cada miembro del equipo (incluido el dueño de producto), selecciona una carta, la pone boca abajo en la mesa y cuando todos han seleccionado una carta se ponen boca arriba a la vez
Una vez todos han mostrado su carta (su estimación), hay dos opciones:
- Descartar las estimaciones mínimas y máximas y quedarse con la estimación media más repetida.
- Buscar la unanimidad. Los que han diferido de la mayoría explican sus motivos y el resto explican los suyos. El objetivo es llegar a una estimación unánime.
Se repite el proceso con cada historia de usuario en el product backlog.
Recuerda que el número 1 indica el tiempo que cuesta desarrollar una pantalla de login.
Hay gente que utiliza números más altos en las cartas para estimar… pero como ya he dicho una historia de usuario con un número demasiado alto es candidata a variar mucho de lo estimado a lo que realmente cuesta. El número más alto también depende de la unidad seleccionada para estimar. En este caso el número 8 me parece más que correcto.
Si hay algún miembro menos experto o incluso que no desarrolla, también tiene que participar en el planning poker. Como mínimo va a aprender bastante de los objetivos del producto.
¿Cuál es el resultado de un planning poker?
El resultado de un planning poker debe ser que junto a cada historia de usuario debe aparecer un número que indique el esfuerzo necesario para terminar esa tarea. Todo el equipo ha participado, todo el mundo conoce el alcance de cada historia de usuario y todos están de acuerdo en el trabajo a realizar.
Ese número se deberá actualizar cada día en el daily meeting, indicando el esfuerzo restante para terminar la tarea en curso. No olvides durante el daily meeting actualizar el gráfico de burndown.
Además tras el planning poker, si se realiza al final de cada sprint, es buena idea planificar las historias de usuario que entran en el siguiente sprint. En el fondo estamos planificando.
Creo que es más difícil explicarlo que hacerlo, pero en mi opinión es una técnica muy sencilla, práctica y que da buenos resultados a la hora de estimar historias de usuario.
Ing Alberto , estuve leyendo su “scrum-planning-poker” es muy interesante su blog, pero casi no le encuentro el sentido de usar las cartas y el fibonacci para darle una prioridad a cada historia, ya que haciendo primero las historias de usuarios , después pasas hacer los product backlog, con la ayuda del propietario y con la experiencia que tiene el equipo de trabajo.
Yo creo en estas palabras que pone … “Todo el equipo ha participado, todo el mundo conoce el alcance de cada historia de usuario y todos están de acuerdo en el trabajo a realizar.” y según a estas palabras decidiré que prioridad le doy a Historia de usuario sin la necesidad de usar las cartas. ojala me pueda responder o quizas aclarar el tema del planing poker.
Atentamente;
Adelfio Carrion Diaz
Hola,
el ‘planning poker’ no se usa para dar prioridad, sirve para estimar cuánto cuesta terminar una historia de usuario.
Con esas estimaciones, las prioridades que decida el dueño de producto y la velocidad del equipo, se acuerda el sprint backlog. O lo que es lo mismo, las historias de usuario que da tiempo a desarrollar durante el sprint.
Saludos!
Hola, tengo una consulta acerca de los números que se usan en las cartas. Si cada número representa el “esfuerzo” que llevaría cada US, entonces el cero en qué caso se usaría? Gracias.
Hola,
en planning poker el 0 se usa cuando la historia de usuario es tan pequeña que no merece ser historia de usuario.
Si hay historias de usuario a 0 normalmente es porque no de han redactado bien el alcance.
En ese caso, o se amplía la funcionalidad o se incluye como tarea en otra historia de usuario similar.
Saludos.
Te pregunto por el símbolo °° (Infinito) que sentido tiene usarlo, teniendo en cuenta que el número 100 ya es demasiado grande para ser considerado como una historia de usuario y que deberíamos dividirla mas?
Como todo en Agile, depende de como lo uses.
En tu caso la carta 100 sería como la carta infinito, una historia muy grande que hay que dividir. Aunque hay un pequeño matiz, si le pones 100 la has estimado y en teoría se podría desarrollar.
Yo prefiero usar hasta la carta 13, que ya me parece muy grande. Para nosotros, una historia de 13 se puede desarrollar, pero más grande le ponemos infinito y hay que dividirla.
Saludos!
Hola!
Muy buen post! estimado, tengo 2 dudas:
1. Me das un ejemplo de una historia de usuario? porque no se si es una funcionalidad completa y tareas pequeñas.
2. Los puntos de cada historia de usuario, cómo se traducen a tiempo?
Gracias!
Hola!
Muy buen post! estimado, tengo 2 dudas:
1. Me das un ejemplo de una historia de usuario? porque no se si es una funcionalidad completa o tareas pequeñas.
2. Los puntos de cada historia de usuario, cómo se traducen a tiempo?
Gracias!
Hola… y a mi quién mi invitó? jeje pero te respondo porque estoy estudiando acerca de esto… Una historia de usuario se puede definir, generalmente, de acuerdo a dos plantillas:
Como [actor], yo necesito o quiero [acción], para [lograr], o bien, Como un [actor], yo necesito o quiero [logro]. Un ejemplo podría ser:
Como un administrador yo necesito deshabilitar cuentas. Otro ejemplo,
Como un cliente yo necesito ver el catálogo de artículos para poder ordenar uno de ellos.
Hola,
Elizabeth ya te ha puesto un par de ejemplos de historias de usuario. Como ves una historia de usuario es una funcionalidad y luego cada historia tendrá sus tareas para llevarla a cabo.
Respecto a los puntos de historia, suelen ser una medida abstracta que no se traduce a tiempo directamente.
El objetivo es que el equipo a través de su experiencia aprenda cuantos puntos de historia puede completar en un sprint. Esto se conoce como velocidad.
Saludos.
El punto dos, si te lo debo.
Hola,
en que momento del proceso de Scrum es recomendable realizar el planning Poker?
Lei en varios lugares que es conveniente después de finalizar el Sprint Planning, es cierto?
Hola,
No tiene mucho sentido hacerlo después de planificar un Sprint porque antes de planificarlo las tareas tienen que estar estimadas.
En general se hace el planning poker antes de cada Sprint o bien cuando se añaden tareas nuevas al product backlog.
Saludos!
Hola, tengo una consulta.
Que pasa si una historia de usuario tiene que ser implementada en back-end, mobile y certificación. Cuál es la forma correcta de estimarla.?
Perdón por la extensión de la pregunta y por colocarla aquí. Pero es que estoy realmente confuso acerca del nivel del profundidad que se debe alcanzar en el SPRINT planning y en breve tengo que empezar a trabajar con Scrum master.
Tengo la siguiente duda respecto al seguimiento del SPRINT. Muchos autores dicen que en el SPRINT PLANNING las user stories no tienen por qué dividirse completamente en tareas y mucho menos estimar las tareas en tiempo, ya que esto consumiría mucho tiempo y se puede ir haciendo a medida que avanza el SPRINT. Por tanto al final del SPRINT PLANNING la única estimación que tenemos son las user stories en story points (proporcionada por ej con el POKER CARD). Por lo que comentas en el post, tú coincides con este pensamiento.
Hay otros que además de la estimación en STORY POINT (servirá para calcular la velocidad), dividen las US en tareas y además las estiman en horas.
En cualquiera de los 2 casos se actualizara diariamente el Burndown chart con el grado de avance lo cual nos permitirá ver el esfuerzo restante para acabar el Sprint. Mi duda surge en como de realista es esta actualización.
En ambos escenarios nos podemos encontrar que una vez que se está trabajando en una User Story (es decir, hayamos actualizado el grafico con unos avances), descubramos que no se han detectado todas las tareas, en cuyo caso habrá algún momento del sprint en el que habrá que trabajar en ellas, sin que este trabajo genere ningún avance en el grafico…
En el segundo caso, ya hemos dividido la US en tareas estimadas en horas….En el grafico representaremos horas vs días. Al final de cada día es bastante sencillo saber cuánto tiempo realmente hemos dedicado a cada tarea y cuanto nos falta para concluirla. Es decir que la actualización del Burndown chart, va a ser bastante exacta.
En el primer caso, al hacer el BurnDown Chart, en el grafico tenemos STORY POINTS vs Dias duración del Sprint.
Los Story points son algo abstracto, referencian algo que está a alto nivel (US). Sucede además que en una misma US habitualmente trabajara más de un desarrollador, encontrándonos además con que habrá tareas más complejas que otras, es decir que varias personas con distintos criterios van a tener que actualizar un único valor que es el grado de avance en Story points de una misma US. Es decir que lo veo muchísimo mas inexacto. ¿Cómo lo haceis?
Dicho esto, veo más clara la opcion2 (horas vs días) pero entiendo que la opción 1 (Story points vs días) es la más popular, entiendo que además del motivo expuesto anteriormente (dividir en tareas y estimarlas en horas consumiría mucho tiempo) debe haber algún otro motivo, por favor, podrías aclarar en más detalle como realizas el Sprint Planning hasta el punto de hacer el seguimiento diario con el burndown Chart?
Muchísimas gracias y disculpa por el pedazo correo.
Creo que es pesimo el ejemplo, tiene que haber otra unidad de medida, mucho mas standard. Creo que esta mal el ejemplo porque es algo mecanico, cada vez que hago un login lo hare mas rapido, en cambio la primera vez tendre que pensar, como se hace?, como valido?, despues todo esto esta pensado, de hecho despues seria copiar y pegar, al final algo que por primer vez me demore 3 dias, luego me demorare 3 horas. Lo mismo maquetar una pagina, hay personas que solo se encargan de maquetar, y otras que hace el diseño, la maquetan, la construyen el modelo de la base datos y despues muestra esos datos a traves de una interfaz. Obviamente el segundo se demorara unas 5 veces mas que el primero en maquetar. En un proyecto apareceran muchas cosas que se haran por primera vez, y no se tendra ni idea de cuanto sera la demora ni siquiera si sera factible.
Hola Jorge,
creo que el problema es que lo llevas al terreno de las “horas” y que no se puede estimar lo que no sabes hacer. Por partes:
– Si usas una medida “sintética”, como por ejemplo pantallas de login. Cuando seas un paquete haciendo pantallas de login, una historia de usuario te costará muchas pantallas de login. Cuando seas el puto amo haciendo pantalla de login te costará menos pantallas de login. ¿Cuál es el problema?
– Si no sabes hacer una historia de usuario ¿cómo piensas estimarla? Para eso hay algo en Scrum que se llama spike.
Saludos.
Hola, tengo una duda. La planning poker se hace en la etapa de Refinamiento del Product Backlog también? O es propia del Sprint Planning?
Como todo en agile, lo puedes ajustar a lo que mejor te venga a ti. Mi opinión es que cuánto más tarde estimes una historia de usuario, menos fallarás, aunque también hay a quien no le gusta tener nada en el panel sin estimar.
Como ves no te he dado una respuesta :), tendrás que probar.
ahh… yo porque pensé que en la etapa de Refinamiento del PB ya tienen que estar estimadas por lo menos las que se seleccionan para esa iteración (obviamente no todas), como una característica del criterio de Ready (cumpliendo modelo INVEST) para poder pasar a formar parte del sprint backlog… pero claro, eso puede depender del equipo y su forma de trabajo jaja, muchas gracias!