Scrum no necesita planing póquer ni historias de usuario

Dentro de las técnicas de estimación en Scrum, planing póquer es una de las más famosas, introducida por Mike Cohn en su libre Agile estimating and planning. Sin embargo Scrum no necesita ni historias de usuario ni planing póquer.

La historia de usuario es uno de esos elementos míticos de Scrum. Todos los Product Backlogs deben de estar poblados de ellas, aunque en ocasiones ni se refieran a un usuario y haya que enrevesadas para que expresen lo que realmente queremos.

El planing póquer es casi sinónimo de planificación en Scrum. Todos aquellos que han utilizado Scrum se han sentado alguna vez en una habitación con las cartas de estimación o una aplicación en el móvil para estimar el tamaño de historias de usuario.

Sin embargo, ninguno de los dos forman parte de Scrum y su uso es a discreción de los equipos Scrum y no de la organización.

El planing póquer

Scrum, en su guía oficial, expresa la necesidad de contar con estimaciones para los Product Backlog Ítems presentes en el Product Backlog, con el objetivo de entender mejor qué es lo que hay que hacer y cual es el valor que aporta a la organización.

Scrum dice claramente que los ítems presentes en el Product Backlog, deben de tener una estimación hecha por el Development Team

El planing póquer es una técnica de estimación que consiste en una sesión colaborativa con el equipo de desarrollo y, mientras el Product Owner lee un ítem, ellos eligen una carta con un número y la muestran a los demás. Las estimaciones usando planing póquer normalmente se hacen siguiendo la secuencia de Fibonacci, para expresar la complejidad (No las horas, como mucha gente cree). En este caso, un ítem con 5 puntos no es equivalente a 5 ítems de un punto, sino que es ocho veces más complejo que cada uno de ellos. En el planing póquer se estima complejidad y no tiempo, ya que si se estima tiempo no se tiene en cuenta la complejidad y si se estima complejidad si.

Relacionado
7 razones por las que las retrospectivas en Scrum fallan

El planing póquer sirve para fomentar una conversación cuando existe desacuerdo sobre el nivel de complejidad de un elemento. Si dos desarrolladores tienen ideas muy dispares sobre la complejidad de un ítem, es un indicador de que ese tema se debería de tratar en profundidadd.

No sirve para hacer predicciones. Al menos no de manera lineal, que es cómo tienden a hacerlas muchas organizaciones. En otro post veremos como hacer predicciones en entornos complejos usando (aunque no únicamente) la información generada por el equipo.

El valor de las estimaciones está en entender mejor cual es el tamaño de los ítems del backlog porque ello influye en la prioridad final que decida darle el Product Owner; sin embargo, tomarlas como una herramienta de predicción con ajustes es, lamentablemente, perder el tiempo.

Otras formas de estimación alternativa son No Estimates, donde todos los ítems del Product Backlog son del mismo tamaño; T-shirt sizing, donde se estima con tamaños de camiseta; Affinity estimation, donde se estiman los PBIs por comparación continua con otros.

Las historias de usuario

Muchos creen erroneamente que las historias de usuario deben poblar un Product Backlog. Las historias de usuario son elementos expresados en el sentido del valor que dan al usuario final, son independientes entre sí y fomentan una conversación sobre el valor para los usuarios.

As a developer, I want to download the development environment, so I can develop.
Al igual que el planing póquer, se ha convertido en un de esos elementos míticos, donde muchos profesionales dicen que un Product Backlog tiene historias de usuario. Nada más alejado de la realidad. Un product backlog contiene Product Backlog Items, y estos pueden ser cualquier cosa que necesite ser hecha para completar el producto: Casos de uso, historias de usuario, tareas técnica, requerimientos no funcionales, etc… la lista es tan larga como acciones tenga que completar el Equipo de Desarrollo para terminarla.

Relacionado
Cuatro herramientas básicas de un Product Owner

En lugar de escribir historias de usuario, yo recomiendo a los Product Owners con los que trabajo que intenten entender el valor de negocio de cada uno de los ítems existentes, y realmente ese es un ejercicio productivo, ya que en muchas ocasiones, el 20% o el 30% de los ítems presentes no tienen ninguno.

Avatar for Jerónimo Palacios Vela

Posted by Jerónimo Palacios Vela

Mi misión es ayudar a mejorar la profesión del desarrollo de software. Soy Professional Scrum Trainer de Scrum.org, Accredited Kanban Trainer de Lean Kanban y facilitador de LEGO® Serious Play. Vivo entre Berlín y Granada. Me encantan la vela y el Rugby

Suscribete a nuestra lista de correo

Suscribete a nuestra lista de correo

Recibe actualizaciones en la comodidad de tu bandeja de entrada. Un email a la semana. Sin Spam. Sin Trucos.

Suscripción con éxito

Shares
Share This