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.
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.
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.
Deja una respuesta