Table of Contents
Decidí escribir este artículo porque he visto varias veces que los jóvenes desarrolladores que se incorporan a las empresas tienden a malinterpretar o luchar con los conceptos de Story Points o puntos de historia y estimaciones, y también porque he conocido equipos de producto que en mi opinión no invierten el tiempo necesario en preparar sus backlogs y dividir las historias de usuario.
Soy consciente de que desde 2012 existe un debate (#noestimates) en la comunidad que cuestiona la necesidad de estimar en los equipos ágiles — evitaré ese debate y lo dejaré al lector, pero puedo afirmar que tener estimaciones adecuadas es algo que ayuda mucho a los departamentos de desarrollo de negocio, y dado que una cantidad importante de las empresas las utilizan, creo que este artículo puede ser bastante útil. El concepto de puntos de historia está directamente relacionado con la forma en que debemos preparar un backlog y hojas de ruta. Desde la perspectiva de un Product Owner es tan importante saber qué implican los story points para nuestras responsabilidades como saber exactamente qué son los story points.
Este artículo está dividido en 3 partes.
Primero intentaré explicar qué son los puntos de historia y por qué se utilizan en muchos equipos y empresas. No introduciré ninguna novedad aquí, pero intentaré dar algunos ejemplos prácticos sobre el concepto para detallarlo mejor.
En la segunda parte, teniendo como contexto la introducción de los puntos de historia, intentaré explicar la motivación y analizar las razones para explicar por qué un equipo debe dividir las historias de usuario. Cualquier equipo ágil debería ser completamente consciente del razonamiento que hay detrás de esta práctica. Finalmente, la última sección será mucho más práctica, ya que intento presentar los patrones más comunes que se pueden buscar al dividir las historias de usuario y proporcionar algunos ejemplos reales de división de historias de usuario.
El texto que viene es largo, considérate advertido ? pero creo que tenía sentido empezar por los conceptos más básicos y revisarlos en un recorrido por un proceso que se hace una y otra vez semanalmente en nuestras empresas.
Intentaré poner ejemplos prácticos y escenarios para que puedas relacionar los conceptos que intento presentar con situaciones que te hayas encontrado en tu propia empresa.
Espero que os resulte interesante y os ayude también… empecemos ?
Primera parte – Puntos de la historia de usuario
Hablemos de los puntos de historia
Los puntos de historia son una medida indicativa que los equipos ágiles utilizan para estimar el tiempo que se tardará en implementar una tarea. Y soy completamente consciente de que el uso de “tiempo” en esa frase tiene cabida en la discusión, pero al fin y al cabo, el Product Owner traduce una cantidad de story points a sprints, es decir, semanas, es decir, tiempo ?
La primera pregunta sería, si los puntos de historia se traducen en tiempo, ¿por qué no usamos el tiempo para estimar las tareas en primer lugar? Bueno, algunos equipos lo hacen. Otros no lo hacen. Desde una perspectiva muy simplificada, la principal razón para no usar horas o días es porque las unidades de tiempo son absolutas y los equipos de desarrollo a veces no se sienten cómodos proporcionando una estimación absoluta de las tareas que pueden no ser completadas en ese marco de tiempo porque algunos detalles están todavía por resolver en el momento de proporcionar esta estimación.
Así que en lugar de horas, muchos equipos de desarrollo prefieren utilizar puntos de historia.
¿Qué es exactamente un punto de historia?
En algunos textos se dice que el punto de historia mide la dificultad o la complejidad de una historia de usuario – no estoy de acuerdo con eso, es correcto pero incompleto. Otros textos (la mayoría) lo definen como una medida de esfuerzo, lo cual me gusta más. Analicemos lo que significa el esfuerzo y preguntémonos qué diferencia puede haber entre el esfuerzo y la historia de usuario.
Intentemos ponernos en la piel de un equipo de desarrollo e imaginemos que tenemos que estimar el esfuerzo que nos llevaría implementar 3 historias de usuario (súper simplificadas):
- Como usuario quiero ver mi página web en francés
- Como usuario quiero desenfocar una imagen para que se vea más moderna
- Como usuario quiero añadir una API externa de pasarela de pago por SMS a mis métodos de pago
Primer caso:
«Como usuario quiero ver mi pagina web en francés”
Supongamos que tenemos un sitio web con más de 100 vistas, y que todas las cadenas que mostramos son cadenas literales codificadas en el código fuente. La complejidad de esta tarea es casi nula, sólo tenemos que analizar todos los documentos del código fuente en busca de cadenas literales, sustituirlas por una etiqueta, construir algún tipo de sistema de localización (archivo JSON o lo que sea) y ya está.
Pero tenemos más de 100 vistas.
Esta historia de usuario es tediosa. No es difícil, no es complejo – pero tomará mucho tiempo y es aburrido como el infierno. El esfuerzo que esto puede tomar es significativo. Apuesto a que ningún equipo estimaría esa historia de usuario con un valor pequeño de puntos de historia, porque incluso el equipo de desarrollo menos experimentado sabe que puede llevar mucho tiempo completarla.
Segundo caso:
“Como usuario quiero desenfocar una imagen para que se vea más moderna”
De nuevo, vamos a hacer algunas suposiciones. Tenemos un equipo que no está familiarizado con el procesamiento de imágenes y tendrá que investigar muchas cosas.
Algunas preguntas que pueden surgir:
- ¿Qué significa desenfoque?
- ¿Existe alguna biblioteca que pueda ayudarme con esa operación?
- ¿Hay alguna forma de utilizar mis estructuras de datos internas que contienen imágenes con estas bibliotecas?
- ¿Funciona la biblioteca con mi conjunto actual de dependencias?
- ¿Puedo manejar el resultado?
- ¿Será correcto el rendimiento? etc.
Desenfocar una imagen es una operación que requiere una o dos líneas de código en la mayoría de los casos, y 20-30 si tienes que codificarla tú mismo. No es largo. El problema aquí es saber lo que hay que codificar, algunos equipos pueden estar completamente inseguros acerca de cuánto esfuerzo tomará esta historia de usuario.
Un equipo que no está familiarizado con las técnicas de procesamiento de imágenes probablemente estimará esta tarea con un valor significativo o tal vez incluso pida un timebox primero para saber cómo desarrollar la tarea en cuestión.
Tercer caso:
“Como usuario quiero añadir una API externa de pasarela de pago por SMS de terceros a mis métodos de pago”
La última. Lo que suponemos aquí es que tenemos un producto en funcionamiento con una versión web y otra para Android e iOS. Se nos encomienda la tarea de integrarnos con otro sistema de pago que nos ayude a monetizar mejor en un mercado en el que estamos luchando.
Para el equipo es una tarea conocida, ya hemos integrado pasarelas de pago antes, pero también somos conscientes de que tenemos que gestionar adecuadamente un montón de cosas (feedback de los usuarios, casos límite, etc.), hay un grado de conocimiento que aún no tenemos si no estamos familiarizados con la API a integrar y también sabemos que consiste no sólo en implementar la integración desde cero, sino en hacerla funcionar con el sistema que ya está en marcha.
La mayoría de los equipos clasificarían esta característica como compleja — no es un problema de incertidumbre, ya que es una tarea factible para el equipo, pero tenemos que tener en cuenta muchas cosas (gestión de errores, casos límite, la propia integración) y añadir un nuevo método de pago no es algo que se deba tomar a la ligera. Además, todas las partes existentes del sistema tienen que seguir funcionando sin problemas.
Espero que mis ejemplos hayan sido lo suficientemente claros como para representar que a veces es difícil estimar una tarea en un valor de tiempo absoluto y, sobre todo, que una estimación puede tener diferentes ejes a tener en cuenta.
En los ejemplos proporcionados, la mayoría de los equipos de desarrollo proporcionarían estimaciones significativas a las tareas anteriores, pero por diferentes razones. Una medida del esfuerzo reúne 3 conceptos diferentes:
- Tediosidad
- Complejidad
- Incertidumbre
Es algo que un Product Owner debería tener siempre en cuenta, y de hecho, lo es: cuando el equipo estima – como elaboraré en las siguientes secciones.
Hablemos de estimaciones y velocidad
Está bien que sepamos lo que son los puntos de historia y los tres conceptos que se esconden detrás del número. Pero, ¿cómo funcionan en un entorno práctico?
Usamos los story points para evitar la estimación absoluta, pero al mismo tiempo esto plantea otra pregunta, ¿cuánto tiempo equivale a un story point?
Esta es una pregunta clave que es crítica para cualquier equipo de producto para preparar hojas de ruta y prever lanzamientos. Por desgracia, no existe una regla general para resolver esta cuestión, ya que depende del equipo y del proyecto en cuestión.
Pero no te preocupes, no necesitamos ninguna, como verás:
Ejemplo práctico 1:
Tenemos dos equipos de desarrollo, el Equipo A y el Equipo B. Supongamos que ambos están igualmente capacitados, motivados y experimentados. PERO los desarrolladores del Equipo A son más bien optimistas y los miembros del Equipo B son mayoritariamente pesimistas.
Imaginemos que presentamos un ámbito de trabajo a estimar a ambos equipos, y les pedimos que estimen el esfuerzo que les llevaría completar la lista de tareas en puntos de historia. Probablemente se obtendrán dos estimaciones diferentes, por ejemplo:
- Equipo A: 18 puntos de historia
- Equipo B: 30 puntos de historia
Recordemos, mismas habilidades, misma motivación, misma experiencia, mismas tareas. Sin embargo, hay dos estimaciones diferentes.
Una vez realizada la estimación y completado el sprint, ¿qué crees que pasará? Las mismas habilidades, las mismas tareas, así que es muy probable que ambos equipos completen la misma cantidad de trabajo. Sin embargo, el primero completará “18 puntos” y el segundo completará “30 puntos”.
Lo primero que hay que tener en cuenta es que toda estimación sólo puede considerarse para el equipo que la ha proporcionado. Extrapolar una estimación a diferentes equipos no tiene ningún sentido.
Ejemplo práctico 2:
El equipo A ha trabajado en el Proyecto 1 durante tres meses, desarrollando un sitio web que implicaba un registro e inicio de sesión básicos, una página de aterrizaje con un panel de control y algunas vistas e informes informativos.
Durante 6 sprints el rendimiento del equipo ha dado una velocidad de 22 puntos de historia por sprint.
Una vez terminado el primer proyecto, el mismo equipo pasa a otro, otra parte de un sitio web que implica una integración con una API de terceros y una pasarela de pagos de Stripe. Ninguno de los miembros del equipo tiene una amplia experiencia en el desarrollo de integraciones con API de terceros.
¿Qué crees que pasará? Una vez que el backlog del segundo proyecto sea estimado por el mismo equipo, ¿puede el propietario del producto asumir que la velocidad será la misma?
La respuesta es no, no se puede hacer esa suposición.
No digo que la velocidad no pueda ser la misma, sino que la suposición no puede hacerse porque la naturaleza de las tareas a implementar ha cambiado, y eso puede afectar a la velocidad.
La situación descrita anteriormente puede darse incluso dentro del mismo desarrollo de producto, si el cambio de alcance es lo suficientemente relevante.
A fin de cuentas, tenemos que hacer las siguientes suposiciones y tenerlas en cuenta:
- Un equipo siempre estimará de la misma manera (más o menos).
- A medida que se completen más sprints, el equipo tendrá una medida predecible de “cuántos puntos de historia es capaz de completar el equipo de desarrollo en un sprint” – esta medida es la velocidad del equipo de desarrollo.
- La velocidad será estable mientras las circunstancias sean estables, es decir: Mismo equipo, Mismo proyecto, Tareas similares teniendo en cuenta las habilidades del equipo.
- El Product Owner utiliza la velocidad y la cantidad de puntos de historia que quedan en el backlog para prever cuántos sprints serán necesarios para completar las tareas (con un colchón de seguridad, por supuesto).
- El Product Owner utiliza la velocidad y la cantidad de puntos de historia que quedan en el backlog para prever cuántos sprints serán necesarios para completar las tareas (con un colchón de seguridad, por supuesto).
Por último, volvamos a ver cómo los equipos normalmente proporcionan estimaciones en puntos de historia. Como hemos mencionado, no hay un mapeo universal de puntos-tiempo, así que para algunos equipos 3 puntos de historia es el esfuerzo que puede tomar un día y para algún otro equipo puede tomar 2.
Sin embargo, hay una práctica común que muchos equipos de desarrollo utilizan, que es proporcionar estimaciones utilizando la secuencia de Fibonacci en lugar de una secuencia lineal:
¿Por qué? La respuesta es sencilla. Cuanto mayor sea la tarea, mayor será la incertidumbre de la estimación. Si un desarrollador está estimando una tarea y piensa que es algo que le llevará un par de horas, podemos esperar que el margen de error sea pequeño, normalmente acabará tardando entre una hora y media y 3 horas.
Pero, ¿qué ocurre si se estima que la tarea tardará 5 días? En este caso, lo que puede ocurrir es que se tarde de 4 a 7 días.
El uso de una escala de Fibonacci nos ayuda a recoger esta incertidumbre.
Lo que hace el equipo es asignar valores de puntos de historia a las historias de usuario siguiendo la secuencia de fibonacci, utilizando uno de los siguientes valores: 2,3,5,8,13,20 …
Este sistema también puede ser visto como un sistema de “tallas”, una historia de usuario puede ser estimada como XS, S, M, L, XL, XXL — lo mismo que hacemos con la ropa.
Lo importante aquí es que nos hemos alejado de tener que comprometernos con una caja de tiempo para terminar cada historia de usuario (estimación en tiempo) y estamos en una situación en la que el equipo sólo tiene que decirnos cómo de “grande” es cada historia de usuario.
Hablemos de backlogs
Como Product Owners nos gustaría que el ritmo del equipo de desarrollo fuera lo más predecible posible, para poder prever con seguridad cuándo estarán listas las principales mejoras de nuestro producto y así poder coordinarnos con la parte comercial y de marketing de nuestro trabajo.
Esta previsibilidad está estrechamente relacionada con las estimaciones de nuestros compañeros de desarrollo. Cuanto mayor sea la incertidumbre o sus estimaciones, menos predecibles serán, más problemas encontraremos a la hora de prever campañas o acciones comerciales junto con implementaciones listas para el mercado.
Consideremos 2 backlogs, cada uno de ellos con una carga de 100 puntos de historia, estimados por el mismo equipo en el mismo proyecto. Pero con una pequeña diferencia.
Durante los últimos 12 sprints, el equipo ha entregado una media de 33 puntos de historia por sprint. Teniendo en cuenta la carga que queda en el backlog, deberían ser necesarios 3 sprints adicionales para terminar las tareas.
¿En cuál de los dos casos deberíamos estar más cómodos como Product Owner?
Personalmente, estaría más seguro de la fecha de entrega en el primer caso. Puede requerir un poco más de 3 sprints, pero no creo que la desviación sea tan significativa como el riesgo que supone el segundo backlog.
En la sección anterior dije que cuanto mayor es la estimación en puntos de historia, mayor es la incertidumbre de esa estimación. La incertidumbre de una estimación significa RIESGO.
Un product manager siempre debe tratar de minimizar el riesgo de un producto, a menos que la situación exija lo contrario. Hay una forma práctica de minimizar ese riesgo teniendo en cuenta las estimaciones iniciales del equipo de desarrollo:
Básicamente, lo que queremos hacer es estar alerta y considerar siempre la posibilidad de dividir las historias de usuario que se estimen en más de X puntos de historia.
¿Por qué X?
Bueno, como hemos comentado, esa X depende mucho del equipo, así que habrá desarrolladores que estimen que pueden entregar 16 puntos por sprint mientras que otros estimarán la misma cantidad.
