User Stories

Otra de las "herramientas" clave de las metodologías ágiles son las historias de usuario. Empecemos como habitualmente con su wiki-definición.

Podemos entender las historias de usuario como una representación de un requerimiento de software escrito en una o dos frases utilizando el lenguaje común del usuario. 

Las historias de usuario son utilizadas para la especificación de requerimientos incluyendo, a ser posible, las condiciones de aceptación, las pruebas de validación, para dar como buena la historia. 

Podemos entrar en detalles cómo deben estar escritas por el usuario, deben poderse escribir en un post-it, o características similares que, pese a poder ser beneficiosas, para mi son superfluas (no estamos escribiendo un tweet ;D). 

Para mi lo realmente importante, tal y como expresa Xavier Quesada en el post de proyectosagiles.org es que, una vez completada, representen un incremento de valor para el usuario. Y me parece importante por que establece la granuralidad con la que debemos considerar una historia, esa es la diferencia fundamental entre historia y tarea, para ser concretos.

¿Qué información debe contener?

Como viene siendo habitual en los artículos previos, no podemos dar una respuesta por valida para todas las situaciones. Simplemente una solución común y alguna reflexión que pueda ser de utilidad.

• Identificador. Nos debe permitir identificar por ejemplo numéricamente la tarea, útil por ejemplo cuando necesitamos indicar dependencia entre historias
• Nombre o Título de la historia, a ser posible una breve descripción del requisito
• Valor de la historia para el cliente. En el plan de proyecto deberíamos tener una escala de valoraciones, al fin y al cabo nos ayudaran a resolver la prioridad de las tareas
• Esfuerzo estimado, siguiendo las diferentes técnicas de estimación que presentaremos, debemos aportar un valor cuantitativo a la historia, este valor en base a la capacidad productiva del equipo, nos debe servir para analizar su incorporación al Sprint
• Riesgo, no se trata de un campo utilizado siempre, en ocasiones podemos utilizar post-its de diferentes colores para diferencias su riesgo ... nos debe servir igualmente para intentar balancear el riesgo de cada Sprint
• Prioridad, al igual que sucede con el riesgo, la prioridad debe venir definida de la reunión de definición de Sprint, y debe ayudar al equipo a seleccionar la siguiente historia a ejecutar del Sprint Backlog. Nos podemos por ejemplo ayudar de colores para diferenciar la prioridad de cada historia  (En próximos artículos veremos el método de priorización MoSCoW)
• Dependencia, relación de historias que deben ser finalizadas previamente al inicio de ésta, nos debe permitir identificar el camino crítico o potenciales bloqueos
• Pruebas de validación, o condiciones de aceptación. Relación de pruebas de validación que debe cumplir el producto para dar como superada la historia

Veamos un ejemplo gráfico (imagen de la web Agile Modeling referenciada al final de post)

La planificación y la estimación

Las historias de usuario se definen durante la fase de captación de requisitos, de user research, pero también durante las fases de planificación y estimación.

Una vez finalizada la fase de captación de requisitos, disponemos de una lista de historias, el product backlog, que podemos ordenar por prioridad según el criterio del cliente.

El proceso disciplinado ágil recomienda aplicar la visión del iceberg, y diseñar con gran detalle los historias próximas (las más prioritarias) y en menor detalle las de baja prioridad, por ser más lejanas.

A cada finalización de sprint, cuando se detectan nuevas historias, estás son priorizadas e incorporadas al product backlog.

El ejercicio de planificación queda claramente representado en el siguiente esquema, que también podéis encontrar en Agile Modeling.

Una vez priorizado y planificado el product backlog, debemos volver a revisar las historias para su estimación, y debe ser el equipo de desarrollo el responsable de la estimación (veremos en próximos artículos diferentes métodos de estimación) a partir de las estimaciones de las historias más prioritarias, y de la capacidad disponible para el Sprint que vamos a iniciar, podremos definir el Sprint Backlog, es decir las historias objetivos para el siguiente Sprint.
 Referencias:

• Proyectosagiles.org - Introducción a la estimación y planificación ágil
• Wiki - Definición de historia de usuario
• Blog David Bonilla - Estructura de una historia de usuario
• DEVNETTIPS - Definiendo historias de usuario en Scrum
• Agile Modeling - Introduction to User Stories

Saludos,