Artefactos de Scrum. Historias de Usuario en el Product Backlog

2 de septiembre de 2015

En la sección de introducción hemos hablado sobre cómo Scrum está basado en el empirismo y sobre cómo la velocidad de trabajo de los Equipos de Desarrollo dota al proceso de Scrum de predictibilidad. Los elementos del Product Backlog cuentan con una propiedad imprescindible para conseguir este objetivo, las estimaciones.

El Product Backlog debe contener todo aquello que sea necesario realizar para completar el proyecto, es decir, funcionalidades, tareas, prototipos, pruebas, errores a corregir, etc. En la mayoría de los casos estos elementos son representados como historias de usuario.

Las historias de usuario representan fragmentos de funcionalidad o comportamiento que se desea que posea un producto. El término fue introducido por Kent Beck como parte de la metodología Extreme Programming para desarrollar una forma de definición de requisitos informal que pudiera favorecer el entendimiento entre todo tipo de perfiles, ya fueran técnicos o no.

Las historias de usuario deben poder ser escritas en una tarjeta de papel de tres pulgadas, es decir, deben contener una descripción mínima de la tarea que permita comprenderlas hasta el punto de poder priorizar entre ellas.

Las características que describen a las buenas historias de usuario se resumen en el acrónimo INVEST:

  • Independientes (independent). Deben poder ser llevadas a cabo en cualquier orden.

  • Negociables (negotiable). Su alcance puede ser negociado entre el cliente y el Equipo de Desarrollo antes de empezar a desarrollarlas.

  • Valorables (valuable). Dan solución a un problema que aporta valor al cliente y a los usuarios finales del producto.

  • Estimables (estimable). El equipo de desarrollo es capaz de estimar el esfuerzo necesario para completarlas.

  • Reducidas (small). Deben estar lo suficientemente acotadas como para que se puedan llevar a cabo en el plazo de un Sprint.

  • Testables (testable). Debería ser posible escribir tests de software que comprueben su correcto funcionamiento de forma automática.

Las historias de usuario se suelen expresar mediante la fórmula:

“Yo como … quiero … que/para que … “

Por ejemplo:

Yo como usuario quiero que la aplicación tenga una opción exportar que me permita obtener los informes en csv.

La cláusula yo como representa quién necesita la historia o a quién aporta valor, quiero describe la funcionalidad deseada y que/para que describe por qué se quiere la funcionalidad o el valor aportado.

Cabría pensar que el yo siempre representará al usuario final de la aplicación pero puede ser cualquier tipo de rol:

Yo como cliente quiero que los usuarios puedan acceder fácilmente a las web de otros productos míos para que se potencien las ventas cruzadas.

Yo como desarrollador quiero que se despliegue un entorno web hotfix para que se puedan hacer correcciones rápidas sin que afecte a los usuarios finales.

Una vez que se tiene un Product Backlog repleto de historias de usuario correctamente definidas el Equipo de Desarrollo al completo las estima, con la ayuda del Product Owner para explicar y resolver cualquier duda sobre el funcionamiento y alcance de las mismas.

Las estimaciones se pueden hacer mediante horas de trabajo o mediante puntos de historia.

Los puntos de historia aportan mucha más información a las estimaciones pues representan el tiempo que se puede tardar en completarlas, la complejidad de las mismas, la incertidumbre que encierran, etc lo que permite medir la productividad del equipo y su evolución a lo largo de los Sprints.

Las estimaciones mediante horas miden, única y exclusivamente, el tiempo que se les dedica. Hablaremos de los puntos de historia en futuros posts.

La consecuencia de un Product Backlog dinámico, priorizado y rebosante de historias de usuario cuidadosamente estimadas, sumado a un Equipo de Desarrollo con varios Sprints a sus espaldas, es poder planificar los tiempos y costes del proyecto de manera precisa y empírica.

