Plantillas Scrum: historias de usuario y criterios de aceptación

Una de las principales innovaciones que representa el desarrollo ágil frente a los enfoques tradicionales, es en la forma de levantar los requerimientos del usuario.

A diferencia del enfoque tradicional, en el cual el “Diseño de Sistema” contiene documentación detallada del comportamiento y representa el final de las conversaciones, en las metodologías ágiles se hace uso de las “Historias de usuario”, las cuales se enfocan en definir lo que el usuario necesita hacer, sin describir el cómo, por lo que representa el inicio y no el final de las conversaciones.

En este artículo, presentamos una plantilla para documentar las historias de usuario, puede utilizarse en un marco de trabajo de desarrollo ágil (por ejemplo Scrum), e incluye la documentación de los enunciados de las historias y los criterios de aceptación en una misma plantilla.

Las historias de usuario en Scrum

En el marco de trabajo Scrum, no esta prescrita una forma para documentar los elementos del Product Backlog, sin embargo, las historias de usuario son la forma más utilizadas.

En Scrum, el encargado de elaborar los elementos del Product Backlog es el Product Owner. Sin embargo, el Scrum Master tiene la tarea de ayudar al equipo Scrum (Product Owner y desarrolladores) a aplicar técnicas para que los elementos del Product Backlog sean claros y concisos. Una de esas formas, puede ser ayudándolos a escribir historias de usuario.

El enunciado de la historia de usuario

El enunciado está compuesto por el Rol, Acción y Resultado. El enunciado no describe detalles de cómo se va a ejecutar la acción que necesita el usuario.

Para una mejor clasificación y organización puede añadirse un código a cada historia, para ayudar a su identificación unívoca dentro del proyecto.

A continuación a la descripción de cada uno de estos elementos:

• Identificador (ID) de la historia: Código que identifica unívocamente a la historia en el Proyecto que se esté desarrollando. El formato debe ser elegido por el equipo.
• Rol: Es el rol que está desempeñando el usuario cuando utiliza la funcionalidad que se está describiendo. Debe ser lo más especifico posible, describiendo el rol o actor que se está desempeñando. El enunciado puede escribirse como se sigue: Yo como un [Rol], Desempeñando el rol de [Rol], Como un [Rol], entre otros. Por ejemplo: 

• Yo como cliente registrado. 
• Desempeñando el rol de cliente registrado. 
• Como un cliente registrado. 
• Característica / Funcionalidad (Feature): Representa la función que el rol quiere o necesita hacer en el sistema que se está desarrollando. Puede diferenciarse entre acciones obligatorias u opcionales, utilizando la palabra puede o necesita para describir la acción. Por ejemplo:

• Necesito realizar búsquedas de productos por categorías. 
• Puedo seleccionar una categoría para ver el número de productos que tiene asociado. 
• Razón / Resultados: Lo que el rol necesita lograr al ejecutar la acción. Este es el resultado de ejecutar la acción desde el punto de vista del rol. Este punto puede ser opcional, pues la historia puede documentarse sólo con la definición del rol y la acción (sin definir la consecuencia). 

Una vez se definen estos componentes, la frase de historia queda establecida de la siguiente forma:

• Yo como un [Rol], necesito [Descripción de la funcionalidad], con la finalidad de [Descripción de la consecuencia]. 

Esto equivale al Titulo descriptivo de la historia, que Puede utilizarse para hacer referencia en la pila de producto, junto con su código.

Se pueden aplicar las siguientes variantes en la definición del rol:

• Como un [Rol], necesito [Descripción de la funcionalidad], con la finalidad de [Descripción de la consecuencia].
• Desempeñando el rol de [Rol], necesito [Descripción de la funcionalidad], con la finalidad de [Descripción de la consecuencia]. 

O también variar entre obligatorio u opcional en la descripción de la funcionalidad:

• Como un [Rol], puedo [Descripción de la funcionalidad], con la finalidad de [Descripción de la consecuencia]. 

También puede omitirse la descripción de la consecuencia:

• Como un [Rol], puedo [Descripción de la funcionalidad]. 
• Yo como un [Rol], puedo [Descripción de la funcionalidad]. 

Los criterios de aceptación

Están compuestos por la descripción del contexto, evento y consecuencia, definen los requerimientos del dueño de producto sobre cómo deben comportarse el sistema para ejecutar la acción. Representan el inicio de la definición del cómo. No están diseñados para ser tan detallados como una especificación de diseño tradicional.

Si una historia de usuario tiene más de 4 criterios de aceptación, debe evaluarse subdividir la historia.

Puede añadirse un número de escenario para identificar al criterio, asociado a la historia de usuario en cuestión.

Los elementos de los criterios de aceptación son:

• Número de escenario: Número (ejemplo 1, 2, 3 ó 4), que identifica al escenario asociado a la historia. 
• Título del escenario: Describe el contexto del escenario que define un comportamiento. Por ejemplo, si se toma el ejemplo de búsquedas de productos por categoría, un posible ejemplo pudiera ser: Categoría sin productos asociados. 
• Contexto: Proporciona mayor descripción sobre las condiciones que desencadenan el escenario. 
• Evento: Representa la acción que el usuario ejecuta, en el contexto definido para el escenario. 
• Resultado / Comportamiento esperado: Dado el contexto y la acción ejecutada por el usuario, la consecuencia es el comportamiento del sistema en esa situación. 

De esta forma, el formato para documentar los criterios de aceptación es:

Escenario [Número de escenario] [Titulo del escenario]: En caso que [Contexto] y adicionalmente [Contexto], cuando [Evento], el sistema [Resultado / Comportamiento esperado]
Tomando el ejemplo anterior de las búsquedas de productos por categoría, un posible escenario podría ser:

Escenario 1: En caso que exista una categoría sin productos asociados, cuando el cliente despliegue el listado de categorías para realizar su búsqueda, el sistema mostrará el siguiente texto al lado de la categoría “Actualmente no poseemos productos para esta categoría”.

Definición y uso de las historias de usuario

Una vez has escrito tus historias de usuario, debes utilizarlas para que los desarrolladores de software puedan definir el backlog de producto y la planificacion de iteraciones.

> Plantilla de historias de usuario y criterios de aceptación en un marco de desarrollo ágil