Así, si se sabe que nuestro equipo al completo desarrolla a una velocidad media de 15 puntos de historia por día y que nuestro cliente ha descrito un producto para el que se han extraído 89 historias de usuario las cuales, después de ser estimadas, suman un total de 1920 puntos de historia podemos afirmar de manera precisa y con autoridad que el proyecto se completará, inicialmente, en 128 días, es decir, unos seis meses.

Este último párrafo concentra lo mejor de Scrum en una pocas líneas. Pensemos un poco en sus implicaciones.

Sin Scrum, u otra disciplina ágil similar, la planificación de los proyectos se hacía en base al buen criterio de uno o más expertos, es decir, ¡a ojo de buen cubero! o, en el mejor de los casos, mediante diagramas de Gantt, los cuales resultan mucho más complejos de actualizar de forma frecuente para recoger los imprevistos que puedan surgir a lo largo de la ejecución del proyecto.

Con Scrum nos estamos basando en una serie de requisitos debidamente especificados, en el criterio de todo un equipo a la hora de estimar punto por punto cada funcionalidad del producto y en una velocidad media de desarrollo calculada en base a ejercicios pasados y reales, es decir, no estimada sino medida.

Pero aún hay más, esta estimación se actualiza cada Sprint, es decir, cada no más de cuatro semanas, en base a la nueva velocidad media de desarrollo, que suele aumentar a medida que el Equipo aprende más sobre el proyecto y las tecnologías empleadas, y en base también al nuevo conjunto de requisitos reflejado en el Product Backlog. En las metodologías clásicas de desarrollo como el desarrollo en cascada la estimación no se actualiza con lo cual, cuando se detecta que el proyecto se está desviando de la planificación todo lo que se puede hacer es contratar a más personal, el cual resulta difícil formar a tiempo para que sea realmente útil, pedir horas extra al Equipo con la consecuente pérdida de motivación y, en consecuencia, productividad o disculparse y renegociar con el cliente.

En un entorno de desarrollo empírico el riesgo del proyecto se actualiza cada pocas semanas con lo que, si se presentan dificultades, se puede decidir entre ampliar el plazo de entrega o acotar el alcance del producto pues los objetivos de calidad deben permanecer intocables. Pero lo más importante es que nuestro cliente es consciente de la evolución del proyecto y, en muchas ocasiones, de cómo sus frecuentes cambios de requisitos suponen un sobrecoste o un retraso a la estimación inicial con lo que se lo puede pensar dos veces antes de solicitarlos.

Key Points
Scrum está basado en el empirismo.
La velocidad de trabajo del Equipo de Desarrollo dota a Scrum de predictibilidad gracias a las estimaciones.
Los elementos del Product Backlog suelen ser representados como historias de usuario.
Las historias de usuario representan fragmentos de funcionalidad de forma que puedan favorecer el entendimiento entre perfiles técnicos y no técnicos.
Las historias de usuario deben poder ser escritas en una tarjeta de papel.
Las buenas historias de usuario cumplen con el acrónimo INVEST (independent, negotiable, valuable, estimable, small y testable).
Las historias de usuario se suelen expresar mediante la fórmula: "Yo como … quiero … que/para que … "
El Equipo de Desarrollo al completo estima las historias de usuario del Product Backlog. El Product Owner las explica y resuelve dudas.
Los puntos de historia aportan más información a las estimaciones que las horas pues representan tiempo, complejidad e incertidumbre.
Un Product Backlog lleno de historias de usuario debidamente estimadas es la clave para planificar el tiempo de desarrollo de un proyecto de forma precisa y empírica.
Las estimaciones del Product Backlog se actualizan cada Sprint en base a la velocidad de desarrollo del equipo y a las nuevas tareas introducidas.
En Scrum el riesgo del proyecto se actualiza cada pocas semanas, el cliente es consciente de la evolución del proyecto y de cómo los cambios de requisitos suponen un sobrecoste o un retraso a la estimación inicial.